关于腾讯云:不止是上云更是上岸

作者

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

背景

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

混合云弹性伸缩

弹性伸缩整体成果

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

弹性伸缩计划

资源管理

先从资源管理讲起，目前 BeaconLogServer 节点个数是 8000 多个，须要的资源很大，独自依附平台的公共资源，在一些节假日流量突增的时候，可能无奈实现疾速的扩容，因而，通过调研 123 平台（PAAS 平台）和算力平台（资源平台），咱们采纳了混合云的形式，来解决这个问题。
剖析 BLS 业务场景，流量突增存在上面两种状况：

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

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

弹性扩缩容

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

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

能够看到算力平台主动缩容阈值较大，主动扩容阈值较小，次要思考算力平台是应答流量突增的状况，而且算力平台资源常常替换，因而优先思考先扩容或缩容算力平台的资源。最小正本数是保障业务所需的最低资源需要，如果少于这个值，平台会主动补充。最大正本数设置 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 人力保护，如下图是咱们自动化解决的截图。

单机故障解决计划

单机故障次要从零碎层面和业务层面两个维度思考，详情如下：

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

至于告警产生和告警复原的解决，当告警产生的时候，首先会判断告警的节点个数，如果低于三个以下，咱们间接在 Polaris 摘除节点，如果大于 3 个，可能是广泛的问题，这时候咱们会发送告警，须要人工的染指。当告警复原的时候，咱们间接在平台重启节点，节点会从新注册 Polaris。

ATTA Agent 异样解决

如图所示，解决流程是两条线，告警触发和告警复原，当业务异样的时候，首先判断以后异样节点的数量，保障不会大范畴的摘掉节点。而后在北极星摘除节点。当业务复原的时候，间接重启节点。

问题及解决

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

总结

此次上云无效的解决了主动扩缩容和单机故障这两块的问题，缩小了手动操作，升高了人为操作谬误危险，晋升零碎的稳定性。通过此次上云，也总结了几点：

• 迁徙计划：上云之前做好迁徙计划的调研，特地是依赖零碎的反对的性能，升高迁徙过程因零碎不反对的系统性危险。
• 迁徙过程：做好指标监控，迁徙流量之后，及时观测指标，呈现问题及时回滚。

对于咱们

更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~

福利：

①公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~

②公众号后盾回复【系列】，可取得《15 个系列 100+ 篇超实用云原生原创干货合集》，蕴含 Kubernetes 降本增效、K8s 性能优化实际、最佳实际等系列。

③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！