出来混，总要还的！
——《无间道2》
流控、熔断、降级、容错都是任何一个互联网应用的必修课，对于任何一个互联网企业来说，或早或晚，这些核心科技都必须要掌握。这次继续探讨行癫所讲的“核心技术的互联网化”。本文部分内容取自2019杭州云栖大会《互联网中间件专场》、《高可用架构专场》。
上一篇《看云栖说云栖 —— 容器、云原生、微服务》的最后，提到了为配合微服务在Kubernetes上的落地，阿里云有很多的产品可供集成，这些产品中有一些就是阿里云自研的“互联网核心技术”。
- 日志服务SLS、阿里自研的和ELK类似的日志服务。
- 应用实时监控ARMS、解决各种应用和前端监控问题。
- 链路追踪、解决服务间复杂调用依赖关系的性能诊断问题。
- 微服务引擎MSE、解决微服务的注册和订阅问题。
- 企业级分布式应用EDAS、一个微服务托管平台。
- 应用高可用AHAS服务、流量管理和架构感知。
- 应用配置管理ACM、集中化配置中心。
除此以外，还包括但不限于：
- 消息队列服务MQ、面向互联网场景的消息队列服务。
- 全局事务服务GTS、解决分布式场景下的事务一致性问题。
- 云服务总线CSB、主要对组织外部提供应用网关服务。
- 压力测试服务PTS、开箱即用的分布式压力测试服务。
在《互联网中间件专场》阿里云智能中间件首席架构师的《互联网中间件的演进》中将中间件的发展分成了如下几个阶段：
- 单体计算、1960s，在一台计算机上运行全部业务。
- 集群计算、1970s，通过计算节点和存储节点的扩展实现业务的横向扩展。
- 分布式计算、1980s，把大规模的业务系统按领域划分，从而实现业务的横向扩展。
- 互联网中间件、2010s，帮助业务应对双十一级别的大规模并发请求。
- 云计算时代、走向何方？
阿里巴巴的这些互联网核心技术大多都是从近十年的双十一大促活动中锤炼积累出来的，这些核心技术的每一项都对应着阿里踩过的“坑”，在国内做互联网业务，或早或晚，这些“坑”都会碰到。到那时，阿里的这些核心技术就成了一些企业成功爬出来的基础，反正用或者不用，它就在那里。
在《高可用架构专场》阿里云资深专家的《面向失败设计》中，提到以下这些有关失败的场景：
- 硬件问题
- 软件BUG
- 配置变更错误
- 系统恶化
- 超预期流量
- 外部攻击
- 依赖库问题
- 依赖服务问题
为了防止这些失败，可以有如下这些手段：
- 容灾、核心思想是基于隔离的冗余
- 服务能力与依赖调用自我保护、典型手段包括流量控制、熔断降级、系统保护、热点防控等。
- 为一切不可预料的情况做好预案、包括事前准备、日常的沉淀及仿真演练、事中的统一指挥和协同作战、事后的统一分析汇总改进。
- 自动化运维、从完全的人肉运维到依托工具的自动化、到最终依赖数据智能指标体系的自动化。
- 精细化的监控体系、建立业务层、应用层、容器层、主机层的分层监控体系。
- 故障与攻防演练锤炼容灾应急能力、通过计划梳理测试用例、执行故障注入、观察监控日志业务效果、记录容灾、监控、业务结果的有效性和正确性、事后分析的闭环来反复锤炼容灾应急能力。
在《智能化压测——应用稳定性基石》，阿里云智能技术专家爆出了一些历年双十一的“家丑”。
- 2009年，交易和商品系统挂了，很多商家的外部图片空间压挂了服务器容量，网络带宽容量，系统保护都没有。
- 2010年，零点峰值出现了大量的购买失败，但是服务器没有大面积宕机。
- 2011年，临时通知所有有问题的商家下架商品沟通会，商家对双十一的最大期望：系统稳定。
- 2012年，系统超卖问题，0点系统显示交易成功率不到50%，各种系统报错。
之所有出现这种情况是因为当时大家都是基于单个系统的容量预估方式备战双十一，而单个系统的ready并不能代表全局的ready。此后，阿里开始使用贯穿全业务链路的方式来对系统进行整体的全链路压力测试。
为了能够对线上正在运行的系统进行压测而又不污染数据，阿里云全链路压测实现了前端压测流量可识别、压测流量识别后可传递、应用业务系统兼容和识别压测流量、压测数据和业务数据分别存储。
阿里云全链路压测服务目前已经服务于整个阿里经济体，并开始对外以PTS服务的形式对外部客户提供服务，目前已经成功应用在包括中国平安、中国人寿、逻辑思维、懂球帝、CCTV、联通、蜻蜓FM等客户身上。
下一步，PTS准备推出无人值守的智能压测，实现压测流量的智能构造、压测过程中的自动调速、压测结果的智能分析。
