不止是上云，更是上岸

Original 常耀国腾讯云原生

收录于合集

常耀国，腾讯SRE专家，现就职于PCG-大数据平台部，负责千万级QPS业务的上云、监控和自动化工作。

背景

BeaconLogServer 是灯塔 SDK 上报数据的入口，接收众多业务的数据上报，包括微视、 QQ 、腾讯视频、 QQ 浏览器、应用宝等多个业务，呈现并发大、请求大、流量突增等问题，目前 BeaconLogServer 的 QPS 达到千万级别以上，为了应对这些问题，平时需要耗费大量的人力去维护服务的容量水位，如何利用上云实现 0 人力运维是本文着重分析的。

混合云弹性伸缩

弹性伸缩整体效果

首先谈一下自动扩缩容，下图是 BeaconLogServer 混合云弹性伸缩设计的方案图

弹性伸缩方案

资源管理

先从资源管理讲起，目前 BeaconLogServer 节点个数是8000多个，需要的资源很大，单独依靠平台的公共资源，在一些节假日流量突增的时候，可能无法实现快速的扩容，因此，经过调研123平台（PAAS 平台）和算力平台（资源平台），我们采用了混合云的方式，来解决这个问题。分析 BLS 业务场景，流量突增存在下面两种情况：

日常业务负载小幅度升高，时间持续较短
春节业务负载大幅度升高，并持续一段时间针对上述的业务场景，我们采用三种资源类型来应对不同场景，具体如下表所述：

类型	场景	set
公共资源池	日常业务	bls.sh.1
算力平台	小高峰	bls.sh.2
专用资源池	春节	bls.sh.3

日常业务我们使用公共资源池+算力资源，当业务的负载小幅度上升的话，使用算力资源快速扩容，保障服务的容量水位不超过安全阈值。面对春节负载大幅度升高，这时需要构建专有资源池来应对春节的流量升高。

弹性扩缩容

上文阐述了资源的管理，那么针对不同的资源，何时开始扩容，何时开始缩容？

BeaconLogServer 日常的流量分布是 123 平台公共资源：算力平台=7:3。目前设置的自动扩容的阈值是60%，当 CPU 使用率大于60%，平台自动扩容。弹性扩缩容依赖的是 123 平台的调度功能，具体的指标设置如下：

类型	CPU自动缩容阈值	CPU自动扩容阈值	最小副本数	最大副本数
123平台公共资源池	20	60	300	1000
算力平台	40	50	300	1000
123平台专有资源池	20	60	300	1000

可以看到算力平台自动缩容阈值较大，自动扩容阈值较小，主要考虑算力平台是应对流量突增的情况，而且算力平台资源经常替换，因此优先考虑先扩容或缩容算力平台的资源。最小副本数是保障业务所需的最低资源需求，如果少于这个值，平台会自动补充。最大副本数设置1000，是因为 IAS 平台（网关平台）一个城市支持的最大 RS 节点数是1000。

问题及解决

方案推进的过程中，我们也遇到了很多问题，挑选几个问题和大家分享一下。

1）首先从接入层来讲，之前接入层业务使用的是 TGW ， TGW 有一个限制，就是RS的节点不能超过200个，目前 BeaconLogServer 的节点是8000多个，继续使用 TGW 需要申请很多个域名，迁移耗时多且不便于维护。我们调研接入层 IAS ， IAS 四层每个城市支持的节点个数是1000个，基本可以满足我们的需求，基于此，我们设计如下的解决方案如下：

总体上采用“业务+地域”模式分离流量。当集群中一个城市的 RS 节点超过500个就需要考虑拆分业务，例如公共集群的节点超出阈值，可以把当前业务量大的视频业务拆分出来，作为一个单独的集群；如果是一个独立集群的业务节点超出阈值，先考虑增加城市，把流量拆分到新的城市。如果无法新增城市，此时考虑新增一个 IAS 集群，然后在 GLSB 上按照区域把流量分配到不同的集群。

2）同一个城市不同的资源池设置不同的 set，那么IAS如何接入同一个城市不同 set 呢？北极星本来有[通配组功能]，但是 IAS 不支持 set 通配符功能实际上，我们推动 IAS 实现了通配组匹配，例如使用 bls.sh.% 可以匹配 bls.sh.1 , bls.sh.2 , bls.sh.3 。注意， IAS 通配符和北极星的不一样，北极星使用的是***， IAS 在上线的时候发现有用户使用*做单独匹配，所以使用%来表示通配符。

3）资源管理这块遇到的难点是 IAS 四层无法使用算力资源的节点，后面在经过沟通，打通了 IAS 到算力资源的。这里的解决方案是使用 SNAT 能力。

此方案的注意事项

只能绑定 IP 地址，无法拉取实例，实例销毁也不会自动解绑，需要通过控制台或 API 主动解绑（已跨账号，拉取不到实例）
如果是大规模上量：过哪些网关、哪些容量需要评估、风险控制，需要评估

单机故障自动化处理

单机故障处理效果

单机故障自动化处理，目标是实现0人力维护，如下图是我们自动化处理的截图。

单机故障处理方案

单机故障主要从系统层面和业务层面两个维度考虑，详情如下：

维度	告警项
系统层面	CPU
系统层面	内存
系统层面	网络
系统层面	磁盘
业务层面	ATTA Agent不可用
业务层面	队列过长
业务层面	发送atta数据成功率

针对单机故障，我们采用的是开源的 Prometheus +公司的 Polaris（注册中心）的方式解决。Prometheus 主要是用来采集数据和发送告警，然后通过代码把节点从 Polaris 摘除。

至于告警发生和告警恢复的处理，当告警发生的时候，首先会判断告警的节点个数，如果低于三个以下，我们直接在 Polaris 摘除节点，如果大于3个，可能是普遍的问题，这时候我们会发送告警，需要人工的介入。当告警恢复的时候，我们直接在平台重启节点，节点会重新注册 Polaris 。

ATTA Agent 异常处理

如图所示，处理流程是两条线，告警触发和告警恢复，当业务异常的时候，首先判断当前异常节点的数量，保证不会大范围的摘掉节点。然后在北极星摘除节点。当业务恢复的时候，直接重启节点。

问题及解决

主要的难点是 Prometheus Agent 的健康检查和 BeaconLogServer 节点的动态变化，对于第一个问题，目前主要是由平台方负责维护。对于第二个问题，我们利用了定时脚本从 Polaris 拉取节点和 Prometheus 热加载的能力实现的。

总结

此次上云有效的解决了自动扩缩容和单机故障这两块的问题，减少了手动操作，降低了人为操作错误风险，提升系统的稳定性。通过此次上云，也总结了几点：

迁移方案：上云之前做好迁移方案的调研，特别是依赖系统的支持的功能，降低迁移过程因系统不支持的系统性风险。
迁移过程：做好指标监控，迁移流量之后，及时观测指标，出现问题及时回滚。

互动赢好礼

精读文章，回答问题赢好礼

Q1：0人力运维是否是伪命题？

Q2：目前大环境都在上云，那么在上云的过程中，各位遇到的问题和解决的方式可以分享一下。

12月1日上午11点，由作者选出回答最佳的5位读者，送腾讯定制“猿”T恤一件。

往期精选推荐

点个“在看”每天学习最新技术