配置中心——Apollo小记

1、什么是配置

配置是程序运行时，动态调整行为的能力。

配置有如下属性：

• 配置是独立于程序的只读变量

  • 同一份程序在不一样的配置下才会有不一样的行为，并且配置对于程序来讲是只读的，因此程序能够经过读取配置来改变本身的行为，可是不能本身改动配置文件。

• 配置伴随应用的整个生命周期

  • 应用在启动的时候经过读取配置来初始化，在运行时根据配置改变本身的行为。

• 配置有多中加载方式

  • 程序内部hard code，这种作法是反模式，十分不建议。

  • 配置文件。

  • 环境变量，配置能够预置在操做系统的环境变量里，程序运行时读取。

  • 启动参数，能够在程序启动时一次性提供参数。

  • 基于数据库，将易变配置放在数据库中，这样能够在运行期灵活调整配置。

• 配置须要治理

  • 权限控制：对配置的修改须要有比较完善的权限控制，不然不正确的配置会引发灾难。

  • 不一样环境、集群配置管理：同一份程序在不一样环境（开发、测试、生产）、不一样的集群（如不一样的数据中心）常常须要有不一样的配置，因此须要完善的环境、集群配置管理。

  • 框架类组件配置管理：如CAT客户端的配置。

2、为何须要配置中心

在没有引入配置中心以前，通常研发的时候会有如下痛点：

• 配置格式散乱不规范

  • 有的用properties格式，有的用yml格式，有的用xml格式，还有存DB的，作法五花八门。

• 主要采用本地静态配置，配置修改麻烦

  • 在分布式微服务环境下，当服务实例不少的时候，配置修改费时费力。

• 易引起生产事故

  • 如将测试环境的配置带到生产环境上。

• 配置缺少安全审计和版本控制功能

  • 没法查看到修改配置的人，修改了什么内容，以及修改的时间，除了问题也没法及时回滚。

3、配置中心的核心需求

1. 交付件和配置分离

   传统作法应用在打包部署的时候，会为不一样环境打出不一样配置的包，每一个包里头包含环境特定配置。而如今推荐采用如容器镜像方式打包和交付微服务，应用镜像通常只打一份，能够部署到不一样环境，因此这要求交付件和配置进行分离，交付件只制做一份，而且是不可变的，能够部署到任意环境。可是全部环境的配置均可以在配置中心集中配置，运行期应用能够根据自身环境到配置中心动态拉取相应的配置。

2. 抽象标准化

   配置中心应该封装屏蔽配置管理的细节和配置的不一样格式，方便用户进行自主式配置管理，通常用户只须要关注两个抽象和标准化的接口便可：

   • 配置管理界面UI，方便应用开发人员管理和发布配置。

   • 封装好的客户端API，方便应用集成和获取配置。

3. 多环境多集群

   微服务应用大多采用多环境部署，通常标准的环境有开发/测试/生产等，有的应用还须要多集群部署，如支持跨机房或多版本部署。配置中心须要支持对多环境和多集群应用配置的集中式管理。

4. 高可用

   配置中心不能挂，不然会大面积影响微服务。

5. 实时性

   配置更新须要尽快通知到客户端，有些配置的实时性要求很高，像是主备切换配置或者蓝绿部署配置，这些须要秒级切换配置的能力。

6. 治理

   配置须要治理，具体包括：

   • 配置审计，须要记录修改人，修改内容和修改事件，方便出现问题时能后追溯。

   • 配置版本控制，每次变动须要版本化，出现问题能够及时回滚到上一版本。

   • 配置权限控制，配置变动发布须要认证受权。

   • 灰度发布，配置发布时能够先让少数实例生效，肯定没有问题就能够扩大应用范围。

4、什么是Apollo

Apollo是携程框架部门研发的开源配置管理中心，可以集中化管理应用不一样环境、不一样集群的配置，配置修改后可以实时推送到应用端，而且具有规范的权限、流程治理等特性。

Apollo的特性以下：

• 统一管理不一样环境、不一样集群的配置。

  • Apollo提供了一个统一界面集中式管理不一样环境、不一样集群、不一样命名(namespace)空间的配置，并且同一份代码部署在不一样集群，能够有不一样的配置。

• 配置修改实时生效（热发布）

• 版本发布管理

• 灰度发布

• 客户端配置信息监控

  • 能够在界面上方便地看到配置在被哪些实例使用。

• 提供Java和.Net原生客户端

• 提供开放平台API

• 部署简单

能够看到，Apollo的特性几乎符合上文配置中心的核心需求。

5、Apollo的基本模型

1. 用户如今UI界面修改/发布配置。

2. Apollo配置中心会将配置更新信息推送到Apollo客户端。

