codecamp

配置”也有架构演进?看完深有痛感

一、缘起

随着互联网业务的越来越复杂,用户量与流量越来越大,“服务化分层”是架构演进的必由之路
服务化分层
如上图:站点应用会调用服务,上游服务调用底层服务,依赖关系会变得非常复杂

对于同一个服务,它有多个上游调用。为了保证高可用,一个底层服务往往是若干个节点形成一个集群提供服务
服务集群
如上图:用户中心服务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依赖的服务很多的时候,可能每周都有类似的配合重启需求)。

问题二服务方很痛ta不知道有多少个上游调用了自己(特别是底层基础服务,像用户中心这种,调用ta的上游很多),往往只能通过以下方式来定位上游:
         a)群里吼
         b)发邮件询问
         c)通过连接找到ip,通过ip问运维,找到机器负责人,再通过机器负责人找到对应调用服务
(似曾相识的请转发=_=)
不管哪种方式,都很有可能遗漏,导致ip1一直有流量难以下线,ip4/ip5的流量难以均匀迁移过来。该如何优化呢?

三、全局配置

架构的升级并不是一步到位的,先来用最低的成本来解决上述“修改配置重启”的问题一。
全局配置
“全局配置”法:对于通用的服务,建立全局配置文件,消除配置私藏
1)运维层面制定规范新建全局配置文件,例如/opt/globalconf/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)
配置中心2
当下游服务需要扩容缩容时
4)conf-web配置后台进行设置,新增ip4/ip5,减少ip1
5)conf-center服务将变更的配置推送给已经注册关注相关配置的调用方
6)结合动态连接池组件,完成自动的扩容与缩容

配置中心的好处
1)调用方不需要再重启
2)服务方从配置中心中很清楚的知道上游依赖关系,从而实施按照调用方限流
3)很容易从配置中心得到全局架构依赖关系
痛点一、痛点二同时解决

不足:系统复杂度相对较高,对配置中心的可靠性要求较高,一处挂全局挂

五、总结

解决什么问题?
配置导致系统耦合,架构反向依赖。

什么痛点?
上游痛:
扩容的是下游,改配置重启的是上游
下游痛:不知道谁依赖于自己

配置架构如何演进?
一、配置私藏
二、全局配置文件
三、配置中心

大伙的配置架构进化到第几个步骤啦?欢迎留言。
TCP接入层的负载均衡、高可用、扩展性架构
跨公网调用的大坑与架构优化方案
温馨提示
下载编程狮App,免费阅读超1000+编程语言教程
取消
确定
目录

关闭

MIP.setData({ 'pageTheme' : getCookie('pageTheme') || {'day':true, 'night':false}, 'pageFontSize' : getCookie('pageFontSize') || 20 }); MIP.watch('pageTheme', function(newValue){ setCookie('pageTheme', JSON.stringify(newValue)) }); MIP.watch('pageFontSize', function(newValue){ setCookie('pageFontSize', newValue) }); function setCookie(name, value){ var days = 1; var exp = new Date(); exp.setTime(exp.getTime() + days*24*60*60*1000); document.cookie = name + '=' + value + ';expires=' + exp.toUTCString(); } function getCookie(name){ var reg = new RegExp('(^| )' + name + '=([^;]*)(;|$)'); return document.cookie.match(reg) ? JSON.parse(document.cookie.match(reg)[2]) : null; }