参考:
微信公众号:架构师之路

链接

一分钟了解负载均衡的一切

什么是负载均衡
负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。

常见的负载均衡方案
负载均衡知识总结 - 图1
常见互联网分布式架构如上,分为客户端层、反向代理nginx层、站点层、服务层、数据层。可以看到,每一个下游都有多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现“将请求/数据【均匀】分摊到多个操作单元上执行”。

【客户端层->反向代理层】的负载均衡
负载均衡知识总结 - 图2
【客户端层】到【反向代理层】的负载均衡,是通过“DNS轮询”实现的:DNS-server对于一个域名配置了多个解析ip,每次DNS解析请求来访问DNS-server,会轮询返回这些ip,保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip,以做到每台nginx的请求分配也是均衡的。

【反向代理层->站点层】的负载均衡
负载均衡知识总结 - 图3
【反向代理层】到【站点层】的负载均衡,是通过“nginx”实现的。通过修改nginx.conf,可以实现多种负载均衡策略:
1)请求轮询:和DNS轮询类似,请求依次路由到各个web-server
2)最少连接路由:哪个web-server的连接少,路由到哪个web-server
3)ip哈希:按照访问用户的ip哈希值来路由web-server,只要用户的ip分布是均匀的,请求理论上也是均匀的,ip哈希均衡方法可以做到,同一个用户的请求固定落到同一台web-server上,此策略适合有状态服务,例如session(58沈剑备注:可以这么做,但强烈不建议这么做,站点层无状态是分布式架构设计的基本原则之一,session最好放到数据层存储)
4)…

【站点层->服务层】的负载均衡
负载均衡知识总结 - 图4
【站点层】到【服务层】的负载均衡,是通过“服务连接池”实现的。
上游连接池会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。
上一篇文章《RPC-client实现细节》中有详细的负载均衡、故障转移、超时处理的细节描述,欢迎点击link查阅,此处不再展开。

【数据层】的负载均衡
在数据量很大的情况下,由于数据层(db,cache)涉及数据的水平切分,所以数据层的负载均衡更为复杂一些,它分为“数据的均衡”,与“请求的均衡”。
数据的均衡是指:水平切分后的每个服务(db,cache),数据量是差不多的。
请求的均衡是指:水平切分后的每个服务(db,cache),请求量是差不多的。
业内常见的水平切分方式有这么几种:
一、按照range水平切分
负载均衡知识总结 - 图5
每一个数据服务,存储一定范围的数据,上图为例:
user0服务,存储uid范围1-1kw
user1服务,存储uid范围1kw-2kw
这个方案的好处是:
(1)规则简单,service只需判断一下uid范围就能路由到对应的存储服务
(2)数据均衡性较好
(3)比较容易扩展,可以随时加一个uid[2kw,3kw]的数据服务
不足是:
(1)请求的负载不一定均衡,一般来说,新注册的用户会比老用户更活跃,大range的服务请求压力会更大

二、按照id哈希水平切分
负载均衡知识总结 - 图6
每一个数据服务,存储某个key值hash后的部分数据,上图为例:
user0服务,存储偶数uid数据
user1服务,存储奇数uid数据
这个方案的好处是:
(1)规则简单,service只需对uid进行hash能路由到对应的存储服务
(2)数据均衡性较好
(3)请求均匀性较好
不足是:
(1)不容易扩展,扩展一个数据服务,hash方法改变时候,可能需要进行数据迁移

总结
负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。
(1)【客户端层】到【反向代理层】的负载均衡,是通过“DNS轮询”实现的
(2)【反向代理层】到【站点层】的负载均衡,是通过“nginx”实现的
(3)【站点层】到【服务层】的负载均衡,是通过“服务连接池”实现的
(4)【数据层】的负载均衡,要考虑“数据的均衡”与“请求的均衡”两个点,常见的方式有“按照范围水平切分”与“hash水平切分”

lvs为何不能完全替代DNS轮询

