海量服务实践：手 Q 游戏春节红包项目设计与总结（下篇）

接上篇《海量服务实践：手 Q 游戏春节红包项目设计与总结（上篇）》

5.系统保障

第四部分讲述了业务需求的开发，但是否功能开发完成后我们就这样就可放到线上安心睡大觉了呢？

如果出现一部分机器乃至整个机房挂了，服务是否可用？

外部的服务突然故障了，比如 MQ 突然挂了，不能写入消息了，服务是否可用？

说是红包入口流量 8W/s，万一来了 20W/s 呢？系统会不会挂掉？服务是否可用？

以下从系统容灾/过载保护/柔性可用/立体监控来讲我们这方面做的一些工作，我们对于除夕当天出现各种问题系统还能正常运行，用户能正常体验服务的信心从何而来？

5.1.系统容灾

容灾就是在整体服务一部分出现异常时，另一部分能顶上，不影响整体服务的使用，保障业务可用、数据安全。但容灾设计会使得系统复杂度增加，成本和代价也增加，需要额外的开销和资源，应该在合理的范围内考虑容灾。

容灾级别一般划分为多机容灾、多机房容灾，多地容灾，红包的后台服务主要使用公用组件的均衡负载和系统容灾能力，服务无单点问题，采用同地多机房部署，按多机房容灾标准设计。

5.1.1.接入层

典型的 GSLB+TGW+QZHTTP 接入，GSLB 解析域名把请求带到离用户最近的 IDC 的 TGW 接入机，TGW 再通过内网专线，把请求转发到实际提供 WEB 服务的 QZHTTP 服务器上。

• GSLB：Global Server Load Balance 的首字母缩写，意为全局负载均衡，主要提供提供域名解析的就近接入和流量调度。实现在广域网（包括互联网）上不同地域的服务器间的流量调配，保证使用最佳的离自己最近的客户服务器服务，从而确保访问质量；它对服务器和链路进行综合判断来决定由哪个地点的服务器来提供服务，实现异地服务器群服务质量的保证。红包使用独立的 sh.vip.hongbao.qq.com 域名。
• TGW：Tencent Gateway，是一套实现多网统一接入，支持自动负载均衡的系统，TGW 把外网不同运营商的请求，通过内网隧道转发给 server，server 返回数据时，再把数据通过内网隧道返回给 TGW，再由 TGW 发送给不同的运营商。红包 TGW 外网部署了上海电信联通双 VIP+中国香港 CAP VIP。
• QZHTTP：Web 服务器，负责将 HTTP 请求转成逻辑层使用的 WUP 协议，采用同地多机房部署部署。QZHTTP 作为 TGW 的 RS，TGW 会周期性的探测 RS 的状态，在 1 分钟内自动把故障 RS 从可服务列表中踢除，当 TGW 检测到 RS 恢复正常后，自动把它加回可服务列表中。由 TGW 提供负载均衡和容灾。

5.1.2.逻辑层

逻辑层使用 SPP 容器开发，礼包列表/区服选择/礼包发货三个功能均是无状态服务，多个服务器在服务容量足够的情况下任意踢掉一部分都不会影响正常服务，使用 L5 进行负载均衡/容灾/过载保护。

• L5：机器级别容灾，业务程序调用 L5 API 从 L5 Agent 获取后台服务器的(IP, Port)，使用该(IP, Port)对应的后台服务器进行通信，访问结束时调用 L5 API 上报访问接口和处理时延，L5 Agent 对 L5 API 上报的访问结果和处理时延进行统计和上报，当服务器出现故障，L5 一般在 1 到 2 分钟内就会自动剔除故障服务器。

5.1.3.数据层

数据层主要使用了作为 K-V 存储的 CMEM 和作为分布式消息队列的 RocketMQ，这两种服务都采用接入层-存储层划分，逻辑层访问数据层的接入层使用 L5 进行负载均衡/容灾，数据层的存储层都采用一主一备双机热备容灾，并落地磁盘支持掉电重启后重建内存数据，支持多机容灾但是不支持多机房多地容灾。

