十亿人都在用的健康码，运维体系是怎么设计的？

问题导读：

1、设计一个稳定的架构需要考虑哪些方面？
2、怎样设计一个可观测体系？
3、常见的保护能力有哪些？



业务背景
疫情三年，奥密克戎已是强弩之末，疫情终将过去。历经数个阶段的迭代，腾讯健康码产品服务于十余个省份的居民，数亿用户、数百亿次亮码。有效助力保障公共卫生安全。全国健康码共累计PV2k多亿，亮码1k多亿，最大省份的健康码用户量超过1亿，DAU过千万。

随着疫情防控模式的迭代，健康码访问DAU逐渐趋于下跌，意味着健康码将逐步完成历史使命，淡出历史舞台。本文就曾经在健康码业务运营过程中的保障技术手段进行了回顾，欢迎有兴趣的读者在评论区一起探讨。

技术架构体系

一个稳定的架构是设计与运维出来的，为了达到稳态运行，设计上考虑了以下几个方面：

1）选用合适的云原生产品

健康码本身是要求高可用、高并发的应用，为了满足业务稳定上线、快速上线的需求，我们采用了腾讯云的公有云/私有化产品解决方案。以下是健康码上线时碰到的几大类问题：

• 带宽容量问题
  

由于系统需要大容量的承载能力，导致地方政务云资源供给能力不足。表现如公网出口防护能力不足（如经常性面对境外DDOS攻击/CC攻击），IDC出口设备每秒新建连接数不够等。我们采用了DDoS高防包/waf/ecdn等方案来满足。DDoS高防包与Waf产品有效抵挡住境内外的DDoS攻击、Web攻击、入侵、漏洞利用、挂马、篡改、后门、爬虫等网站及 Web 业务安全防护问题；ECDN产品通过静态资源缓存有效降低混合云场景下政务云入口新建连接数、带宽。也提升了用户的访问体验。

• 开发及部署效率问题
  

疫情的需求迭代较快，如果从头开始开发产品，时间上不允许。腾讯云TCB产品做为一站式云原生解决方案，更加贴近小程序/Web 应用开发场景，使开发人员能快速构建完整项目、针对场景快速优化定制且集中管理，各产品间无需耗费时间精力分别配置与打通，无需切换多款云产品的控制台进行使用。

• 云资源成本问题
  

云产品拥有较大的共享资源冗余，能够快速达成大容量，同时深度采用云原生产品，能够带来较大程度的成本节约。例如采用scf云函数，无需在购买云服务器的情况下运行代码，使用腾讯云的能力弹性、安全地运行代码。无需冗余资源闲时运行成本买单，同时因为云原生产品具有天然的跨可用区容灾能力，基于云原生的两地三中心架构设计，基于腾讯云公有云通常可以满足的高可用能力如：从负载层采用CLB的跨可用区高可用能力进行可用区容错；应用层TSF/TKE/CKAFKA的多可用区高可用能力容错；存储层采用TDSQL多可用区部署及主从同步能力满足高可用与容灾。

2）立体化监控体系设计

完整的监控体系，对提升系统SLA有非常重要的作用。一方面监控系统具有提前业务事件预警能力。最有效的监控体系能在业务发生故障前有效预警，从而知会SRE提前介入处置，防止事件扩大成故障，从而降低高故障数量。另一方面在发生故障后，能够评估故障影响程度、有效追踪异常点，引导技术人员介入处置，提升系统故障恢复SLA。

3）系统压力测试、混沌工程、应急预案等多方面检验

随着业务系统逐渐趋于成熟，要保障常规运行过程中的稳定性， 需要周期性保持对系统的应急演练工作。一方面通过压力测试、破怀性测试来检验系统的承受能力。另一方面通过这些演练来检验运维人员团队在面对业务事件时的响应质量、处置预案是否成熟与合规。

可观测体系

可观测能力做为基础技术能力，在健康码运维中是不可缺少的一部分。优秀的可观测体系能够帮助业务及时、准确地发现故障，亦能在故障诊断过程中追根溯源，及时协助问题定位、从而加速故障恢复。

健康码产品基于腾讯云PAAS产品构建，系统的可观测点一般可基于以下能力构建：首先，采用了腾讯云waf/ 腾讯智能网关/腾讯云tke等做为基础组件。这些组件都能够输出标准化日志，我们对日志进行清洗、汇聚，从而可获得各种可观测的metrics。其次，前端埋点。有助于监控前端用户体验，发现资源加载慢、API接口超时、成功率低等问题。最后，组件自身的监控系统，采用公有云API、 telegraf input、 prometheus exporter等方式对组件自身的健康情况做好监控。




1）基础组件可观测

