Apollo 配置中心（一）

Apollo 解析

Github 地址：https://github.com/ctripcorp/apollo/

官方推荐源码解析博客：http://www.iocoder.cn/categories/Apollo/

一、使用 Apollo 是为了解决什么问题

现在开发同一份程序都会在不同的环境下运行，最常见的就是开发环境、测试环境、预发布环境、生产环境等。如何在不同环境下进行，配置切换呢？

最传统，最手工的做法就是每发布一个环境，就手动更改配置。这种做法，会导致配置错误，浪费大量时间。

后来就发现了，使用 maven 管理配置，配置写在文件中，maven 打包的时候，根据你的打包命令，扫描文件，并替换文件中的’{}'中的内容。虽然这样的操作已经能节约很大的时间成本，但是和上一种手工操作一样，存在一个很重大的问题–重要信息泄露。

配置信息中会有数据库的连接信息和密码等信息，以及其他关键信息。不能保证每个程序员都有良好的品格，不会因为各种理由攻击，或者修改数据库。这时候，就需要配置信息掌握在少数人的手中。
当然 apollo 也并不是只解决了上面阐述的问题（可能我比较low，上家公司给我的感觉，迫切想解决的问题，毕竟上家公司的技术业务要求还没达到需要灰度发布程度。。。），还解决了权限、灰度发布、集群配置等。

同时也随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、参数的配置、服务器的地址……

对程序配置的期望值也越来越高：配置修改后实时生效，灰度发布，分环境、分集群管理配置，完善的权限、审核机制……

在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。

Apollo配置中心应运而生！

二、Apollo 框架介绍

1、基础模型

（1）用户在配置中心对配置进行修改并发布

（2）配置中心通知Apollo客户端有配置更新

（3）Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用（这里用拉取不太合适，不过可以先这么理解）

2、总体设计

上图简要描述了Apollo的总体设计，大致分为Client、Portal、SLB、Meta Server、 Eureka、Config Service、Admin Service 7个服务以及两个数据库。我们可以从下往上看：

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

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

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

• 在Eureka之上我们架了一层Meta Server用于封装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进程中

3、各模块概要介绍

(1) Config Service

• 提供配置获取接口
• 提供配置更新推送接口（基于Http long polling）
• 服务端使用Spring DeferredResult实现异步化，从而大大增加长连接数量
• 目前使用的tomcat embed默认配置是最多10000个连接（可以调整），使用了4C8G的虚拟机实*测可以支撑10000个连接，所以满足需求（一个应用实例只会发起一个长连接）。
• 接口服务对象为Apollo客户端

(2) Admin Service

• 提供配置管理接口
• 提供