互联网架构，究竟为什么需要配置中心？

2023-02-27

架构中心 conf

配置中心是互联网架构体系中很重要的一块，但为什么会有配置中心，是不是一开始就要有配置中心，它究竟解决什么问题，这是今天要讨论的问题。随着互联网业务的越来越复杂，用户量与流量越来越大，“服务化分层”是架构演进的必由之路。如上图，站点应用会调用服务，上游服务调用底层服务，依赖关系会变得非常复杂。对于同一

配置中心是互联网架构体系中很重要的一块，但为什么会有配置中心，是不是一开始就要有配置中心，它究竟解决什么问题，这是今天要讨论的问题。

随着互联网业务的越来越复杂，用户量与流量越来越大，“服务化分层”是架构演进的必由之路。

如上图，站点应用会调用服务，上游服务调用底层服务，依赖关系会变得非常复杂。

对于同一个服务：

(1)它往往有多个上游调用;

(2)为了保证高可用，它往往是若干个节点组成的集群提供服务;

如上图，用户中心服务user-service有三个节点，ip1/ip2/ip3对上游提供服务，任何一个节点当机，都不影响服务的可用性。

那么问题来了：

调用方如何维护下游服务集群配置?
当服务集群增减节点时，调用方是否有感知?

初期：“配置私藏”架构

“配置私藏”是配置的最初级阶段，上游调用下游，每个上游都有一个专属的私有配置文件，记录被调用下游的每个节点配置信息。

如上图：

用户中心user-service有ip1/ip2/ip3三个节点;
service1调用了用户中心，它有一个专属配置文件s1.conf，里面配置了us的集群是ip1/ip2/ip3;
service2也调用了用户中心，同理有个配置文件s2.conf，记录了us集群是ip1/ip2/ip3;
web2也调用了用户中心，同理w2.conf，配置了us集群是ip1/ip2/ip3;

画外音：是不是很熟悉?绝大部分公司，初期都是这么玩的。

“配置私藏”架构的缺点是什么呢?

来看一个容量变化的需求：

运维检测出ip1节点的硬盘性能下降，通知研发未来要将ip1节点下线;
由于5月8日要做大促运营活动，未来流量会激增，研发准备增加两个节点ip4和ip5;

此时要怎么做呢?

需要用户中心的负责人通知所有上游调用者，修改“私藏”的配置，并重启上游，连接到新的集群上去。在ip1上没有流量之后，通知运维将ip1节点下线，以完成整个缩容扩容过程。

这种方案存在什么问题呢?

当业务复杂度较高，研发人数较多，服务依赖关系较复杂的时候，就没这么简单了。

问题一：调用方很痛，容量变化的是你，凭啥修改配置重启的是我?这是一个典型的“反向依赖”架构设计，上下游通过配置耦合，不合理。

问题二：服务方很痛，ta不知道有多少个上游调用了自己，往往只能通过以下方式来定位上游：

群里吼
发邮件询问
通过连接找到ip，通过ip问运维，找到机器负责人，再通过机器负责人找到对应调用服务

画外音：是不是似曾相识?

不管哪种方式，都很有可能遗漏，导致ip1一直有流量难以下线，ip4/ip5的流量难以均匀迁移过来。该如何优化呢?

中期：“全局配置”架构

架构的升级并不是一步到位的，先来用最低的成本来解决上述“修改配置重启”的问题一。

“全局配置”架构：对于通用的服务，建立全局配置文件，消除配置私藏：

运维层面制定规范，新建全局配置文件，例如/opt/global.conf;画外音：如果配置较多，注意做好配置的垂直拆分。
对于服务方，如果是通用的服务，集群信息配置在global.conf里;
对于调用方，调用方禁止配置私藏，必须从global.conf里读取通用下游配置;

全局配置有什么好处呢?

如果下游容量变化，只需要修改一处配置global.conf，而不需要各个上游修改;
调用方下一次重启的时候，自动迁移到扩容后的集群上来了;
修改成本非常小，读取配置文件目录变了而已;

全局配置有什么不足呢?

如果调用方一直不重启，就没有办法将流量迁移到新集群上去了。

有没有方面实现自动流量迁移呢?

答案是肯定的，只需要引入两个并不复杂的组件，就能实现调用方的流量自动迁移：

文件监控组件FileMonitor：作用是监控文件的变化，起一个timer，定期监控文件的ModifyTime或者md5就能轻松实现，当文件变化后，实施回调。
动态连接池组件DynamicConnectionPool：“连接池组件”是RPC-client中的一个子组件，用来维护与多个RPC-server节点之间的连接。所谓“动态连接池”，是指连接池中的连接可以动态增加和减少。

画外音：用锁来互斥，很容易实现。

引入了这两个组件之后：