上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注,评论中大家争论的比较多的一个技术点是接入层负载均衡技术,部分同学持这样的观点:
1)nginx前端加入lvs和keepalived可以替代“DNS轮询”
2)F5能搞定接入层高可用、扩展性、负载均衡,可以替代“DNS轮询”
“DNS轮询”究竟是不是过时的技术,是不是可以被其他方案替代,接入层架构技术演进,是本文将要细致讨论的内容。

一、问题域
nginx、lvs、keepalived、f5、DNS轮询,每每提到这些技术,往往讨论的是接入层的这样几个问题:
1)可用性:任何一台机器挂了,服务受不受影响
2)扩展性:能否通过增加机器,扩充系统的性能
3)反向代理+负载均衡:请求是否均匀分摊到后端的操作单元执行

二、上面那些名词都是干嘛的
由于每个技术人的背景和知识域不同,上面那些名词缩写(运维的同学再熟悉不过了),还是花1分钟简单说明一下(详细请自行“百度”):
1)nginx:一个高性能的web-server和实施反向代理的软件
2)lvs:Linux Virtual Server,使用集群技术,实现在linux操作系统层面的一个高性能、高可用、负载均衡服务器
3)keepalived:一款用来检测服务状态存活性的软件,常用来做高可用
4)f5:一个高性能、高可用、负载均衡的硬件设备(听上去和lvs功能差不多?)
5)DNS轮询:通过在DNS-server上对一个域名设置多个ip解析,来扩充web-server性能及实施负载均衡的技术

三、接入层技术演进
【裸奔时代(0)单机架构】
负载均衡知识总结 - 图7
裸奔时代的架构图如上:
1)浏览器通过DNS-server,域名解析到ip
2)浏览器通过ip访问web-server
缺点
1)非高可用,web-server挂了整个系统就挂了
2)扩展性差,当吞吐量达到web-server上限时,无法扩容
注:单机不涉及负载均衡的问题

【简易扩容方案(1)DNS轮询】
假设tomcat的吞吐量是1000次每秒,当系统总吞吐量达到3000时,如何扩容是首先要解决的问题,DNS轮询是一个很容易想到的方案:
负载均衡知识总结 - 图8
此时的架构图如上:
1)多部署几份web-server,1个tomcat抗1000,部署3个tomcat就能抗3000
2)在DNS-server层面,域名每次解析到不同的ip
优点
1)零成本:在DNS-server上多配几个ip即可,功能也不收费
2)部署简单:多部署几个web-server即可,原系统架构不需要做任何改造
3)负载均衡:变成了多机,但负载基本是均衡的
缺点
1)非高可用:DNS-server只负责域名解析ip,这个ip对应的服务是否可用,DNS-server是不保证的,假设有一个web-server挂了,部分服务会受到影响
2)扩容非实时:DNS解析有一个生效周期
3)暴露了太多的外网ip

【简易扩容方案(2)nginx】
tomcat的性能较差,但nginx作为反向代理的性能就强多了,假设线上跑到1w,就比tomcat高了10倍,可以利用这个特性来做扩容:
负载均衡知识总结 - 图9
此时的架构图如上:
1)站点层与浏览器层之间加入了一个反向代理层,利用高性能的nginx来做反向代理
2)nginx将http请求分发给后端多个web-server
优点
1)DNS-server不需要动
2)负载均衡:通过nginx来保证
3)只暴露一个外网ip,nginx->tomcat之间使用内网访问
4)扩容实时:nginx内部可控,随时增加web-server随时实时扩容
5)能够保证站点层的可用性:任何一台tomcat挂了,nginx可以将流量迁移到其他tomcat
缺点
1)时延增加+架构更复杂了:中间多加了一个反向代理层
2)反向代理层成了单点,非高可用:tomcat挂了不影响服务,nginx挂了怎么办?