5.2.过载保护

红包入口流量说是 8W/s，万一基础侧有问题发到了 20W/s 怎么办？

每个模块的容量都是从入口流量按照用户行为漏斗模型推算转化率设计的，万一评估有误转化率偏高超过了设计容量怎么办？

对于可能出现的超过了设计容量的流量尖峰，就要应用过载保护方法，保障系统能拒绝超过容量的部分请求，保障设计容量内的请求还能正常响应，实施的时候有四个要注意的地方：

• 从源头上减少无效请求；
• 从接入层开始拒绝；
• 各层互相不信任；
• 要照顾用户的情绪。

5.2.1.流量预加载

CDN 做为页面访问的关键路径，前端页面制作离线包，预先下发到客户端，减少除夕当天 CDN 的流量压力。

5.2.2.频率限制

前台对用户发起请求的频率进行限制，超出频率的请求提示用户失败而不走到后台（每 5 秒只允许请求一次到后台），前台保护后台。

后台接入层根据压测数据配置 CGI 接口的每分钟接受的请求数，超出接口处理能力的请求丢弃并进行告警。接入门神系统，配置 IP/uin/refer 等规则限制恶意用户刷请求，保障服务的正常运行。

5.2.3.降级开关

前台调用后台的接口，设置开关以一定概率丢弃请求，对于关键路径返回错误提示用户稍后重试，对于非关键路径提供降级体验，结合频率限制功能，可以限制前台的流量传递到后台的比例，当比例设为 0 的时候则关闭该模块，实现前台保护后台。

5.2.4.队列堆积丢弃

后台逻辑层使用 SPP 框架，worker 处理消息前先检查消息在 SPP 消息队列中等待时间是否超出了预设阈值（500ms），在队列中堆积过久的消息前端已经超时，对于用户已经无意义，服务丢弃请求并进行告警，预防队列式过载雪崩。

5.3.柔性可用

柔性可用，柔性是为了保护系统，保证系统整体的稳定性，可用性。可用是为了用户，尽最大努力为用户提供优质的体验（可能是部分服务体验）。一个是从系统本身角度出发，一个是从用户角度看，在真正实施过程中只有将两者分析清，并融合在一起才能真正做到系统的柔性可用。关键问题是找准用户的核心诉求，找出符合求场景的核心诉求作为关键路径，出现异常可以放弃的诉求作为非关键路径。

5.3.1.找准用户的核心诉求

春节游戏红包用户的核心诉求有三个：

• 看到礼包列表
• 选择区服角色
• 领取礼包到账

其他的都可以作为非关键路径，有可以提高用户体验，没有也不影响用户的核心诉求。

5.3.2.保障关键路径的可用

• 看到礼包列表：作为页面关键模块的礼包列表，在红包活动前，十种游戏的礼包内容作为前端静态数据已经预先通过离线包/CDN下发。红包活动时，后台接口根据用户偏好返回的游戏礼包列表，只是提供前端礼包内容进行过滤和排序，失败了也有前端默认的游戏礼包列表，用户依旧能看到礼包列表，只是排序不够智能化。
• 选择区服角色：除夕前一周游戏中心的主站页面和运营活动增加一个后台接口请求，预先请求用户的区服角色信息缓存到本地，既降低了除夕当天的区服接口请求量又保证了游戏中心核心用户的区服信息是有效的。
• 领取礼包到账：RocketMQ对于领取操作是关键路径服务，用户领取礼包后需要写入RocketMQ才能算成功。故业务对消息队列做了逻辑层面的容灾，当RocketMQ出现故障时，可以打开容灾开关，领取操作写完应发流水后直接返回成功，不再往RocketMQ写入消息，采用分时段对账的方法替代实时发货，达到消息队列容灾效果，参见4.3.容错需求开发。

5.3.3.放弃异常的非关键路径

