项目配置管理从单一到全面

本文是我同事、我部微服务架构师杨工在2018年7月5号发表于公众号“CI智创未来”的一篇文章，特为大家转载分享。

 

 

新人程序员张阿毛接到了一个开发任务，要做一个跨系统调用的查询。领导拍拍他肩膀说，要有对外部系统连接信息的配置。

 

张阿毛想了想，去查了下配置的概念：

“配置是独立于程序的只读变量。”

 

张阿毛一看只读变量，就懂了，代码很快就出来了。

 

01 Hard code

张阿毛在程序里定义了url，timeout等常量，然后调用这些常量完成了查询

领导看了后，强行咽下要喷出口的老血，对张阿毛解释说：配置定义中“只读”的意思是程序只能读取配置的内容，却不能修改配置。程序中要避免硬编码。

 

02 配置文件

张阿毛意识到不能用硬编码，于是改用了配置文件。在properties配置文件中定义url的地址和其他信息，然后写了个方法读取配置文件中的内容，后来又改成全局变量+配置文件的方式用来提高性能。

 

领导看了后阴着脸说，配置文件确实是很常用的配置方式，多数用在配置很少变更的场合，因为一旦配置调整就不得不重新修改、打包、发布，分布式应用甚至要每个服务都做修改，带来的工作量和停机成本是很高的，希望换个思路。

 

03 数据库配置

配置文件被否掉以后，张阿毛想到了数据库配置的方式。在数据库中建了一张配置表，程序启动时加载配置表信息。这样在需要修改的时候只要修改数据库就可以了，避免了修改代码重新打包的问题。

领导对张阿毛的进步表示认可，但又提了新的问题：

1

对配置的修改需要重启服务，这依旧带来了停机成本和复杂性；

2

测试人员和运维人员都需要修改配置，不可能让他们直接去数据库改，要有配置维护页面；

3

微服务项目要有松散的耦合，不应多个服务都连接在一个数据库上。

04 配置中心V1

这并不能难倒努力的张阿毛，通过跟团队大神的请教和自己的不断学习，一系列重构后，张阿毛把配置功能抽离出来，构成了独立于应用的配置中心。形成的配置中心架构图如下：

 

其中：

 

• Config Service是配置服务，作为一个单独的服务独立出来，一方面供各微服务通过Config client调用获取配置，另一方面服务于Config web portal进行在线配置管理。

• Config Service和Client保持长连接，采用推拉结合（pull&push）的模式。Push就是配置的变更实时推送给client，实现方式是Http Long Polling，即通过client发起http请求，Config Service保持住这个连接30秒，如果遇到变更就立刻返回给client，返回后client重新发起请求。Pull是为了防止push机制失败而采用的替补方案，Client每5分钟一次请求同步。

 

领导对这个设计表示赞许，同时也提出了存在的问题：配置信息在不同的环境中可能不同，这样Config Service和DB每个环境需要一套。但是Config Web Portal如果也分开就会很麻烦，建议通过一个Web终端管理所有的配置数据。

 

05 配置中心V2

考虑到要通过一套web终端（Config web portal）管理多个环境的配置，因此引入了Environment的维度，对应开发、测试、预生产、生产等环境。因为web终端既要维护不同环境的配置数据，也要对应一套统一的权限和配置数据，前者在不同的数据库中，后者只要一套数据库就可以了，因此将数据库拆分开来，得到的架构图如下：

 

其中：

 

• 数据库拆分开，Config DB用于存放不同环境的配置数据，Portal DB存放用户、权限、项目信息和配置的元数据信息。

• 增加了Admin Service服务，供Config Web Portal调用进行配置管理。

• Config Web Portal和Portal DB部署一套，Admin Service和Config Service以及Config DB每个环境有一套。

 

领导再次表扬了张阿毛，但又提出了配置中心高可用的问题。

 

06 配置中心V3

为了保证配置中心的高可用，Config Service和Admin Service都需要以集群方式部署。这个时候就需要服务注册和发现，以及负载均衡机制。架构再次调整：

其中：

 

• Config Service和Admin Service改用集群方式部署；

• 增加高可用服务注册中心Eureka集群，Eureka提供了完整的服务注册和发现功能，并且跟Spring Cloud无缝集成，还是开源的，是目前注册中心的最佳选择。

• Config Service和Admin Service启动后会注册到Eureka；Client 或Portal通过Eureka的服务发现功能和客户端负载均衡（Ribbon）请求到对应的Config Service或Admin Service。

 

领导对这个设计给予了极大的肯定，这个配置中心能满足基于java的微服务平台的绝大多数需求，但是对于公司非java技术场景的应用却不适用，因为无法注册到Eureka上去。希望能够开放接口，支持到其他技术场景。

 

07 配置中心V4

如此变态的需求让张阿毛苦恼不已，Eureka仅支持java应用，如果要支持到其他技术势必要改造Eureka，工作量和难度可谓是很大了。张阿毛经过无数个夜晚绞尽脑汁的苦苦挣扎之后，终于想到了一个办法：虽然Eureka只支持java，但是HTTP是所有语言都适用的，何不在Eureka外再加一层封装Meta Server，通过Http接口将服务地址列表开放出去，这样各个语言的Client可以很容易的获取服务列表，而且可以在Client端做负载均衡。

 

但是问题又来了，领导肯定会提Meta Server的高可用问题，毕竟一旦Meta Service挂了，整个配置中心也就不能用了。如果Meta Server用集群部署，势必需要再加一层负载均衡。

 

于是整个架构就成了下面的样子：

 

其中：

 

• Meta Server用于封装Eureka服务发现接口，Client或Portal通过负载均衡访问Meta Server获取Config Service或Admin Service服务列表，而后通过服务列表地址访问对应的服务，同时在Client或Portal侧会做负载均衡和错误重试。

• Nginx Load Balance提供了对Meta Server的负载均衡和流量转发。

 

领导经过长时间思考之后，终于露出了满意的微笑。

 

08 结束语

以上是以故事的方式一步步对配置中心的设计深入分析，故事过程纯属瞎编。本文的最终设计思路来自于对Ctrip Apollo的学习，其作者宋顺给出的架构图如下：

 

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

 

Apollo基于开源模式开发，开源地址：https://github.com/ctripcorp/apollo（请点击阅读原文）

 

除了上面提到的架构设计外，Apollo还提供了灰度发布、权限管理、发布审核、操作审计、配置信息监控等功能，可以说是目前功能最完善的配置中心了，值得我们深入学习和研究。