【高可用方案(3)keepalived】
为了解决高可用的问题,keepalived出场了(之前的文章“使用shadow-master保证系统可用性”详细介绍过):
负载均衡知识总结 - 图10
此时:
1)做两台nginx组成一个集群,分别部署上keepalived,设置成相同的虚IP,保证nginx的高可用
2)当一台nginx挂了,keepalived能够探测到,并将流量自动迁移到另一台nginx上,整个过程对调用方透明
负载均衡知识总结 - 图11
优点
1)解决了高可用的问题
缺点
1)资源利用率只有50%
2)nginx仍然是接入单点,如果接入吞吐量超过的nginx的性能上限怎么办,例如qps达到了50000咧?

【scale up扩容方案(4)lvs/f5】
nginx毕竟是软件,性能比tomcat好,但总有个上限,超出了上限,还是扛不住。
lvs就不一样了,它实施在操作系统层面;f5的性能又更好了,它实施在硬件层面;它们性能比nginx好很多,例如每秒可以抗10w,这样可以利用他们来扩容,常见的架构图如下:
负载均衡知识总结 - 图12
此时:
1)如果通过nginx可以扩展多个tomcat一样,可以通过lvs来扩展多个nginx
2)通过keepalived+VIP的方案可以保证可用性
99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。

这就完美了嘛?还有潜在问题么?
好吧,不管是使用lvs还是f5,这些都是scale up的方案,根本上,lvs/f5还是会有性能上限,假设每秒能处理10w的请求,一天也只能处理80亿的请求(10w秒吞吐量8w秒),那万一*系统的日PV超过80亿怎么办呢?(好吧,没几个公司要考虑这个问题)

【scale out扩容方案(5)DNS轮询】
如之前文章所述,水平扩展,才是解决性能问题的根本方案,能够通过加机器扩充性能的方案才具备最好的扩展性。
facebook,google,baidu的PV是不是超过80亿呢,它们的域名只对应一个ip么,终点又是起点,还是得通过DNS轮询来进行扩容
负载均衡知识总结 - 图13
此时:
1)通过DNS轮询来线性扩展入口lvs层的性能
2)通过keepalived来保证高可用
3)通过lvs来扩展多个nginx
4)通过nginx来做负载均衡,业务七层路由

四、结论
聊了这么多,稍微做一个简要的总结:
1)接入层架构要考虑的问题域为:高可用、扩展性、反向代理+扩展均衡
2)nginx、keepalived、lvs、f5可以很好的解决高可用、扩展性、反向代理+扩展均衡的问题
3)水平扩展scale out是解决扩展性问题的根本方案,DNS轮询是不能完全被nginx/lvs/f5所替代的

末了,上一篇文章有同学留言问58到家采用什么方案,58到家目前部署在阿里云上,前端购买了SLB服务(可以先粗暴的认为是一个lvs+keepalived的高可用负载均衡服务),后端是nginx+tomcat。

五、挖坑
接入层讲了这么多,下一章,准备讲讲服务层“异构服务的负载均”(牛逼的机器应该分配更多的流量,如何做到?)。

如何实施异构服务器的负载均衡及过载保护?

零、需求缘起
第一篇文章“一分钟了解负载均衡”和大家share了互联网架构中反向代理层、站点层、服务层、数据层的常用负载均衡方法。
第二篇文章“lvs为何不能完全代替DNS轮询”和大家share了互联网接入层负载均衡需要解决的问题及架构演进。
在这两篇文章中,都强调了“负载均衡是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】”。

然而,后端的service有可能部署在硬件条件不同的服务器上
1)如果对标最低配的服务器“均匀”分摊负载,高配的服务器的利用率不足;
2)如果对标最高配的服务器“均匀”分摊负载,低配的服务器可能会扛不住;
能否根据异构服务器的处理能力来动态、自适应进行负载均衡及过载保护,是本文要讨论的问题。

一、service层的负载均衡通常是怎么做的
负载均衡知识总结 - 图14
一分钟了解负载均衡”中提到,service层的负载均衡,一般是通过service连接池来实现的,调用方连接池会建立与下游服务多个连接,每次请求“随机”获取连接,来保证service访问的均衡性。
RPC-client实现细节”中提到,负载均衡、故障转移、超时处理等细节也都是通过调用方连接池来实现的。
这个调用方连接池能否实现,根据service的处理能力,动态+自适应的进行负载调度呢?