• 前端页面展示模块化，对于请求数据不成功的非关键模块进行隐藏
• 红包页面导流到游戏中心，游戏中心展示按红点逻辑展示，只显示第一屏的数据，默认不加载第二屏数据，用户往下滚动时再加载，牺牲用户往下滚动会短暂卡顿的体验减少后台的请求压力。
• 后台读取算法接口返回的推荐排序失败时使用默认的礼包排序
• 后台读取CMEM接口返回的礼包是拉活跃还是拉新失败的时每款游戏默认返回低价值的拉活跃礼包

5.4.立体监控

“我们对外提供的服务是否正常的么？怎么证明我们的服务是没有问题的？”，是监控告警首先要回答的根本问题。有效的监控告警需要保证能完备地监测业务指标，当发现问题时能有效通知负责人并帮助分析问题，强调的是“完备性”和“有效通知”，两者缺一不可。春节红包的监控告警从用户、业务和机器三个层面上描述。

5.4.1 用户层面

从用户的角度监控系统是否有问题，模拟用户行为从系统外部发起请求，判断请求结果和时延是否符合预期，使用的是ATT的自动化用例。

ATT，autotest，是社交、开放平台测试组使用的测试管理工具，它是功能用例、自动化用例管理的平台。通过模拟真实的用户访问并校验返回数据，确认访问延时、功能正确性的用户层的监控手段，从业务侧进行实施监控功能的正常运行状态的工具。

5.4.2 业务层面

监控红包系统内部的各个子业务模块是否运行正常，分为两种：

• 模块间的调用监控

监控系统内部各个模块间的调用是否正常，使用的是模调系统。

• 模块内的状态监控

监控某个业务模块当前的状态是否正常，使用的是各个子系统自建的监控告警系统，春节红包这方面的监控主要有两个：AMS礼包领取剩余数量和消息队列消息堆积数量。春节红包由于准备的礼包数量较为充足，故没有引起告警；队列由于生成速度远超消费速度，设置的告警阈值是100W，但实际最终堆积超过了1200W，引发了告警。

5.4.3 机器层面

监控机器的CPU/内存/磁盘/网络是否正常，使用的是网管系统。 网管系统(TNM2)是一个功能非常强大的采集服务器CPU、内存、网络、IO等指标的监控系统，同时还能对设备的进程和端口异常、磁盘使用率、硬件故障等进行告警，同时对外部系统提供功能丰富的调用接口，关于网管系统的监控能力，请参考其网站首页的TMP监控能力白皮书 。

6.演习验证

演习是一种将被动相应转换为主动服务的手段，在演习前设定演习目标和演习方法，在演习过程中进行验证并收集数据，在演习后进行总结并提出改进方案。通过演习，可以实际验证用户行为与评估预期是否一致（灰度演习），系统各个模块的容量是否符合预期（压测演习），各类容灾和柔性的措施是否生效（异常演习），提前发现架构中存在的问题。

6.1.灰度演习

核心问题：实际的用户行为与评估预期是否一致

已知游戏红包的入口流量设定是最大80k/s，红包系统内的各个模块需要支持的流量是多少？每个模块要部署多少机器以支持多大的流量？这个就要涉及到对用户行为和各个模块的转化率的评估？

解决方案：现网灰度用户收集数据进行验证

在现网灰度一部分用户对游戏红包进行验证，收集数据修正评估模型。结果如下：

• 入口卡券也到游戏礼包列表页的转化率评估为60%，实际为59%，评估与实际相当接近。
• 区服组件数据前端有缓存，评估请求缓存命中率为60%，请求到后台的比例为40%，实际为45%，评估与实际相当接近。
• 游戏礼包列表页有10款游戏，评估每个用户平均会领取2个礼包，实际为0.23个礼包，评估与实际有很大出入。

