Apollo（阿波罗）是携程框架部门研发的分布式配置核心，可能集中化治理利用不同环境、不同集群的配置，配置批改后可能实时推送到利用端，并且具备标准的权限、流程治理等个性，实用于微服务配置管理场景。

性能：

  • 对立治理不同环境、不同集群的配置，以命名空间namespace为最小粒度进行配置，一个服务引入了这个命名空间，即应用了该命名空间的配置。
  • 配置批改实时失效
  • 版本公布治理
  • 灰度公布
  • 权限治理、公布审核、操作审计
  • 客户端配置信息监控

应用：

  • 服务端的配置：

    • 新建appId，appId能够了解为是一套利用。在appId新建namespace增加配置内容。Namespace能够了解为是配置的汇合，原先一个yml文件寄存配置，当初能够通过某个环境 ，某个appId下的namespace引入。

  • 客户端的应用：

    • 引入maven包并在启动类退出@EnableApollo即可，通过meta.server，appId和namespace找到所需的配置。能够了解为在apollo的配置就在配置文件里。通过@Value，@ConfigurationProperties引入的变量不受影响，对代码的入侵比拟小。
    • 监听配置的变动，不同的namespace

  • 在我的项目的应用：

    • 把配置信息放入apollo。间接的做法是每个服务应用一个namespace，然而通过梳理发现，有些配置是多个服务独特应用的。

    • 服务的配置进行分类：

      • 通用：Log，eureka，feign调用相干的
      • 某些服务专用：database（openapi monitor） redis（card openapi double） kafka activemq ElasticSearch
      • 各自的服务领有独自的namespace

通过分类后，如果要批改数据库地址，redis地址，或者新增一个中间件的地址，只用新增namespace，在配置文件引入/批改该namespace即可。
如果想更改某个服务的配置，在相应的namespace下批改，并重启docker服务。能够看到公布历史，有哪些实例在应用。
我的项目是用docker部署的，原先一部分配置在服务里，一部分配置在docker-compose里，革新后尽可能所有的配置都放在apollo里，apollo的配置放在docker-compose.yml里，docker-compose.yml能够引入公共的配置文件env_file，真正的apollo配置寄存文件，包含apollo.meta，app.id，apollo.cacheDir，不必再通过profile.active辨别。一些无奈通过apollo配置的放在服务的配置或docker的配置中。实践上能当在服务的配置文件里的都能放在apollo里。
每个服务只需一个配置文件，甚至不必配置文件。为了本地开发的不便，在本地搁置了sit环境的配置。
通过apollo.meta辨别不同的环境，apollo.meta变量通过docker-compose文件的公共配置env_file引入

须要留神的：

  • 配置的备份
  • 假如两个人对同一个服务进行开发，须要批改配置
  • Application里的配置会实时失效，自定义的namespace不会。
  • 开关，限流额度，门路

  • 对于日志级别，database等须要更新bean的，须要写代码

    • https://github.com/ctripcorp/apollo-use-cases

Namespace的类型：

  • 公有：namespace从属于appId，只有配置了该appId才可拜访
  • 私有：只有连上了apollo就能应用，属于所有利用，全局惟一
  • 关联：属性是公有的，能够了解为在继承私有属性的根底上，可对私有属性进行批改

其余的性能：

  • 密钥治理，爱护配置不被其余利用获取
  • 权限调配：以namespace为粒度调配批改，公布，查看的权限
  • 增加集群
  • 配置笼罩，后面的会笼罩前面的，尽可能不要笼罩，保障配置的唯一性

架构：

从逻辑上来说比拟清晰，将配置的编辑/公布与客户端获取配置离开，用两个服务实现
Portal通过调用admin service接口批改配置
Client通过config service接口获取配置
为了保障高可用，增加了一层eureka，client和portal通过eureka调用接口服务。
为了使不同语言的client可通过http接口即可获取admin service和config service的信息，eureka上搭建Meta service，用来封装服务发现的细节，不必关怀背地的注册核心和服务发现组件（用于不同语言的服务注册到eureka上）。

残缺架构如下：

次要模块：

  • Config Service：配置的读取、推送等，服务对象是Apollo客户端
  • Admin Service：配置的批改、公布等，服务对象是Apollo Portal（治理界面）
  • Config Service和Admin Service都是多实例、无状态部署，所以须要将本人注册到Eureka中并放弃心跳

  • Meta Server：在Eureka之上搭建，用于封装Eureka的服务发现接口：

    • Client通过域名拜访Meta Server获取Config Service服务列表（IP+Port），而后间接通过IP+Port拜访服务，同时在Client侧会做load balance、谬误重试
    • Portal通过域名拜访Meta Server获取Admin Service服务列表（IP+Port），而后间接通过IP+Port拜访服务，同时在Portal侧会做load balance、谬误重试
  • 为了简化部署，实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM过程中

服务端设计：

Admin service公布了配置批改的事件，所有config service收到音讯并告诉客户端批改配置。
有两个值得去摸索的点：

  • Admin service公布事件的形式：能够用中间件redis，activemq实现。这里为了缩小内部组件的依赖，通过数据库实现。


具体的做法是Admin公布一条配置后，这个配置必定属于某个namespace，在ReleaseMessage表插入一条记录AppId+Cluster+Namespace，config service有一个线程每秒扫描ReleaseMessage表，如果有新的音讯记录，就告诉客户端更新配置。所以配置如果有更新，个别一秒内就可告诉到客户端。

  • Config service告诉客户端的形式：客户端发动获取配置的申请，config service用defferResult将申请挂起，如果60秒内没有感兴趣的namespace配置发生变化，返回304，否则立刻返回变动后的配置。应用defferResult能够进步申请的并发量

客户端设计：

  • 客户端和服务端放弃了一个长连贯，从而能第一工夫取得配置更新的推送。（通过Http Long Polling实现）

  • 客户端还会定时从Apollo配置核心服务端拉取利用的最新配置。

    • 这是一个fallback机制，为了避免推送机制生效导致配置不更新
    • 客户端定时拉取会上报本地版本，所以个别状况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
    • 定时频率默认为每5分钟拉取一次，客户端也能够通过在运行时指定System Property: apollo.refreshInterval来笼罩，单位为分钟。
  • 客户端从Apollo配置核心服务端获取到利用的最新配置后，会保留在内存中

  • 客户端会把从服务端获取到的配置在本地文件系统缓存一份

    • 在遇到服务不可用，或网络不通的时候，仍然能从本地复原配置
  • 应用程序能够从Apollo客户端获取最新的配置、订阅配置更新告诉
  • 测试环境下多环境部署SIT，QA，UAT，用一套画面治理不同的环境：

与spring的集成原理
Spring的ApplicationContext会蕴含一个Environment，在服务启动的时候把参数注入即可。