二、通过“静态权重”标识service的处理能力
负载均衡知识总结 - 图15
调用方通过连接池组件访问下游service,通常采用“随机”的方式返回连接,以保证下游service访问的均衡性。

要打破这个随机性,最容易想到的方法,只要为每个下游service设置一个“权重”,代表service的处理能力,来调整访问到每个service的概率,例如:
假设service-ip1,service-ip2,service-ip3的处理能力相同,可以设置weight1=1,weight2=1,weight3=1,这样三个service连接被获取到的概率分别就是1/3,1/3,1/3,能够保证均衡访问。

假设service-ip1的处理能力是service-ip2,service-ip3的处理能力的2倍,可以设置weight1=2,weight2=1,weight3=1,这样三个service连接被获取到的概率分别就是2/4,1/4,1/4,能够保证处理能力强的service分别到等比的流量,不至于资源浪费。

使用nginx做反向代理与负载均衡,就有类似的机制。
这个方案的优点是:简单,能够快速的实现异构服务器的负载均衡。
缺点也很明显:这个权重是固定的,无法自适应动态调整,而很多时候,服务器的处理能力是很难用一个固定的数值量化。

三、通过“动态权重”标识service的处理能力
提问:通过什么来标识一个service的处理能力呢?
回答:其实一个service能不能处理得过来,能不能响应得过来,应该由调用方说了算。调用服务,快速处理了,处理能力跟得上;调用服务,处理超时了,处理能力很有可能跟不上了。

动态权重设计
1)用一个动态权重来标识每个service的处理能力,默认初始处理能力相同,即分配给每个service的概率相等;
2)每当service成功处理一个请求,认为service处理能力足够,权重动态+1
3)每当service超时处理一个请求,认为service处理能力可能要跟不上了,权重动态-10(权重下降会更快)
4)为了方便权重的处理,可以把权重的范围限定为[0, 100],把权重的初始值设为60分

举例说明:
假设service-ip1,service-ip2,service-ip3的动态权重初始值weight1=weight2=weight3=60,刚开始时,请求分配给这3台service的概率分别是60/180,60/180,60/180,即负载是均衡的。

随着时间的推移,处理能力强的service成功处理的请求越来越多,处理能力弱的service偶尔有超时,随着动态权重的增减,权重可能变化成了weight1=100,weight2=60,weight3=40,那么此时,请求分配给这3台service的概率分别是100/200,60/200,40/200,即处理能力强的service会被分配到更多的流量。

四、过载保护
提问:什么是过载保护?
负载均衡知识总结 - 图16
图示:过载保护的负载与处理能力图(会掉底)
回答:互联网软件架构设计中所指的过载保护,是指当系统负载超过一个service的处理能力时,如果service不进行自我保护,可能导致对外呈现处理能力为0,且不能自动恢复的现象。而service的过载保护,是指即使系统负载超过一个service的处理能力,service让能保证对外提供有损的稳定服务。
负载均衡知识总结 - 图17
图示:过载保护的负载与处理能力图(不会掉底)
提问:如何进行过载保护?
回答:最简易的方式,服务端设定一个负载阈值,超过这个阈值的请求压过来,全部抛弃。这个方式不是特别优雅。

五、如何借助“动态权重”来实施过载保护
动态权重是用来标识每个service的处理能力的一个值,它是RPC-client客户端连接池层面的一个东东。服务端处理超时,客户端RPC-client连接池都能够知道,这里只要实施一些策略,就能够对“疑似过载”的服务器进行降压,而不用服务器“抛弃请求”这么粗暴的实施过载保护。

应该实施一些什么样的策略呢,例如:
1)如果某一个service的连接上,连续3个请求都超时,即连续-10分三次,客户端就可以认为,服务器慢慢的要处理不过来了,得给这个service缓一小口气,于是设定策略:接下来的若干时间内,例如1秒(或者接下来的若干个请求),请求不再分配给这个service;
2)如果某一个service的动态权重,降为了0(像连续10个请求超时,中间休息了3次还超时),客户端就可以认为,服务器完全处理不过来了,得给这个service喘一大口气,于是设定策略:接下来的若干时间内,例如1分钟(为什么是1分钟,根据经验,此时service一般在发生fullGC,差不多1分钟能回过神来),请求不再分配给这个service;
3)可以有更复杂的保护策略…

