前面两篇介绍了共享服务中台的业务价值以及建设原则，本篇内容将主要介绍当服务中台支撑越来越多业务场景后，在打造平台稳定性能力方面所探索出的一系列创新技术以及成果。整个稳定性体系包含的内容非常广，机房布线、网络通信、硬件部署、应用架构、数据容灾等都与稳定性相关，这里我们提到的稳定性主要指从共享服务中台的角度，实现了对中台应用架构以及平台自身的精细化管控以及保障，主要措施包括容量压测和评估、全链路压测、流量的限流和降级以及业务一致性平台。
容量压测和评估
想了解一个平台的容量，在传统的常规性能测试以及系统容量评估时，一般是通过需求分析得出压测的业务场景以及不同场景在压测中的比例关系，或者是凭经验对业务进行分析而得出经验型的测试模型，再通过测试工具进行模拟压测，以此来判断该系统的最大负载。
然而该经验型的测试方法不仅测试场景简单，并且测试结果大部分依赖测试人员的水平，当业务频繁变化时导致多场景模拟成本巨大甚至无法完整的评估。为了更加精准的了解平台容量，科学利用服务器资源，阿里巴巴技术团队经过多年的实施与验证总结出了一套在分布式应用架构下应用系统容量测试与评估的自动化平台。
应用系统容量预测包括容量压测以及容量分析预测两部分：容量压测通过将线上真实的流量引流到压测目标机器上，并不会对本系统及下游系统带来额外的流量，也不需要准备测试数据、压测系统，利用HSF服务框架对于服务路由权重的支持，通过对服务路由权重的逐步增加达到逐步增加某服务单机请求数量的目的，以此来验证单机服务实例所能提供的最大QPS处理值；容量规划平台则是利用服务的单机QPS数据，结合多年来沉淀的算法，对各种服务器机型处理能力的差异化分析，来更加准确的预测大促活动需要部署的服务器资源，提升平台精细化管控能力的同时也大大的节省了资源成本。
全链路压测平台
全链路压测是阿里全系统在每个环节都参加的双11实战演习，双11活动09年开始举办，但实际上在2013年前，无人能确保平台全链路的高可靠性，容量压测以及规则仅仅是针对单个应用进行评估，以及后面即将提到的限流、降级等措施重点在于对平台的稳定性保障，为了彻底解决这个难题，从2013年开始，阿里巴巴开始了称为全链路压测的工作，并很快成为集团大促备战最重要的武器，在历年的全链路压测过程中，提前暴露了诸多环节存在的问题。
全链路压测平台通过应用系统改造使线上环境可以同时处理正常流量和测试流量，获得真实的线上实际承载能力数据。进行全链路压测，涉及范围非常广泛包括网络、应用、数据库以及安全等都需要改造，下面简单介绍该平台：
- 基础数据抽取——为了模拟尽可能真实，全链路压测以线上数据为数据源进行采样、过滤和脱敏，数据量与线上数据保持同一个数量级并在数据库上进行区间隔离；
- 链路与模型构造——链路代表要压测的范围，链路的访问量级、链路的参数集合以及基础数据的特性一起构造了压测的模型；
- 链路验证——在全链路压测平台建设过程中，验证环节耗费了项目组大量的时间和精力，电子商务业务特性复杂，下订单以及支付等上百条链路，每一条链路都需要在平台上进行验证，目前链路验证已经集成到平台当中，能够自动化完成对压测链路的验证；
- 业务系统改造——在业务系统针对压测流量进行改造，比如为了支持压测链路的重复执行、下游写流量的拦截、防止污染BI报表和线上推荐算法等场景；
- 数据平台——全链路压测的基地；
- 流量平台——全链路压测的CPU，主要由全链路压测操控中心以及压测引擎两大部件构成；
- 影子表——为了不污染线上的正常数据，在同一个数据库实例上对数据库表建同样结构的影子表来进行数据隔离；
- 中间件改造——全链路压测需要所有中间件的协议都支持对压测流量的识别，使得压测标识能够随着调用传递下去，使得下游的应用、基础中间件和存储都能够识别压测流量；
- 安全机制——安全机制分为两层：第一层是安全的监控和防护，建立非法流量的监控机制、防止数据错乱；第二层是对压测流量的安全过滤，针对压测流量放松安全过滤，使得压测流量不被判别为攻击流量。
流量的限流和降级
限流的作用相当于保险丝，当过载的时候掐掉一些流量，让系统有能力集中资源以较快的速度处理平台能力范围内的客户。比如某次活动，预计100万人的流量结果涌来千万用户，容易使得后端的服务器直接满负荷运算最终造成整个平台无法响应，限流之后仅让100万用户进入后端的处理流程，给被阻拦的用户返回限流页面，限流页面可以与活动页面保持一致在一定程度上减低用户的失落体验。
阿里巴巴通过在Nginx上实现的扩展组件TMD（Taobao Missile Defense）实现了接入层限流的主要工作，主要通过域名类限流、cookie限流、黑名单等一些安全策略来实现。对于服务层的限流控制，主要通过限流平台Sentinel控制，Sentinel平台是对资源调用的控制平台，主要涵盖了授权、限流、降级、调用统计监控四大模块。同时Sentinel平台还提供降级功能，除了通过代码中修改服务调用逻辑的值外，也可以通过Sentinel控制台提供的降级规则的配置来开启服务的降级模式。
业务一致性平台
业务与数据不一致的问题原因非常复杂，远程服务调用失败、数据库保存失败、MQ消息发送失败或者程序设计自身的问题都会导致业务数据异常。为了解决这个问题，实时业务审计BCP（Business Check Platform）应运而生，BCP平台并不仅限于交易类业务，也适合其他对业务稳定性要求比较高的领域，通过事件模式，把业务数据变化触发的消息转换为相应业务类型的事件，放入到事件执行队列进行规则检查。
BCP平台主要实现了4个目标，第一：高实时性地发现业务脏数据或错误逻辑；第二：让各应用快速接入BCP平台；第三：整合订正工具，形成规范的脏数据订正流程；第四：实现了对新业务上线的实时监控。BCP平台让整个平台稳定性能力从技术维度延伸到了业务维度，是平台稳定性体系中一个非常重要的拼图。
内容摘录于《企业IT架构转型之道》，限于篇幅原因，本篇有关流量调度以及业务开关环节未做介绍，有兴趣的读者可以阅读阿里巴巴中间件首席架构师钟华著作的《企业IT架构转型之道》一书，此系列就此结束，前两篇的文章链接如下，欢迎一起探讨：
阿里巴巴中台架构的建设原则——走进《企业IT架构转型之道》系列2
阿里巴巴中台架构的业务价值思考——走进《企业IT架构转型之道》系列1
作者：钟华（古谦）
阿里巴巴中间件首席架构师，15年中间件领域行业经验。对传统企业IT建设和互联网架构都有较为深入的理解，有着扎实的理论基础和丰富的实战经验，多次作为总架构师协助大型传统企业打造业务中台项目，为企业实现“互联网+”转型提供了科学的发展方向和强有力的技术支持，项目涉及政府、制造业、金融、交通、媒体等多个领域。
