高可用架构技术实践 亿级用户数字业务的坚强后盾

文章来源：《华为云确定性运维案例集（稳定可靠篇）》

      业务背景：某深耕文化娱乐行业的互联网企业，当前服务用户已过亿，其核心数字业务的稳定性直接关系到企业的GMV（商品交易总额）。业务对自身可用性要求极为敏感，服务接口的单次请求失败将直接导致收入的损失，网络抖动引发的时延增大、突发流量导致的业务瓶颈以及服务端响应异常等情况均会导致业务访问的成功率受损，业务对整体架构的可靠性提出相当高的要求。企业对业务架构进行部署高可用、业务流高可用梳理、降低业务对于单实例、单硬件的依赖性迫在眉睫。

      由于业务的特殊性，企业在进行高可用优化时，针对不同的云服务模块提出不同的要求：
      1. 针对数据接入层，保障入口服务的可用性，提升流量入口服务的观测能力和应急响应能力；
      2. 针对服务层，在IaaS服务出现突发硬件故障时如ECS HA，减少引发的业务感知，日常进行硬件巡检，提前识别亚健康风险；
      3. 针对数据层，对中间件服务在出现实例倒换场景时，秒级内完成倒换并完成业务恢复；对数据库服务的性能，响应时间及性能配置优化等要求。

       1、广告业务入口部署架构优化
      （1）优化前业务架构
      广告业务后端采用容器化部署，APP通过APIG调用广告业务后端。使用DNS控制APP流量的配比，采用2个X3版APIG实例均分一部分流量，额外采用ELB后接多个APIG实例承接部分流量，每个APIG实例与CCE工作负载直接对接。 

      （2）优化后业务架构
      将ELB后接APIG的链路作为备用链路，只作为应急使用。调整ELB的规格至最小，后接一个基础版的APIG实例，防止DNS改完权重以后，有部分流量残留，预留最小规格，如果有小流量则导入基础版的APIG实例。若业务流量增加，现有配置不足的情况下，提前1天创建好APIG实例并挂载到ELB后端，同时修改DNS的权重进行分流。若对DNS分流时效性要求较高，在紧急情况下可将APIG内部ELB挂载上新创建的APIG的后端地址快速切流，控制后端CCE的POD数量在400个以下，通过纵向扩容的方式提升POD的承载能力。
      （3）优化后架构优势
      灵活扩缩容：使用多个APIG X3实例承载日常公网流量，同时维持一个小型ELB，最小成本达到快速扩缩容能力。新增的容量后续可以安全缩容删掉， 新增多个集群的情况下可以不用修改DNS的配比。
      降低成本：日常公网流量使用多个APIG X3实例直接承接，ELB链路只作应急使用，因此日常保留最小规格即可，降低成本。
      快速应急准备：ELB作为逃生通道，若有紧急的峰值可以提前做好预案，进行流量切换，同时ELB保留最小规格承接DNS的存量残留，IP会继续保留在DNS中，可以快速调整DNS配比。

      2、广告业务架构优化
      APP请求广告业务服务端，端到端超时时间为6秒，APIG后端配置的超时时间为5秒。业务架构的挑战点如下：
      （1）业务执行涉及公网网络访问，公网网络质量无法保证稳定。
      （2）整条请求链路涉及多次Redis请求，Redis倒换检测时间配置30s+，远超过业务要求的上限。
      为保证请求成功率，从组件故障高可靠、FRU隔离/倒换的检测时间和业务影响时间等方面分析优化措施如下：

      3、广告业务链路稳定性分析
      针对广告业务架构和业务流分析，可将整条请求链路拆分为三大模块，对三大模块的链路稳定性分别进行分析。
      （1）APIG链路分析
      手机APP通过APIG请求广告业务服务端，端到端请求时延为6s，6s后请求超时。对APIG链路分析发现，其中1/8流量不跨AZ，5/8流量跨2次AZ，1/4流量跨1次AZ。跨AZ绕行导致请求的时延增大，通过部署优化，减少请求的AZ绕行次数和频率。
      （2）Redis链路分析
      广告业务服务端访问DCS，当前DCS的抖动规格是15s+，超出APIG配置的请求5s的超时时间，抖动的具体参数包括：
      a) 主备倒换的时间：配置20s；
      b) Proxy超时30s，slot刷新10s；
      c) ELB健康探测时间12s；
      d) 客户端SDK超时1s。
      DCS产品侧优化了主备倒换时间，将倒换时间降低至10s，针对Redis链路上各参数的配置，联合客户对每个DCS实例进行了参数优化、测试、演练，最终将DCS抖动时间降低至秒级。

      （3）NAT访问公网链路分析
      广告业务服务端通过NAT，访问公网的第三方DSP，该链路的主要的挑战在于公网环境不稳定，业务上准备了2个NAT实例，其中1个实例作为灾备实例，两个实例在同一个底层网关集群，为使灾备资源故障独立，需要对备用NAT实例进行迁移，使主备实例分布于不同的网关集群。