对于基础组件来说，我们需要知道各组件的运行状态、容量性能情况等。基础组件可观测选型较多，相对私有云来说，公有云具有较好的可观测生态。以腾讯云为例，公有云除了提供较好的dashboard 与告警能力外， 基于API V3构建的开源生态亦比较丰富，可使用grafana plugin 和prometheus qcloud exporter进行观测，方便与prometheus / grafana 进行集成对接。





需要特别说明的是由于原生监控指标较少，服务器数量较多时，监控原生api可能无法满足高额拉取频率要求，我们可以采用开源手段进行监控，比如自行部署 node exporter， 由prometheus 自行抓取与监控。

2）业务指标可观测

根据业务指标的重要程度，我们会针对关键指标如亮码、核酸、疫苗接口相关业务指标进行观测。对各种接口监控好，我们就可以有效保障系统整体质量，监控的指标包括各接口业务量、成功率、平均耗时、95分位耗时等。

• 业务量监控
  

从Log中分解出相应的URL，分时间/URL  Count 数量即可获得业务量 metrics, 业务量的监控有阈值监控、同环比、动态阈值监控等。

• 成功率监控
  

成功率表示的是成功请求量占总请求量百分比，从Log中很容易区分出异常返回码，从而计算出成功率。一般采用阈值监控 。

• 耗时监控
  

耗时监控表示的是业务整体耗时，每一笔耗时在日志中均有记载，可采用平均值或p95耗时监控，一般采用阈值、无阈值监控等方法进行监控。

常用的日志处理手段有ElasticSearch / 腾讯云CLS等。

3）用户体验可观测

• 前端监控
  

我们在健康码项目中使用的监控工具是腾讯云RUM监控（Real User Monitoring), RUM监控的便捷之处在于对业务代码的侵入性较少，只需新增数行代码。能够监控到前端JS错误、白屏、首屏打开速度、API成功率、API耗时等。