这样的话,不但能借助“动态权重”来实施动态自适应的异构服务器负载均衡,还能在客户端层面更优雅的实施过载保护,在某个下游service快要响应不过来的时候,给其喘息的机会。

需要注意的是:要防止客户端的过载保护引起service的雪崩,如果“整体负载”已经超过了“service集群”的处理能力,怎么转移请求也是处理不过来的,还得通过抛弃请求来实施自我保护。

六、总结
1)service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的
2)异构服务器负载均衡,最简单的方式是静态权重法,缺点是无法自适应动态调整
3)动态权重法,可以动态的根据service的处理能力来分配负载,需要有连接池层面的微小改动
4)过载保护,是在负载过高时,service为了保护自己,保证一定处理能力的一种自救方法
5)动态权重法,还可以用做service的过载保护

单点系统架构的可用性与性能优化

一、需求缘起

明明架构要求高可用,为何系统中还会存在单点?
回答:单点master的设计,会大大简化系统设计,何况有时候避免不了单点

在哪些场景中会存在单点?先来看一下一个典型互联网高可用架构。
负载均衡知识总结 - 图18
典型互联网高可用架构:
(1)客户端层,这一层是浏览器或者APP,第一步先访问DNS-server,由域名拿到nginx的外网IP
(2)负载均衡层,nginx是整个服务端的入口,负责反向代理与负载均衡工作
(3)站点层,web-server层,典型的是tomcat或者apache
(4)服务层,service层,典型的是dubbo或者thrift等提供RPC调用的后端服务
(5)数据层,包含cache和db,典型的是主从复制读写分离的db架构
在这个互联网架构中,站点层、服务层、数据库的从库都可以通过冗余的方式来保证高可用,但至少
(1)nginx层是一个潜在的单点
(2)数据库写库master也是一个潜在的单点

再举一个GFS(Google File System)架构的例子。
负载均衡知识总结 - 图19
GFS的系统架构里主要有这么几种角色:
(1)client,就是发起文件读写的调用端
(2)master,这是一个单点服务,它有全局事业,掌握文件元信息
(3)chunk-server,实际存储文件额服务器
这个系统里,master也是一个单点的服务,Map-reduce系统里也有类似的全局协调的master单点角色。

系统架构设计中,像nginx,db-master,gfs-master这样的单点服务,会存在什么问题,有什么方案来优化呢,这是本文要讨论的问题。

二、单点架构存在的问题

单点系统一般来说存在两个很大的问题:
(1)非高可用:既然是单点,master一旦发生故障,服务就会受到影响
(2)性能瓶颈:既然是单点,不具备良好的扩展性,服务性能总有一个上限,这个单点的性能上限往往就是整个系统的性能上限

接下来,就看看有什么优化手段可以优化上面提到的两个问题

三、shadow-master解决单点高可用问题

shadow-master是一种很常见的解决单点高可用问题的技术方案。
“影子master”,顾名思义,服务正常时,它只是单点master的一个影子,在master出现故障时,shadow-master会自动变成master,继续提供服务。
shadow-master它能够解决高可用的问题,并且故障的转移是自动的,不需要人工介入,但不足是它使服务资源的利用率降为了50%,业内经常使用keepalived+vip的方式实现这类单点的高可用

负载均衡知识总结 - 图20
以GFS的master为例,master正常时:
(1)client会连接正常的master,shadow-master不对外提供服务
(2)master与shadow-master之间有一种存活探测机制
(3)master与shadow-master有相同的虚IP(virtual-IP)

负载均衡知识总结 - 图21
当发现master异常时:
shadow-master会自动顶上成为master,虚IP机制可以保证这个过程对调用方是透明的

