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

原创作者： 58沈剑来自公众号：架构师之路

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

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

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

对于同一个服务：

（1）它往往有多个上游调用；

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

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

那么问题来了：

调用方如何维护下游服务集群配置？

当服务集群增减节点时，调用方是否有感知？

初期：“配置私藏”架构

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

如上图：

（1）用户中心user-service有ip1/ip2/ip3三个节点；

（2）service1调用了用户中心，它有一个专属配置文件s1.conf，里面配置了us的集群是ip1/ip2/ip3；

（3）service2也调用了用户中心，同理有个配置文件s2.conf，记录了us集群是ip1/ip2/ip3；

（4）web2也调用了用户中心，同理w2.conf，配置了us集群是ip1/ip2/ip3；

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

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

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

（1）运维检测出ip1节点的硬盘性能下降，通知研发未来要将ip1节点下线；

（2）由于5月8日要做大促运营活动，未来流量会激增，研发准备增加两个节点ip4和ip5；

此时要怎么做呢？

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

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

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

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

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

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

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

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

中期：“全局配置”架构

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

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

（1）运维层面制定规范，新建全局配置文件，例如/opt/global.conf；

画外音：如果配置较多，注意做好配置的垂直拆分。

（2）对于服务方，如果是通用的服务，集群信息配置在global.conf里；

（3）对于调用方，调用方禁止配置私藏，必须从global.conf里读取通用下游配置；

全局配置有什么好处呢？

（1）如果下游容量变化，只需要修改一处配置global.conf，而不需要各个上游修改；

（2）调用方下一次重启的时候，自动迁移到扩容后的集群上来了；

（3）修改成本非常小，读取配置文件目录变了而已；

全局配置有什么不足呢？

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

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

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

（1）文件监控组件FileMonitor

作用是监控文件的变化，起一个timer，定期监控文件的ModifyTime或者md5就能轻松实现，当文件变化后，实施回调。

（2）动态连接池组件DynamicConnectionPool

“连接池组件”是RPC-client中的一个子组件，用来维护与多个RPC-server节点之间的连接。所谓“动态连接池”，是指连接池中的连接可以动态增加和减少。

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

引入了这两个组件之后：

（1）一旦全局配置文件变化，文件监控组件实施回调；

（2）如果动态连接池组件发现配置中减少了一些节点，就动态的将对应连接销毁，如果增加了一些节点，就动态建立连接，自动完成下游节点的增容与缩容；

终版：“配置中心”架构

“全局配置”架构是一个能够快速落地的，解决“修改配置重启”问题的方案，但它仍然解决不了，服务提供方“不知道有多少个上游调用了自己”这个问题。

如果不知道多少上游调用了自己：

“按照调用方限流”

“绘制全局架构依赖图”

等这类需求便难以实现，怎么办？

“配置中心”架构能够完美解决。

对比“全局配置”与“配置中心”的架构图，会发现配置由静态的文件升级为动态的服务：

（1）整个配置中心子系统由zk、conf-center服务，DB配置存储与，conf-web配置后台组成；

（2）所有下游服务的配置，通过后台设置在配置中心里；

（3）所有上游需要拉取配置，需要去配置中心注册，拉取下游服务配置信息（ip1/ip2/ip3）；

当下游服务需要扩容缩容时：

（4）conf-web配置后台进行设置，新增ip4/ip5，减少ip1；

（5）conf-center服务将变更的配置推送给已经注册关注相关配置的调用方；

（6）结合动态连接池组件，完成自动的扩容与缩容；

“配置中心”架构有什么好处呢？

（1）调用方不需要再重启；

（2）服务方从配置中心中很清楚的知道上游依赖关系，从而实施按照调用方限流；

（3）很容易从配置中心得到全局架构依赖关系；

痛点一、痛点二同时解决。

“配置中心”架构有什么不足呢？

一来，系统复杂度相对较高；

二来，对配置中心的可靠性要求较高，一处挂全局挂。

总结

究竟要解决什么痛点？

上游痛：扩容的是下游，改配置重启的是上游；

下游痛：不知道谁依赖于自己；

总之，难以实施服务治理。

究竟如何解决上述痛点？

一、“配置私藏”架构；

二、“全局配置文件”架构；

三、“配置中心”架构；

知其然，知其所以然。

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

微服务架构spring cloud - 分布式配置中心config（七）
1.什么是spring-cloud-config 用来为分布式系统中的基础设施和微服务应用提供集体化的外部配置支持,它分为服务端和客户端.服务端也就是config服务,客户端就是其他的微服务. spr ...
大数据互联网架构 tomcat集群配置时三个端口的作用
tomcat集群配置时三个端口的作用在配置多个tomcat时需要同时配置这三个端口 Connector用于监听请求 protocol: http/1.1协议 , 用于监听浏览器发送的请求 , 设置成 ...
微服务架构之「配置中心」
点击上方"方志朋",选择"置顶公众号" 技术文章第一时间送达! 在微服务架构的系列文章中,前面已经通过文章<微服务架构之「服务网关」>介绍过了在微 ...
spring.profiles.active配置了没生效_微服务架构之「配置中心」
在微服务架构的系列文章中,前面已经通过文章<微服务架构之「服务网关」>介绍过了在微服务中服务网关的原理和应用,今天这篇文章我们继续来聊一聊微服务中另外一个重要模块:「配置中心」.后面 ...
spring cloud互联网分布式微服务云平台规划分析--服务统一配置中心
1.介绍鸿鹄云架构[服务统一配置中心]为分布式系统中的外部配置提供服务器和客户端支持.使用commonservice-config,可以在所有环境中管理应用程序的外部属性.应用程序可通过从开发人员到 ...
微服务中集成分布式配置中心 Apollo
背景随着业务的发展.微服务架构的升级,服务的数量.程序的配置日益增多(各种微服务.各种服务器地址.各种参数),传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求:配置修改后实时生效, ...
apollo 配置中心_配置中心——Apollo小记
一.什么是配置配置是程序运行时,动态调整行为的能力. 配置有以下属性: 配置是独立于程序的只读变量同一份程序在不同的配置下才会有不同的行为,而且配置对于程序来说是只读的,所以程序可以通过读取配置来 ...
Apollo配置中心热加载mysql_Apollo 配置中心部署注意事项
2019 年 12 月份的时候写过一篇文章 Apollo 配置中心初探,当时刚接触 apollo,使用还不是很熟练,只是快速的部署出来了.随后在业务快速迭代的过程中,使用 apollo 的频率越来越高 ...
统一配置中心选型对比
整理笔记时发现之前整理的一些东西,分享给大家. 为什么需要集中配置程序的发展,需要引入集中配置: 随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关.参数的配置.服务器的地址-- 并且对配置 ...

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

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

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

最新文章

热门文章