apollo在项目的使用

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，在服务启动的时候把参数注入即可。