Apollo分布式配置中心 - 服务中间件

一、概念

1、什么是配置？

应用程序在启动和运行的时候往往需要读取一些配置信息（可以理解为系统参数），配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。

配置主要有以下几个特点：

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

① 配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为。

② 配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置。

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

① 配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。

3）配置可以有多种加载方式

① 常见的有程序内部硬编码、配置文件、环境变量、启动参数、基于数据库等。

4）配置需要治理

① 权限控制：由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制。

② 不同环境、集群配置管理：同一份程序在不同的环境（开发、测试、生产）、不同的集群（如不同的数据中心）经常需要有不同的配置，所以需要有完善的环境、集群配置管理。

2、什么是配置中心？

简单理解，配置中心是对配置的管理中心。

在单体应用中，一个应用只需要一份配置文件，但是现在的微服务架构，每个服务可能都需要一份配置文件，这样很多配置文件就需要有一个统一管理的地方，这个地方就叫做配置中心。

分布式的一个特点就是共享性，就是每一个服务都可以为其他服务提供服务，因此就可以专门做一个配置中心服务专门为其他服务提供配置文件的管理。

总的来说，配置中心就是一种统一管理各种应用配置的基础服务组件。

二、Apollo（阿波罗）

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

https://github.com/ctripcorp/apollo

服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot 环境也有较好的支持。

1、Apollo特性：

基于配置的特殊性，Apollo从设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：

1）统一管理不同环境、不同集群的配置

① Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。

② 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等。

③ 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖。

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

① 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。

3）版本发布管理

① 所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。

4）灰度发布

① 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。

5）权限管理、发布审核、操作审计

① 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。

② 所有的操作都有审计日志，可以方便的追踪问题。

6）客户端配置信息监控

① 可以在界面上方便的看到配置在被哪些实例使用。

7）提供Java和.Net原生客户端

① 提供了Java和.Net的原生客户端，方便应用集成。

② 支持Spring Placeholder，Annotation和SpringBoot的ConfigurationProperties，方便应用使用（需要Spring3.1.1+）。

③ 同时提供了http接口，非Java和.Net应用也可以方便的使用。

8）提供开放平台API

① Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验。如数据库用户名、密码、Redis服务地址等。

② 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制。

2、Apollo执行流程：

 操作流程如下：

1）用户在Apollo配置中心上的管理界面上添加或修改配置信息，比如数据库的连接参数等等。

2）应用程序通过Apollo的客户端连接Apollo的配置中心（Apollo服务端）来拉取信息给应用程序使用。

用户通过Apollo配置中心修改或发布配置后，会有两种机制来保证应用程序来获取最新配置：一种是Apollo配置中心会向客户端推送最新的配置；另外一种是Apollo客户端会定时从Apollo配置中心拉取最新的配置，通过以上两种机制共同来保证应用程序能及时获取到配置。

3、本地安装Apollo服务端

1）运行时环境：

Java：Apollo服务端：1.8+

           Apollo客户端：1.7+

MySQL：5.6.5+

MySQL下载路径：https://downloads.mysql.com/archives/community/

2）Apollo的组成：

① Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端

② Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）

③ Eureka提供服务注册和发现，为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的

④ Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳

⑤ 在Eureka之上架了一层Meta Server用于封装Eureka的服务发现接口

⑥ Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），然后直接通过IP+Port访问服务，同时在Client侧会做负载均衡（load balance）、错误重试

⑦ 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

4、配置发布的原理：

 上图简要描述了配置发布的主要过程：

1）用户在Portal操作配置发布

2）Portal调用Admin Service的接口操作发布

3）Admin Service发布配置后，发送ReleaseMessage给各个Config Service

4）Config Service收到ReleaseMessage后，通知对应的客户端

5、Admin Service发布配置后，发送ReleaseMessage给各个Config Service的过程：

Admin Service作为producer（生产者）向消息队列中发，Config Service作为consumer（消费者）监听消息队列，如果有新的消息就能拿到了。Apollo考虑到实际使用场景，以及为了尽可能减少外部依赖，自己通过数据库实现了一个简单的消息队列：

具体实现方式如下：

1）在数据库中创建了一张ReleaseMessage表，这张表中存储的是发布配置的消息记录。当Admin Service发布配置之后，Admin Service就会向ReleaseMessage表中插入一条记录，消息内容就是配置发布的 AppId+Cluster+Namespace，表示刚才向哪个应用、哪个集群、哪个namespace发布了一个配置。

2）Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。如果发小有新的消息记录，它就会拿到这个消息去通知客户端。

3）客户端收到通知后，就知道了是哪个应用、哪个集群、哪个namespace有配置更新，就能找到刚刚更新的配置信息。

6、环境变量：

-Dapp.id=account-service -Denv=DEV -Dapollp.cluster=SHAJQ -Ddev_meta=http://localhost:8080

-Dapp.id=account-service        表示服务名称

-Denv=DEV        表示环境信息

-Dapollp.cluster=SHAJQ        表示集群

-Ddev_meta=http://localhost:8080        表示配置信息的地址