中间件middleware
内容管理
- why use 配置中心
- 配置中心feature
- 配置中心develop
- 主流配置中心
- Apollo浅谈
本文从理论上介绍一下服务化中服务治理系统中的配置中心的理论并浅析Apllo
配置在生产中是很关键的一个部分，cfeng在work中遇到几次配置问题引发的问题，如果没有一个方便快捷的配置修改方案，那么不利于产品的快速迭代。
why use 配置中心
配置分离是一个基本的过程，把开关写在代码里面是非常低级的行为。we接触SpringBoot的时候，经常将配置写在yml文件中，但是文件打包发布之后，你如果再修改yml内容，那么就需要再次部署。 可以直接在yml中利用${XXX}的方式将参数设置为变量进行管理，不管是在K8s中配置还是在Potainer中配置都比较快捷， 这就是配置管理的重要性。
配置Configuration是独立于程序的变量： 首先就是配置独立程序，不同的配置程序会有不同的行为。 常见的配置包括: DB Connection、 Thread Pool、 内存Buffer size… ②： 配置贯穿应用的整个生命周期，程序启动时读取配置进行初始化，运行时根据配置进行行为的调整； ③：配置有多种加载方式： 常见的就是程序内部硬编码，配置文件以及环境变量、启动参数、基于DB…
服务化架构下，一个产品可能由多个不同的子系统组成，产品性能的保证依靠所有子系统组成整体的配置的良好管理。 配置中心，就是统一管理项目中所有配置的系统。
没有配置中心之前的配置管理
- 小的单体项目之前经常是静态化配置： 项目中存在单独的配置文件，比如log.properties、yml等，但是正如👆所说，参数修改不灵活，有的甚至需要重启项目才行
- 配置文件区分环境需要手动编写多个文件，比如application.yml, application_test.yml, application_dev.yml，手动维护可能会因为误操作导致一些问题， 同时多个文件会显得非常分散，不易管理
- 配置修改不能追溯： 也就是修改是没有记录的，不会记录历史操作记录，那么都不能进行配置回滚，非常麻烦
上面几个痛点的解决就是配置中心：
那么一个配置中心需要具有哪些特性来改善？
1. 权限控制： 因为配置会影响程序的行为，配置修改属于敏感操作，需要进行控制
2. 不同环境、集群配置管理： 同一个程序不同环境、不同的集群对应不同的配置，需要完善管理
3.兼容框架类组件配置管理： 框架类组件配置如CAT客户端配置，框架是产品的一部分，这些配置作为产品配置一部分也需要管理起来
...
配置中心feature
配置中心最基本支持的功能就应该是配置的CRUD， 除了基本的配置治理需求之外，对于分布式架构，配置中心还需要具备一下特点：
高可用
服务化系统需要考虑高可用问题，配置是逻辑中非常重要的部分，很大程度决定程序的行为，为避免无法预期的结果，会直接报错，所以配置很关键，需要保证HA
配置热发布
大多数场景下，应用程序的重新发布（重启）代表业务中断，这个会影响产品使用，很多时候的版本迭代可能只是涉及到配置的修改，这个时候如果能够支持热发布【程序运行时更新配置】，那么就可以消除上述影响
不同环境、集群配置管理
公司一般会涉及到不同的环境（比如开发、SIT、UAT、生产…）以及不同的集群（不同地域的机房…)，如果手动的复制不同环境的配置文件，会极大增加错误的风险； 那么配置中心如果能够设置规则，并且复制相关的相同的配置… ，可以提高效率
权限管理，操作审核
一些关键的配置会严重影响产品的使用，对于一些配置的修改，应该管控起来，配置的更改应该具有一定的资质（权限），每次配置的修改都应该留存记录，并且应当让产品的高权限者进行审核，以此确保产品的正常发布
灰度发布
配置的重要性不言而喻，cfeng之前work一般发布的时候都会有灰度验证步骤，这是增加了一次试错机会。配置中心需要支持将配置应用到部分实例上， 这样we可以观察配置在这些实例上生效之后的效果，如果符合预期，监控系统没有报错，那么就可以将其应用到所有实例上
版本管理
配置中心的配置的每次修改都应该有记录，并且配置记录具有版本的概念，不同版本的发布应该对应不同的版本。以此支持版本回滚操作
监控&&多语言支持
配置中心应该具备监控功能，这样才能更加保证配置中心的可靠性。配置中心对接的是不同的产品系统，服务端代码当然是配置中心本身决定，但是客户端耦合时，需要支持多种语言支持，方便不同语言编写的系统的接入（一些产品可能go实现、java实现、C++实现…）
配置中心develop
随着业务的不断发展，架构在不断变化，各种新兴业务的接入，配置中心也需要考虑新的困难。
容器化、Serverless、云原生
云原生架构当下是比较热门的，cfeng 之前work中就是这种架构，这种架构会要求无状态的应用程序不要依赖磁盘，而是将数据放到有状态的系统上，like 分布式存储系统和DB… 需要考虑在没有磁盘缓存的场景下，如何保证配置中心的可用性…
并且在没有磁盘缓存的情况下，如果需要扩容 ----- 将应用部署到新的机器上，没有磁盘缓存，如果配置中心服务端连接断开,怎么处理…
写配置HA
大多数场景都会实现配置中心的读配置的高可用，因为配置变动非常低频，【如果发生异常，配置中心无法读取到新的配置，原有的配置也是继续运行的，不会导致服务中断】
但是写配置HA也需要保证， eg：某个机房大量断电，导致某个核心应用不能正常运行，它依赖的一些其他的应用也不能运行，短时间难以恢复。 那么这个时候的解决办法可能是：应用负责人登录配置中心，尝试更改配置，切换URL，部署到其他的机房机器上。 但是如果没有写配置HA，那么这个时候写配置会提示DB错误，不能正常修改，无法达到效果
如何实现写配置HA也是需要考虑的一个问题…
敏感配置
敏感的配置信息：比如数据库的数据源、账号密码，不适合缓存在本地，那么这些敏感数据在配置中心中应该如何正确的进行治理也是需要仔细考虑的一个问题…
主流配置中心
目前市面上流通的配置中心包括baidu开源的Disconf、 Spring Cloud生态中的Spring Cloud Config、 ctrip开源的Apollo、ali开源的Nacos
详细的对比解析这里不再具体展开，Nacos不仅具有配置治理功能，同时还具有注册中心的功能； Spring Cloud Config作为Spring Cloud生态中一员，与Git紧密相关。
Apollo浅谈
Apollo是专业的配置治理中间件。 其分为MySQL、 Config Service、 Admin Service、 Portal（入口）四个模块。
- MySQL: 用于存储Apollo元数据和相关的用户的配置数据
- Config Service： 提供配置的读取、推送等功能，客户端的请求直接落点
- Admin Service：配置的修改、发布等功能，Portal操作的服务就是对应该组件功能
- Portal： 入口大屏，提供给用户的配置界面
这是Apollo官网给出的时间比较久远的架构，可以看到配置中心也是需要和类似Eureka的注册中心进行交互注册。
Apllo的apollo-client的AbstactConfigFile中：
//AbstractConfigFile 这个类的成员包含ConfigRepository， 获取配置文件需要从仓库中获取
protected final ConfigRepository m_configRepository;
//要初始化AbstractConfigFile，需要从仓库中获取配置文件加入properies成员中
private void initialize () {
...
m_configProperties.set(m_configRepository.getConfig);
...
}
Repository在应用中经常见到，就是抽象的本地存储，从本地存储中获取config信息加入properties中使用
再看看具体的getConfig方法：
public Properties getConfig() {
...
sync();
...
}
//再看看LocalConfigFileRepository类的实现
in = new FileInputStream(file);
properties = new Properties();
properties.lodad(in);
//可以看到这里就是读取file文件，并且本地缓存不只是支持Properties这种类型文件，在apllo/internals/PlainTextConfigFile中提供了文件支持
Apllo的客户端和服务端之间会保持长连接，这样当然是为了方便进行服务端的推送【配置更新主动推送到客户端】
//apollo-client/... /internals/RemoteConfigLongPollService
//连接超时时间为90s
private static final int LONG_POLLING_READ_TIMOUT = 90 * 1000;
//设置读超时
HttpRequest request = new HttpRequest(url);
request.setReadTimeout(LONG_POLLING_READ_TIMEOUT);
//接收服务端配置更新推送
if(response.getStatusCode() == 200 && response.getBody() != null) {
updateNotifications(response.getBody());
updateRemoteNotifications(response.getBody());
notify(lastServiceDto, response.getBody());
}
客户端发起一个readTimeout为90s的请求，进行配置的推送。
详细的源码解析和简易demo的实现后续会详细展开🌳