import Aegis from 'aegis-mp-sdk';const aegis = new Aegis({  id: "pGUVFTCZyewxxxxx", // 项目key  uin: 'xxx', // 用户唯一 ID（可选）  reportApiSpeed: true, // 接口测速  spa: true, // 页面切换的时候上报 pv});
复制代码

代码示例：RUM监控接入方法及为简单方便。




上图是前端监控数据总览视图，有助SRE第一时间了解整体用户体验数据。



上图是某健康码业务前端调用后端API成功率。

API监控功能有助于SRE了解后端API性能，在后端成功率、耗时（如95分位，平均耗时）有波动时，可以有效下钻分析并联合后端进行排查。由于健康码内部引用了大量的外部接口，在实际应用中，我们通常采用此方法第一时间发现第三方系统接口耗时波动，并及时联系第三方接口后端进行处理。



上图是某健康码业务前端错误。该视图有助于SRE第一时间了解整体前端错误数据，并有针对性对业务前后端应用进行优化。

• 用户反馈监控
  

在业务出现问题时，微信投诉入口或微博等媒体一般会有投诉产生，一旦产生某些关健字汇聚，可以及时介入处理，防止事态扩大化。

4）业务拨测

我们可以模拟业务请求向业务后端接口发起拨测。拨测失败（无法连接、响应超时、错误返回码）可发出告警，这种探测手段也比较有效。腾讯云的拨测功能能有效从全球发起拨测请求，并生成拨测结果报表。



上图是全国健康码质量拨测质量视图。

我们也可能在系统内部建立起对第三方接口的拨测，达到自证清白的效果。低成本的拨测解决方案有 blackbox exporter等。



上图是某健康码业务的第三方接口拨测，有助于自证清白。

容量压测

疫情往往会瞬时带来比平日峰值数倍甚至数十倍的亮码业务量，增长幅度较大，运维团队一般无法即时进行扩容，所以在疫情增长趋势较为明显时，我们会预估业务量，并与业主沟通进行扩容，扩容后完成性能压测。

1）读接口压测

我们会从系统随机抽取一部分用户，向系统模拟数十倍峰值请求来进行压力测试。压测的同时向第三方接口报备压测流量，以免造成第三方系统损坏。

2）写接口压测

写接口涉及到数据写入到生产环境，所以一般采用两种形式进行压测。一种是标记数据压测、比如采用一些模拟用户ID 号段的用户生成清求，压测完成后采用删除压测数据的方式进行清脏。另一种是压测请求http头内携带压测标记，业务代码内对压测请求特殊处理，旁路插入测试库。

腾讯云压测团队提供了一系列的压测工具及服务，有效助力每个健康码业务疫情期容量保障。

3）压测排障

压测过程中碰到瓶颈常见于：单核跑满——存在于某些应用使用单核的情况，一般需要做业务改造，使系统运行在多核；负载过高——如CPU过高，虚拟机包量超 10W等；防火墙等数通链路故障——防火墙可能会存在带宽限制、新建会话数限制等 （不限于互联网出口防火墙、区域间防火墙）；PAAS能力限制——如redis单机版单核跑满，连接数跑满等；第三方接口延时过高——如第三方接口不能承压等情况；某些私有云存在大量CPU超分。在压测过程中发现并解决能力短板，从而使系统能达到理想的容量。

混沌工程与故障演练



上图是健康码混沌工程实践。每个健康码从新上线到成熟，产品与运维团队都经历了组建至成熟的过程，通过故障演练，团队能快速找到产品架构薄弱点、组织效率瓶颈点，演习完成后可有针对性对演习中发现的问题进行优化，经历过多次演习，架构高可用能力与组织效率均能有所提高。

1）检验服务的高可用性，如架构无单点，具备健康检查、负载均衡等能力

通过关机、网卡禁用、实例调整等手段模拟故障，检验在IaaS/PaaS出现故障时，业务是否会受到影响，业务能否自动切换，后端业务能否自动止损熔断等。

2）检验监控覆盖度和有效性，如基础监控、业务指标监控的覆盖度和告警有效性

通过关机、网卡禁用、实例调整等手段模拟故障，检验基础监控手段能否及时发现问题，业务监控手段能否及时发现业务抖动，告警能否触达到相关的运维人员。

3）检验应急预案的有效性，如扩缩容预案，限流预案等

以压力测试为辅助，检验压力条件下，能否快速成功扩充容量，能否快速启动对业务限流。

4）提前发现服务稳定性隐患并推动消除隐患，建立故障快速发现和快速止损的能力

在某些特定的业务耗时增加、错误率增加时，能够快速启动预案介入，快速恢复业务成功率及耗时。

业务架构优化与业务柔性

优秀的架构需要具有自保护能力与对后端应用的保护能力。常见的保护能力如：

某些高并发写请求入库前增加队列以增加瞬时吞吐能力。如高峰期扫场所码，扫场所码信息入库实时性要求并不强，采用腾讯云ckafka等组件进行业务削峰。

在应用加入适当时长（如：5分钟）的缓存，用户短时间调用该数据时走缓存，以减少对后端、第三方接口的请求。该缓存可以加在前端（如Localstorage）或 后端（采用redis或hash到有状态服务的本地内存）。

在后端或第三方接口故障时，由于用户会不断重试而瞬时增加大量请求，甚至导致后端雪崩，这时就有必要在前端增加限制重试的逻辑。比如有些小程序设计在用户请求出错后，会要求用户重登陆， 但如果对该登陆请求没有限制，必然会导致请求量过大而后台雪崩。我们建议在前端加上限频措施。以下是常见的前端设计：



后端在网关等层面限流，只允许承载能力内的请求进行后端。通过压测对系统承载能力摸底，从而在接入网关进行限流。我们采用腾讯云智能网关（腾讯云公有云API网关有同样的能力）限流。可以对后台起到相应的保护作用。

第三方接口耗时太长，产生大量TCP连接而耗尽系统资源，此时会要求后端具有快速失败的能力，不再长时间等待第三方接口返回。



上图是健康码系统分层部署及各层对后端的保护能力。以上保护手段在每个项目中的实现策略均有所差异。因为涉及到用户体验，需要与业主充分讨论后执行。

变更控制

业务上线后，需要持续保持业务稳定运行，变更控制尤其重要，现网变更均需要提出变更请求，每一个变更请求需要进行技术严格评审后，经客户、管理授权后方能在现网实施。

我们特别使用腾讯云coding承载变更工作流，变更工作在平台中实现闭环。一个合格的变更请求至少要包含变更目的、实施过程、验证方案、回退方案等。ITIL 的 change management中均有规范，此处不再详述。变更时尽量遵循灰度发布，防止变更中产生较大影响面的问题。

以上是从技术架构、可观测体系、运营保障体系等运维体系各方面总结出来的、保障健康码过程中的心得，希望能给大家一些借鉴和参考。整体来说，技术架构上，基础资源尽量采用云原生产品，满足大容量、可伸缩、高可用的基础资源能力。可观测体系上，要采用云原生产品构建业务前端、后端一体化观测体系，保障业务可用性。运营保障体系上，好的系统运维是设计出来的， 一方面加强业务技术架构设计，可层可对后端提供保护，通过限流、逻辑熔断等手段使业务架构具有容错能力；另一方面平时要不断通过混沌工程演习手段，检验系统容量及高可用能力，保障团队能够及时响应，专业响应。

当然我们碰到的业务场景有限，为了满足业务快速上线，历史上所采用的的一些技术实践也不一定是最优的。当前云产品发展日新月异，已经产生了更好的产品解决方案，期待大家在评论区一起发掘讨论。

最新经典文章，欢迎关注公众号

---------------------

作者：高可用架构
来源：weixin
原文：十亿人都在用的健康码，运维体系是怎么设计的？

感谢分享