除了GFS与MapReduce系统中的主控master,nginx亦可用类似的方式保证高可用,数据库的主库master(主库)亦可用类似的方式来保证高可用,只是细节上有些地方要注意:
负载均衡知识总结 - 图22
传统的一主多从,读写分离的db架构,只能保证读库的高可用,是无法保证写库的高可用的,要想保证写库的高可用,也可以使用上述的shadow-master机制:
负载均衡知识总结 - 图23
(1)两个主库设置相互同步的双主模式
(2)平时只有一个主库提供服务,言下之意,shadow-master不会往master同步数据
(3)异常时,虚IP漂移到另一个主库,shadow-master变成主库继续提供服务
需要说明的是,由于数据库的特殊性,数据同步需要时延,如果数据还没有同步完成,流量就切到了shadow-master,可能引起小部分数据的不一致。

四、减少与单点的交互,是存在单点的系统优化的核心方向

既然知道单点存在性能上限,单点的性能(例如GFS中的master)有可能成为系统的瓶颈,那么,减少与单点的交互,便成了存在单点的系统优化的核心方向。
怎么来减少与单点的交互,这里提两种常见的方法。
批量写
批量写是一种常见的提升单点性能的方式。
例如一个利用数据库写单点生成做“ID生成器”的例子:
负载均衡知识总结 - 图24
(1)业务方需要ID
(2)利用数据库写单点的auto increament id来生成和返回ID
这是一个很常见的例子,很多公司也就是这么生成ID的,它利用了数据库写单点的特性,方便快捷,无额外开发成本,是一个非常帅气的方案。
潜在的问题是:生成ID的并发上限,取决于单点数据库的写性能上限。
如何提升性能呢?批量写

负载均衡知识总结 - 图25
(1)中间加一个服务,每次从数据库拿出100个id
(2)业务方需要ID
(3)服务直接返回100个id中的1个,100个分配完,再访问数据库
这样一来,每分配100个才会写数据库一次,分配id的性能可以认为提升了100倍。

客户端缓存
客户端缓存也是一种降低与单点交互次数,提升系统整体性能的方法。
还是以GFS文件系统为例:
负载均衡知识总结 - 图26
(1)GFS的调用客户端client要访问shenjian.txt,先查询本地缓存,miss了
(2)client访问master问说文件在哪里,master告诉client在chunk3上
(3)client把shenjian.txt存放在chunk3上记录到本地的缓存,然后进行文件的读写操作
(4)未来client要访问文件,从本地缓存中查找到对应的记录,就不用再请求master了,可以直接访问chunk-server。如果文件发生了转移,chunk3返回client说“文件不在我这儿了”,client再访问master,询问文件所在的服务器。

根据经验,这类缓存的命中非常非常高,可能在99.9%以上(因为文件的自动迁移是小概率事件),这样与master的交互次数就降低了1000倍。

五、水平扩展是提升单点系统性能的好方案

无论怎么批量写,客户端缓存,单点毕竟是单机,还是有性能上限的。
想方设法水平扩展,消除系统单点,理论上才能够无限的提升系统系统。
以nginx为例,如何来进行水平扩展呢?
负载均衡知识总结 - 图27
第一步的DNS解析,只能返回一个nginx外网IP么?答案显然是否定的,“DNS轮询”技术支持DNS-server返回不同的nginx外网IP,这样就能实现nginx负载均衡层的水平扩展。

负载均衡知识总结 - 图28
DNS-server部分,一个域名可以配置多个IP,每次DNS解析请求,轮询返回不同的IP,就能实现nginx的水平扩展,扩充负载均衡层的整体性能。

数据库单点写库也是同样的道理,在数据量很大的情况下,可以通过水平拆分,来提升写入性能。

遗憾的是,并不是所有的业务场景都可以水平拆分,例如秒杀业务,商品的条数可能不多,数据库的数据量不大,就不能通过水平拆分来提升秒杀系统的整体写性能(总不能一个库100条记录吧?)。

六、总结