从以上三个接口的流量评估来看，我们的开发和产品根据以往经验评估的用户行为数据大部分还是比较接近实际情况，但也有不太好评估的接口的灰度数据跟评估预期相差很大。根据灰度数据我们重新修正了评估模型和模块容量设计，极大地节约了领取接口的机器。活动当天的数据与灰度得到的数据相差无几，也证明了灰度验证手段是确切可靠的。

6.2.压测演习

核心问题：系统能否抗住压力

细分又可以划为两个问题：

• 对于系统容量内的合理请求，系统能否正常处理
• 对于系统容量外的超额请求，系统能否成功丢弃

解决方案：全链路压测和单模块压测

最理想的情况是先红包各个模块的进行压测后评估没有问题，再灰度用户使用现网流量进入红包系统进行全链路压测，但由于使用现网流量进行演习需要实际地发送红包，成本较高，灰度 500 万用户红包入口峰值仅为 5k/s，远低于设计的 80k/s。故对系统的压力测试验证主要以单模块压测结合灰度演习得到的用户行为数据评估系统的整体能力。

• 对于未上线的接口的 CGI Server 和 SPP Server，采用 ApachBenchmark 模拟请求压测
• 对于已经上线的接口，除了隔离现网机器用 ApachBenchmark 模拟请求压测外，还使用了小组自研的压测系统，通过调整 L5 权重把现网流量逐步导到一台机器上来进行压测

经验证，在 V8 的机器上，礼包列表/区服接口 CGI/Server的QPS 在 5k/s~8k/s 之间，礼包领取接口达到 2k/s 的 QPS。在部署足够的机器后，对于系统 80k/s 的请求量，是可以正常处理的。

在配置了接入层 CGI 的限速选项后，超出限速(8k/s)的超额请求会被 CGI 直接返回错误而不传递到后端处理；在配置了逻辑层 SPP 的超时丢弃后，在队列中堆积超过超时时间(500ms)的堆积请求会被框架丢弃而不进行实际处理。对于超出系统容量的请求，系统是可以成功丢弃的。

6.3.异常演习

核心问题：系统发生异常时各种柔性逻辑/容灾措施能否生效

系统中的柔性/容灾措施，往往只有系统异常时才会生效，导致在实际现网服务运行中，柔性逻辑经常无法测试到，容灾措施一般也不会启用。这样，当运营环境真正异常时，柔性逻辑/容灾措施是否有效还是个未知数。

解决方案：验证柔性逻辑和容灾措施

在红包正式上线前，通过模拟故障发生的真实异常场景，列出重点可能发生的故障问题，验证柔性逻辑和容灾错误是否真实有效。

• 后台 SPP 修改神盾的 L5 为错误的 L5，SPP 调用神盾出错，预期后台依旧能按默认排序返回礼包列表。
• 后台 SPP 修改 CMEM 的 L5 为错误的 L5，SPP 调用 CMEM 出错，预期后台依旧能按全部游戏推荐拉活跃礼包返回礼包列表。
• 后台随机停掉一台 SPP，CGI 调用 SPP出错，预期服务短时间内有部分失败，L5 能在 1~2 分钟内踢掉该出错机器，服务恢复正常。
• 打开 MQ 容灾开关，用户领取成功消息不再放入 MQ，而是直接走流水对账，预期游戏能够成功到账。
• 前台用户操作频率超过了限制（5 次/秒），预期前台直接返回领取失败，抓包看到请求不走到后台。
• 前台调用后台接口通过设置 host 指向错误 IP，前台调用后台推荐接口出错，预期前端页面依然能正确显示作为关键路径的礼包列表。
• 前台调用后台接口通过设置 host 指向错误 IP，前台调用后台非关键信息接口出错，预期前端页面对非关键模块进行隐藏。

经测试同学验证，checklist 中的柔性逻辑和容灾措施确切有效，符合预期。

7.总结

三个系统功能：礼包列表/区服选择/礼包发货

四个开发阶段：功能开发/性能开发/容错开发/监控开发

四种业务保障：系统容灾/过载保护/柔性可用/立体监控

三场演习验证：灰度演习/压测演习/异常演习