背景介绍
在服务刚启动的时候,服务的运行状态并没有达到最佳,如果一下子将流量提升到日常运行的状态,会存在大量的请求超时。
为什么服务刚启动的时候,服务不是最佳状态呢?
- JAVA应用类加载是按需加载的,在服务刚启动的时候,只会加载启动过程中需要的类;当服务接口被调用的时候,才会加载、初始化接口用到的类;对于热点代码,存在一个字节码解释执行到本地机器码执行的过程。
- Java应用需要与依赖的数据库创建连接,与数据库的连接不仅仅是建立一个TCP连接,还涉及用户认证、权限校验、数据库资源分配等,是一个比较耗时的操作。
- Java应用与依赖的redis、HSF服务都要做初始化工作… …
为了服务达到最佳状态,我们通过调整服务权重慢慢增加流量,经过一段时间的小流量预热,让系统达到最佳运行状态。
某天我决定干这个事,我将权重由1调整到2,系统正常;由2调整到4,系统正常;将权重调整到9的时候,故障出现了。
故障描述
将权重调整到9,网关将流量都打到了30多台机器上(一共168台机器),接着应用不断发生CMS GC,接口成功率直线下降。
下游没流量的机器
下游没流量的机器
下游机器接口成功率
下游机器接口成功率
分析过程
因为提前完全没有想到发生这种情况,一点预案也没有。后来冷静下来,想明白:这不应该是应用侧的问题,调整个权重就被打挂似乎没有这种道理。
系统交互关系
系统交互图
第4步-List<Host>
机器不健康的时候,注册中心会剔除掉问题机器;机器恢复健康后,注册中心会再次将机器加入到列表中,【机器列表的顺序不会改变】。
举例说明:
- A1、A2、A3、A4(权重都是1)已经注册到注册中心,状态健康;
- A1发送心跳失败(网络超时/服务hang住等原因),client从注册中心获取的机器列表是:A2、A3、A4;
- A1发送心跳成功(恢复健康状态),client从注册中心获取的机器列表是:A1、A2、A3、A4。
第5步-构造下游机器列表
网关从注册中心拿到List<Host>后,构造下游机器列表的逻辑:
构造下游机器列表
举例说明:
List<Host>中共有A1、A2、A3、A4四台机器,每台机器权重是3,该方法构造出的下游机器列表是:
[A1,A1,A1,A2,A2,A2,A3,A3,A3,A4,A4,A4]
第6步-选择一台下游机器
当网关收到第一个请求的时候,选择下游机器列表的第一个机器;
当网关收到第二个请求的时候,选择下游机器列表的第二个机器;
依次轮询下游机器列表。
轮询逻辑
小结
每当某台机器向注册中心发送心跳超时的时候,该接口在注册中心对于的机器列表就会变化;
网关会获取该接口新的机器列表List<Host>,并根据List<Host>重新构造一个新的下游机器列表;
新的请求会按照下游机器列表的顺序轮询发送到后端业务机器上。
故障场景复盘
基本信息
业务应用有168台机器,定义为:A1,A2,A3… …A168;
网关有大概600台机器。
场景复盘
- 业务应用将权重调整为【9】;
- 网关机器列表(所有网关机器上都是这个列表)变更为:[A1,A1,A1…A1,A2,…A2,…A168,A168,A168…A168],列表中有9个A1,9个A2,9个A3,…,9个A168,计数设置为【0】;
- 单台网关机器QPM:300,【2】中数组每台机器对应9个元素,由于网关是轮询策略,所以一分钟的流量【整个集群的】打到了【300/9=33】台机器上;
- 由于流量打到了30多台机器上,机器负载迅速增大->发生了CMS GC,系统hang住,进而导致业务应用向注册中心发送心跳失败,注册中心通知网关机器列表变更,流程回到了第【2】步。
声明:本站部分内容及图片来自互联网,转载是出于传递更多信息之目的,内容观点仅代表作者本人,不构成投资建议。投资者据此操作,风险自担。如有任何标注错误或版权侵犯请与我们联系,我们将及时更正、删除。