综上所述，针对业务链路稳定性，一方面做好硬件保障，对所有资源建档，例行巡检，提醒隐患识别灵敏度，针对核心链路高风险资源提前热迁闭环隐患。另一方面需从可靠性、参数配置等方面对链路进行详细拆解分析，确保资源高可靠情况下，减少AZ绕行；优化倒换、隔离参数，提升敏感性；优化部署，确保灾备资源具备故障域高可靠。

      4、配置优化
      （1）APIG配置优化
      梳理APIG的全部配置项，根据最佳实践，结合业务，输出配置优化建议，发挥产品最大性能。
      （2）CCE配置优化
      节点开启静态绑核：单个POD绑定单个核，减小CPU核间切换开销，单个POD承载的QPS提升30%。
      内核参数优化：基于最佳实践，修改ECS侧net相关参数，单个POD1min处理的请求数提升6%。
      POD数量优化：降低POD数量，控制每个命名空间下POD数量在400以下，提升单POD的利用率。

      5、广告业务逃生方案设计
      （1）EIP故障逃生方案：
      故障发现：QPS调用突降，接口不通，EIP无法ping通。
      逃生方案：扩容备用ELB和ELB绑定的EIP，将EIP后端APIG地址加入ELB中，将新EIP加入DNS中，同时将故障EIP移除。
      （2）APIG故障逃生方案：
      故障发现：调用接口不通或报错，APIG实例CPU冲高，上报告警。

      逃生方案：
      a. 管理员进入APIG的管理后台修改故障实例ELB后端地址，绑定到另外已有实例中，用于流量隔离。
      b. 创建新的铂金版X3实例，并进行业务配置，扩容ELB到最大规格，并修改DNS权重接入流量，用于分担故障实例流量。
      （3）CCE工作负载POD故障逃生方案：
      故障发现：APIG产生大量5XX，CCE节点或POD CPU冲高或异常上报告警。
      逃生方案：
      a. 若单个POD负载正常但无响应，APIG上快速剔除故障的POD节点。
      b. 创建新的铂金版X3实例，同时创建新的namespace，接入ELB，承接新流量，减缓POD压力。

      1. 减少爆炸半径，对广告业务的业务架构和部署架构的深入分析和优化，使得架构具备灵活扩缩容能力，满足业务应对活动期间大流量的场景。通过入口架构优化，降低对单实例的依赖，从而达到减少爆炸半径、降低成本的作用。
      2. 提高链路稳定性，对业务链路进行拆解，识别关键路径，分析每条子链路的稳定性，从访问路径、访问时长、异常模式、部署可靠性等方面，识别瓶颈点，输出改进点，提高了链路稳定性。
      3. 降低故障对业务的影响时间，设计业务逃生方案，梳理业务架构上的所有故障模式，明确每个故障的观测点以及故障后的应急预案，将故障对业务的影响时间降至最低。
      4. 高可用性能架构优化完成后，当面临618等重大活动时，在峰值请求量和QPS超过平时流量的140%的情况下，保障业务实现零故障。

      本次高可用架构优化实践，实现了现状分析=>方案优化=>技术落地的完整闭环。通过广告业务部署架构优化、广告业务逃生方案、广告业务架构优化、广告业务链路稳定性分析等关键行动，减少爆炸半径，提高链路稳定性，达成了业务高可用，保障亿级用户数字业务的稳定性。后续我们将继续在高可用方向继续探索，追求更加极致的业务增长，提升用户体验。