【管理设计篇】聊聊分布式配置中心
之前就写过一篇文章，介绍配置中心，但是也只是简单描述了下配置中心的设计点。本篇从apollo的安装到部署架构到核心原理进一步解读，大概看了下apollo的原理，感觉没有必要深究，所以就不打算写源码分析的文章了。只要了解明白基本设计思路就可以。
部署
整体上来说就是需要启动三个java项目，然后导入两个数据库。
1.创建ApolloPortalDB
通过各种MySQL客户端导入sql/apolloportaldb.sql即可。
2.创建ApolloConfigDB
通过各种MySQL客户端导入sql/apolloconfigdb.sql即可。
3.下载安装包
官方文章 ：https://www.apolloconfig.com/#/zh/deployment/quick-start
其中有三个系统，adminservice、configService、portal 将对应的配置文件的数据库修改成自己的。
解压之后，按照如下方式启动，
configService
nohup java -jar apollo-configservice-2.0.1.jar > configservice.log &
adminservice
nohup java -jar apollo-adminservice-2.0.1.jar > adminservice.log &
portal
nohup java -jar apollo-portal-2.0.1.jar > portal.log &
4.访问就可以了
http://localhost:8070/ u/p apollo/admin
具体可以参考官方文档。
架构
整体上来说有五个角色，apollo客户端 也就是java程序，两个DB、Eureka集群、portal、config service、Admin service
- config service提供配置的读取、推送功能，服务对象是apollo客户端
- admin service 提供配置的修改，发布功能。服务对象是apollo portal界面
- config service和admin service都是多实例，无状态部署，所以需要将自己注册到eureka中
整体流程是这样的。
1.config service服务启动，将服务注册到eureka中。admin service也将自己的服务注册到eureka中。
2.添加修改配置 portal启动，从eureka获取admin service服务实例，当添加修改配置的时候，portal调用admin serice修改配置 config，对应的数据。数据是保存在DB中的。
3.客户端启动的时候，从enurka集群获取到config service服务实例。获取服务配置。
注意，如果我们要修改配置数据的话，如何将数据实时通知给apollo客户端
配置发布后实时推送设计
其中主要以来的是admin service服务异步通知config service，config service 通知客户端。
发送ReleaseMessage的实现方式
从上面的流程可以看到其实admin Service通知config service变更的通知场景，就是典型的一发一收的场景，可以使用消息队列来解决，但是apollo设计者可能考虑到引入对于的中间件，所以采用了一种定时查询数据表的方式。大概如下：
其实就是admin service有数据变更的话，都会在release Message表插入新的记录。而config service有一个定时任务，每秒都查询一次数据是否有新增，有新增的话，就通知客户端进行配置更新。
Config Service通知客户端的实现方式
其实客户端会发起一个HTTP请求到config service的接口，不会立即马上返回，而是在60S内判断，配置又没有变更，没有变更 就返回http 304状态码给客户端。
如果有配置变更，会传入变更配置的namespace信息，同时该请求会立马返回。
客户端从返回的结果中获取到配置变化的name space后，立刻请求config service获取该namespace最新配置
客户端设计
客户端这边除了通过长连接的方式会更新配置，还有定时从配置中心拉去配置。并且自己本地内存缓存和本地文件也都会存储一份。
可用性
技术选型
总结
本篇简单从部署以及介绍了apollo的实现原理，可以发现对于配置中心来说其底层以来的是数据库进行数据存储的。并且在一般的配置中 push 、pull 、定时 等方式 也都有一定的优缺点。