今天的话题就讨论到这里,内容很多,占用大家宝贵的时间深表内疚,估计大部分都记不住,至少记住这几个点吧:
(1)单点系统存在的问题:可用性问题,性能瓶颈问题
(2)shadow-master是一种常见的解决单点系统可用性问题的方案
(3)减少与单点的交互,是存在单点的系统优化的核心方向,常见方法有批量写,客户端缓存
(4)水平扩展也是提升单点系统性能的好方案

集群信息管理,架构设计中最容易遗漏的一环

准备系统性介绍“技术体系规划”了,这是第一篇。

监控平台,服务治理,调用链跟踪,数据收集中心,自动化运维,自动化测试… 很多要讲,却没想好从哪里入手。

讲Z平台,可能需要提前介绍Y服务;讲Y服务,可能需要提前介绍X知识。

思来想去,准备从技术体系里,最容易被遗漏,非常基础,却又非常重要的“集群信息管理”开始介绍。

由于基础,可能部分同学会觉得简单;由于大家所在公司处于不同阶段,所以在实现上会介绍不同阶段的公司应该如何来实现。

还是一如既往的按照“架构师之路”的思路:

  • 是什么
  • 什么场景,为什么会用到,存在什么问题
  • 常见方案及痛点
  • 不同阶段公司,不同实现方案

希望大伙有收获。

一、啥是集群?
互联网典型分层架构如下:
负载均衡知识总结 - 图29

  • web-server层
  • service层
  • db层与cache层

为了保证高可用,每一个站点、服务、数据库、缓存都会冗余多个实例,组成一个分布式的系统,集群则是一个分布式的物理形态。

额,好拗口,通俗的说,集群就是一堆机器,上面部署了提供相似功能的站点,服务,数据库,或者缓存。
负载均衡知识总结 - 图30
如上图:

  • web集群,由web.1和web.2两个实例组成
  • service集群,由service.1/service.2/service.3三个实例组成
  • db集群,由mysql-M/mysql-S1/mysql-S2三个实例组成
  • cache集群,由cache-M/cache-S两个实例组成

与“集群”相对应的是“单机”。
画外音:关于高可用架构,详见文章《究竟啥才是互联网架构“高可用”》。
画外音:缓存如果没有高可用要求,可能是单机架构,而不是集群。

二、集群信息
什么是集群信息?
一个集群,会包含若干信息(额,这tm算什么解释),例如:

  • 集群名称
  • IP列表
  • 二进制目录
  • 配置目录
  • 日志目录
  • 负责人列表

画外音:集群IP列表不建议直接使用IP,而建议使用内网域名,详见文章《小小的IP,大大的耦合》。

什么时候会用到集群信息呢?
很多场景,特别是线上操作,都会使用到各种集群信息,例如:

  • 自动化上线
  • 监控
  • 日志清理
  • 二进制与配置的备份
  • 下游的调用(额,这个最典型)

这些场景,分别都是如何读取集群信息的?
一般来说,早期会把集群信息写在配置文件里。

例如,自动化上线,有一个配置文件,deploy.user.service.config,其内容是:
name : user.service
ip.list : ip1, ip2, ip3
bin.path : /user.service/bin/
ftp.path : ftp://192.168.0.1/USER_2_0_1_3/user.exe

自动化上线的过程,则是:

  • 把可执行文件从ftp拉下来
  • 读取集群IP列表
  • 读取二进制应该部署的目录
  • 把二进制部署到线上
  • 逐台重启

画外音:啥,还没有实现自动化脚本部署?还处在运维ssh到线上,手动执行命令,逐台机器人肉部署的刀耕火种阶段?赶紧照着这个方案,做自动化改造吧。

又例如,web-X调用下游的user服务,又有一个配置文件,web-X.config,其内容配置了:
service.name : user.service
service.ip.list : ip1, ip2, ip3
service.port : 8080

web-X调用user服务的过程,则是:

  • web-X启动
  • web-X读取user服务集群的IP列表与端口
  • web-X初始化user服务连接池
  • web-X拿取user服务的连接,通过RPC接口调用user服务

日志清理,服务监控,二进制备份的过程,也都与上述类似。