3. 客户端再从Apollo配置中心拉取最新配置，更新本地配置以后，通知到应用。

6、Apollo客户端设计

 

一、Apollo客户端实现原理

1. 客户端和服务端会保持一个长链接，从而第一时间获取配置更新的推送。

2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置，并且客户端定时拉取会上报给本地版本，默认每隔5分钟拉取一次，也能够经过运行时指定apollo.refreshInterval来覆盖，单位为分钟。

3. 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存。

4. 客户端会把从服务端拉取到的配置在本地文件系统缓存一份，保证在遇到服务不可用或网路故障时，依赖能从本地恢复配置，也实现了必定的高可用性。

5. 应用程序从客户端获取到罪行的配置、订阅配置更新通知。

二、配置更新推送实现

上文提到Apollo客户端和服务端保持了一个长链接，从而能够第一时间得到配置更新的推送，实际上长链接是经过Http Long Polling实现的：

• 客户端发起Http请求给服务端

• 服务端保持60s链接

  • 若是在60s中有客户端关心的配置变化，则请求会当即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取该namespace的最新配置。

  • 若是60s内没有客户端关心的配置变化，则返回http状态码304给客户端。

在服务端，是用async servlet(Spring DeferredResult)来服务Http Long Polling请求。

7、Apollo整体设计

 

在捋清思路以前，先对其中的模块进行了解：

主要模块：

1. ConfigService

   • 提供配置获取接口

   • 提供配置推送接口

   • 服务于Apollo客户端

2. AdminService

   • 提供配置管理接口

   • 提供配置修改发布接口

   • 服务于管理界面Portal

3. Client

   • 为应用获取配置，支持实时更新

   • 经过MetaServer获取ConfigService的服务列表

   • 使用客户端软负载SLB方式调用ConfigService

4. Portal

   • 配置管理页面

   • 经过MetaServer获取AdminService的服务列表

   • 使用客户端软负载SLB方式调用AdminService

辅助模块：

1. Eureka

   • 用于服务发现和注册

   • Config/AdminService注册实例并按期报心跳

   • 和ConfigService一块儿部署

2. MetaServer

   • Portal经过域名访问MetaServer获取AdminService的地址列表

   • Client经过域名访问MetaServer获取ConfigService的地址列表

   • 至关于Eureka Proxy

   • 和ConfigService一块儿部署

3. NginxLB

   • 和域名系统配合，协助Portal访问MetaServer获取AdminService的地址列表

   • 和域名系统配合，协助Client访问MetaServer获取ConfigService的地址列表

   • 和域名系统配置，协助用户访问Portal进行配置管理。

一、简化架构A

 

假设没有分布式微服务的服务发现，那么：

1. Portal会调用AdminService进行配置管理和发布

2. ConfigService和Client保持长链接，ConfigService服务于Client进行配置获取，ConfigService和Client经过一种推拉结合的方式，实现配置实时更新 的同时，保证配置更新不丢失。

3. ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境的配置信息，并且这三者在每一个配置环境（DEV/FAT/UAT/PRO)中都要部署一份。

4. Protal有个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Portal只需部署一份，它能够管理多套环境。

二、简化架构B

 

由于Client要找ConfigService须要地址列表，Portal找到AdminService也须要地址列表，这时候就须要服务发现了。

1. Config/AdminService启动后都会注册到Eureka服务注册中心，并按期发送保持心跳。

2. Eureka采用集群方式部署，使用分布式 一致性协议保证每一个势力的状态最终一致。

3. Client和Portal能够经过Eureka发现ConfigService和AdminService的地址列表。

三、简化结构C

 

由于携程须要跟自家的.Net的系统兼容，因此引入了MetaServer服务，这至关因而代理Proxy，将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来。

可是MetaServer自己也是无状态以集群方式部署的，那么Client/Protal该如何发现MetaServer呢？传统的方式是借助硬件（能够在其中指定MetaServer的位置）或者是软件负载均衡器。

四、彻底结构D

 

使用NginxLB（也称Software Load Balancer），由运维为MetaServer集群配置一个域名，指向NginxLB集群，NginxLB再对MetaServer进行负载均衡和流量转发。Client/Portal经过域名+NginxLB间接访问MetaServer集群。

 

---

这里踩个坑，由于一套Portal就能够集中管理多套环境（DEV/FAT/UAT/PRO）中的配置，因此当切换环境的时候，须要注意到.properties(.yml)等配置文件中（SpringBoot）是否有明确标记处须要取出哪些namespace的配置，不然Client将会拉取不了配置中心的配置到本地。

 

参考：

微服务架构 为何须要配置中心
携程 Apollo 配置中心架构深度剖析
Apollo配置中心介绍