高可用互联网系统稳定性建设实践指南

 1.概述

      自己以及带领团队曾经负责较多不同的互联网服务系统，如几十万应用数&亿级流量的云计算平台、年营收将近千亿的广告系统、亿级用户千万级日活的用户系统、亿级交易额的交易系统、算法在线离线工程系统等相关系统或子系统，整体而言无重大故障，达到定级故障数也很少，线上稳定性保障在一个不错的水位上。阶段性总结下我自己从团队技术负责人视角做好稳定性建设的实践性思考和简要思路，为感兴趣的技术同学提供一个实践指南。

       我的团队稳定性建设思路包括了3大技术要素：良好的系统架构和实现、完备的团队研发运维流程机制、技术同学良好意识和能力，以及1个业务要素：良好的研发项目管理。下面内容会详细讲解下3+1的要素。

2. 良好的系统架构和实现

2.1 架构设计

根据不同系统业务特点、不同发展阶段（系统规模、团队规模）、不同系统指标侧重性要求等，有很多不同的架构思路和折衷考量，例如存储选型、服务化治理、中间件选型、中台系统抽象等。本文会专注于简要讲叙会影响稳定性的一些架构设计点以供参考，设计考量点具体内容可自行搜索细看。

2.1.1 消除单点

       从请求发起侧到服务处理返回的调用全链路的各个环节上避免存在单点（某个环节只由单个服务器完成功能），做到每个环节使用相互独立的多台服务器进行分布式处理，要针对不同稳定性要求级别和成本能力做到不同服务器规模分布式，这样就避免单个服务器挂掉引发单点故障后进而导致服务整体挂掉的风险。 可能涉及的环节有端动态获取资源服务(html& js &小程序包等)、域名解析、多服务商多区域多机房IP入口、静态资源服务、接入路由层、服务逻辑层、任务调度执行层、依赖的微服务、数据库、消息中间件。 消除单点可能策略：在服务逻辑层采用多运营商多IP入口、跨地&同地多机房部署、同机房多机器部署、分布式任务调度等策略；在数据存储层采用数据库分库分表、数据库主从备集群、KV存储&消息等分布式系统集群多副本等策略。有分布式处理能力后同步需要考虑单个服务器故障后自动探活摘除、服务器增删能不停服自动同步给依赖方等问题，这里就需引入一些分布式中枢控制系统，如服务注册发现系统、配置变更系统等，例如zookeeper是一个经典应用于该场景的一个分布式组件。

2.1.2 数据一致性

       在分布式处理以及微服务化后，相关联的数据会存在于不同的系统之中，相关联的数据库表、数据存储、缓存等数据会因为架构设计或子系统抖动故障失败等原因导致彼此数据出现不一致，这也是一类稳定性故障。最简单一致性问题就是关系型数据库的同请求内同库相关联多个数据表更新的一致性， 这个可通过数据库的事务以及不同事务级别来保证。从架构层面，数据一致性也会根据业务特点，做强一致性、最终一致性的架构选型，不同选型根据CAP理论，也会带来可用性以及分区容忍性的一些折衷。在做好SLA高的基础系统选型、分布式事务中间件使用、幂等设计、针对性提升好微服务本身SLA后，可根据不同数据一致性级别要求，考虑通过消息触发多系统对账、定时调度对账、子流程失败后主动投递消息延迟重试、消息消费失败后回旋重试、数据库记录过程中状态后做定时调度扫描未成功记录后重试、离线全量对账。 缓存更新机制不合理也容易引发缓存和数据库之间数据不一致，一般在数据更新时考虑并发更新时缓存删除优先 或 固定单线程串行更新策略。复杂分布式业务系统 或微服务化治理后，基于消息中间件的解耦是普遍方式，这时选择一个确保自身不重不丢以及高SLA消息中间件非常重要，利用消息中间件自身的多次回旋重试基本能保障很高的最终一致性，数据一致性要求更高的，再配合不同级别对账机制即可。

 2.1.3 强弱依赖梳理和降级

       当服务依赖各类微服务时，避免强依赖（依赖服务挂掉会到自己服务挂掉），尽可能在对应服务出现问题时做到自动降级处理（弱依赖）或者手工降级，降级后依赖服务功能局部去掉或做合适局部提示，局部体验上有部分降级，但不会让主链路和整体功能挂掉。对于稳定性要求很好的关键系统，在成本可接受的情况下，同时维护一套保障主链路可用的备用系统和架构，在核心依赖服务出现问题能做一定时间周期的切换过渡（例如mysql故障，阶段性使用KV数据库等）。强依赖的服务越少，系统整体基础稳定性就越高。 部分特殊数据依赖多于逻辑依赖的系统，做去依赖架构设计也是一个思路，将依赖服务数据统一整合到自有服务的数据存储中，通过消息 或定时更新的方式更新，做到不依赖 或少依赖其他系统，进而提高稳定性，但这样做也会有副作用：数据冗余可能会引发不同程度一定时间窗口数据不一致性。

  2.1.4 热点 或 极限值处理

       业务规模 以及数据规模大的部分系统，在系统中会出现数据热点、数据极度倾斜、少量大客户超过极限