三、存在什么问题?
上述业务场景,对于集群信息的使用,有两个最大的特点

  • 每个应用场景,所需集群信息都不一样(A场景需要集群abc信息,B场景需要集群def信息)
  • 每个应用场景,集群信息都写在“自己”的配置文件里

一句话总结:集群信息管理分散化。

这里最大的问题,是耦合,当集群的信息发生变化的时候,有非常多的配置需要修改:

  • deploy.user.service.config
  • clean.log.user.service.config
  • backup.bin.user.service.config
  • monitor.config
  • web-X.config

这些配置里,user服务集群的信息都需要修改:

  • 随着研发、测试、运维人员的流动,很多配置放在哪里,逐步就被遗忘了
  • 随着时间的推移,一些配置就被改漏了
  • 逐渐的,莫名其妙的问题出现了

画外音:ca,谁痛谁知道

如何解决上述耦合的问题呢?
一句话回答:集群信息管理集中化。

四、如何集中化管理集群信息
如何集中化管理集群配置信息,不同发展阶段的公司,实现的方式不一样。

早期方案
通过全局配置文件,实现集群信息集中管理,举例global.config如下:
[user.service]
ip.list : ip1, ip2, ip3
port : 8080
bin.path : /user.service/bin/
log.path : /user.service/log/
conf.path : /user.service/conf/
ftp.path :ftp://192.168.0.1/USER_2_0_1_3/user.exe
owner.list : shenjian, zhangsan, lisi

[passport.web]
ip.list : ip11, ip22, ip33
port : 80
bin.path : /passport.web/bin/
log.path : /passport.web/log/
conf.path : /passport.web/conf/
ftp.path :ftp://192.168.0.1/PST_1_2_3_4/passport.jar
owner.list : shenjian, zui, shuaiqi

集中维护集群信息之后:

  • 任何需要读取集群信息的场景,都从global.config里读取
  • 任何集群信息的修改,只需要修改global.config一处
  • global.config会部署到任何一台线上机器,维护和管理也很方便

画外音:额,当然,信息太多的话,global.config也要垂直拆分

中期方案
随着公司业务的发展,随着技术团队的扩充,随着技术体系的完善,通过集群信息管理服务,来维护集群信息的诉求原来越强烈。
画外音:慢慢的,配置太多了,通过global.config来修改配置太容易出错了
负载均衡知识总结 - 图31
如上图,建立集群信息管理服务

  • info.db :存储集群信息
  • info.cache :缓存集群信息
  • info.service :提供集群信息访问的RPC接口,以及HTTP接口
  • info.web :集群信息维护后台

服务的核心接口是:
Info InfoService::getInfo(String ClusterName);
Bool InfoService::setInfo(String ClusterName, String key, String value);

然后,统一通过服务来获取与修改集群信息:

  • 所有需要获取集群信息的场景,都通过info.service提供的接口来读取集群信息
  • 所有需要修改集群信息的场景,都通过info.web来操作

长期方案
集群信息服务可以解决大部分的耦合问题,但仍然有一个不足:集群信息变更时,无法反向实时通知关注方,集群信息发生了改变。更长远的,要引入配置中心来解决。
负载均衡知识总结 - 图32
配置中心的细节,网上的分析很多,之前也撰文写过,细节就不再本文展开。

五、总结
集群信息管理,是架构设计中非常容易遗漏的一环,但又是非常基础,非常重要的基础设施,一定要在早期规划好:

  • 传统的方式,分散化管理集群信息,容易导致耦合
  • 集中管理集群信息,有全局配置,信息服务,配置中心三个阶段

六、调研
调研一、对于集群信息管理,你的感受是:

  • ca,没考虑过这个问题,一直是分散式管理
  • 在使用全局配置文件
  • 在使用信息管理服务
  • 在使用配置中心

调研二、对于自动化运维,你的感受是:

  • ca,啥是运维,都是研发在线上乱搞
  • 有专门的运维,但一直是人肉运维
  • 运维在使用脚本,实现了自动化
  • 运维都下岗了,在使用平台,实现了平台化