互联网架构,究竟为什么需要配置中心?-阿里云开发者社区

开发者社区> 阿里云MVP> 正文
登录阅读全文

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

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

配置中心是互联网架构体系中很重要的一块,但为什么会有配置中心是不是一开始就要有配置中心,它究竟解决什么问题,这是今天要讨论的问题。
随着互联网业务的越来越复杂,用户量与流量越来越大,“服务化分层”是架构演进的必由之路。
image.png

如上图,站点应用会调用服务,上游服务调用底层服务,依赖关系会变得非常复杂。 对于同一个服务:(1)它往往有多个上游调用;(2)为了保证高可用,它往往是若干个节点组成的集群提供服务;
image.png

如上图,用户中心服务user-service有三个节点,ip1/ip2/ip3对上游提供服务,任何一个节点当机,都不影响服务的可用性。 那么问题来了调用方如何维护下游服务集群配置?当服务集群增减节点时,调用方是否有感知? 初期:“配置私藏”架构
“配置私藏”是配置的最初级阶段,上游调用下游,每个上游都有一个专属的私有配置文件,记录被调用下游的每个节点配置信息
image.png

如上图:(1)用户中心user-serviceip1/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 画外音:是不是很熟悉?绝大部分公司,初期都是这么玩的。 “配置私藏”架构的缺点是什么呢?
image.png

来看一个容量变化的需求:(1)运维检测出ip1节点的硬盘性能下降,通知研发未来要将ip1节点下线(2)由于5月8日要做大促运营活动,未来流量会激增,研发准备增加两个节点ip4和ip5 此时要怎么做呢?
image.png

需要用户中心的负责人通知所有上游调用者,修改“私藏”的配置,并重启上游,连接到新的集群上去。在ip1上没有流量之后,通知运维将ip1节点下线,以完成整个缩容扩容过程。 这种方案存在什么问题呢?当业务复杂度较高,研发人数较多,服务依赖关系较复杂的时候,就没这么简单了。 问题一:调用方很痛,容量变化的是你,凭啥修改配置重启的是我?这是一个典型的“反向依赖”架构设计,上下游通过配置耦合,不合理。 问题二:服务方很痛,ta不知道有多少个上游调用了自己,往往只能通过以下方式来定位上游:

  • 群里吼

  • 发邮件询问

  • 通过连接找到ip,通过ip问运维,找到机器负责人,再通过机器负责人找到对应调用服务

画外音:是不是似曾相识?
不管哪种方式,都很有可能遗漏,导致ip1一直有流量难以下线,ip4/ip5的流量难以均匀迁移过来。该如何优化呢? 中期:“全局配置”架构
架构的升级并不是一步到位的,先来用最低的成本来解决上述“修改配置重启”的问题一。
image.png

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

(1)运维层面制定规范,新建全局配置文件,例如/opt/global.conf;画外音:如果配置较多,注意做好配置的垂直拆分。(2)对于服务方,如果是通用的服务,集群信息配置在global.conf里;(3)对于调用方,调用方禁止配置私藏,必须从global.conf里读取通用下游配置; 全局配置有什么好处呢?(1)如果下游容量变化,只需要修改一处配置global.conf,而不需要各个上游修改;(2)调用方下一次重启的时候,自动迁移到扩容后的集群上来了;(3)修改成本非常小,读取配置文件目录变了而已; 全局配置有什么不足呢?如果调用方一直不重启,就没有办法将流量迁移到新集群上去了。


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

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

(1)文件监控组件FileMonitor作用是监控文件的变化,起一个timer,定期监控文件的ModifyTime或者md5就能轻松实现,当文件变化后,实施回调。
(2)动态连接池组件DynamicConnectionPool“连接池组件”是RPC-client中的一个子组件,用来维护与多个RPC-server节点之间的连接。所谓“动态连接池”,是指连接池中的连接可以动态增加和减少。画外音:用锁来互斥,很容易实现。 引入了这两个组件之后:(1)一旦全局配置文件变化,文件监控组件实施回调;(2)如果动态连接池组件发现配置中减少了一些节点,就动态的将对应连接销毁,如果增加了一些节点,就动态建立连接,自动完成下游节点的增容与缩容; 终版:“配置中心”架构
“全局配置”架构是一个能够快速落地的,解决“修改配置重启”问题的方案,但它仍然解决不了,服务提供方“不知道有多少个上游调用了自己”这个问题 如果不知道多少上游调用了自己:“按照调用方限流”“绘制全局架构依赖图”等这类需求便难以实现,怎么办?
“配置中心”架构能够完美解决。
image.png

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

(1)整个配置中心子系统由zk、conf-center服务,DB配置存储与,conf-web配置后台组成;(2)所有下游服务的配置,通过后台设置在配置中心里;(3)所有上游需要拉取配置,需要去配置中心注册,拉取下游服务配置信息(ip1/ip2/ip3)
image.png

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

(4)conf-web配置后台进行设置,新增ip4/ip5,减少ip1;(5)conf-center服务将变更的配置推送给已经注册关注相关配置的调用方;(6)结合动态连接池组件,完成自动的扩容与缩容; “配置中心”架构有什么好处呢?(1)调用方不需要再重启;(2)服务方从配置中心中很清楚的知道上游依赖关系,从而实施按照调用方限流;(3)很容易从配置中心得到全局架构依赖关系;痛点一、痛点二同时解决。 “配置中心”架构有什么不足呢?一来,系统复杂度相对较高;二来,对配置中心的可靠性要求较高,一处挂全局挂。
 总结
究竟要解决什么痛点?上游痛:扩容的是下游,改配置重启的是上游;下游痛:不知道谁依赖于自己;总之,难以实施服务治理
 究竟如何解决上述痛点?一、“配置私藏”架构;二、“全局配置文件”架构;三、“配置中心”架构; 知其然,知其所以然。

本文转自“架构师之路”公众号,58沈剑提供。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

阿里云最有价值专家,是专注于帮助他人充分了解和使用阿里云技术的意见领袖。

官方博客
官网链接
精彩专题