这本技术成长集精选了近年来阿里集团和阿里云在重要领域中遇到的故障，排查，分析和改进。从故障中得到的教训，刨析出来的架构缺陷，折射出来的实现问题以及运维过程中疏忽和错误是·真实的，·具有说服力。他山之石可以攻玉，希望对广大开发和运维工程师带来帮助。

---------阿里云资深总监 吴结生

古语说前人栽树后人乘凉，要乘凉必须要栽树，栽树需要很长的时间，那么《阿里成长集》正是这样一个活动，让历史的经验传承下来，帮助到更多的人。它汇集了阿里巴巴集团各个BU技术同学在日常工作中所遇到的典型踩坑案例，这些案例全部来自于线上生产实践，涉及到基础设施，中间件，数据库，业务开发以及稳定性建设，基本涵盖了阿里巴巴所有技术兵种，所以这是一本非常全面的技术踩坑实践，具有很重要的参考意义。也许某一天你也遇到了书中已经出现的某一个坑，但是问题排查起来却毫无头绪，正在你焦头烂额的时候，突然想起在某某一天曾经看到过书中的案例，也许你就能够非常轻松的迎面解决它，从中真正领悟分享的意义和价值，再将你遇到的问题总结下来分享出去，这就是传承。·后祝愿大家能够从成长集中汲取养分，同时也能够分享出你的自己成长集，让这个良性循环不断的持续下去，不断地造福后来的人。

-------阿里云研究员 褚霸

阿里巴巴的电商系统和其他互联网公司的系统有很大不一样的地方，因为双11带来了非常大的瞬间峰值流量，瞬间的峰值流量是没有办法通过人的临时思考进行响应的，而这个时候你只能将你的想法提前做到系统里，在流量到来的时候，系统自行做决策。对于这种决策机制我们分为两种类型，一是类似大脑一样的集中化决策，通过收集各个系统的数据来决策一些问题，第二是膝跳反应机制，让中间件面对突发瞬时的问题进行在线节点决策，比如异常连接闪断保护，限流降级等等。而这些经验的提出和沉淀都来源于不断出现的新挑战和解决新挑战的过程。

另外阿里巴巴的电商业务还是比较复杂的，一方面是市场多样化，业务多样化，另外是消费者，商家的影响面非常广，任何一个小故障都可能引发一些社会问题，所以公司对产品的质量，对服务的连续性有严格的要求。 如何解决好业务发展的需求和服务稳定性变成了一个矛盾。 业务只要发展就会不断发布新的功能，新的代码，新的功能和新的代码就会不断引入新的问题，新的故障。而如何减少问题和故障，需要在技术上不断创新，同时对人的能力的要求也就有了更高的要求。阿里巴巴的技术人员在日常的研发运维过程中，就是不断和新问题斗智斗勇的过程中，我们会鼓励把遇到的挑战和问题总结出来，所以在这个过程中积累了大量的总结资料，这些资料有些总结到了产品里，成为了架构，系统的一部分，有些不断被学习变成了其他更多同事的新能力。

----中间件技术部研究员 小邪

“人类从历史中学到的，教训，那就是人们从来没有在历史中吸取过任何教训”。在我带领阿里巴巴GOC（全球运行指挥中心）团队期间，天天面对不断发生的大小故障，尤其是重复发生的故障，确实有这种感受。而此书恰恰是在这种思考之下所采取的行动之一。成功难以模仿，教训可以学习。篇篇文章的背后都是血淋淋的教训，值得每一个技术人员好好阅读。

----菜鸟资深专家 王乐

目录

第1章  基础架构高可用     1

1.1  域名解析异常的排查思路   2

1.2  网络静默丢包        14

1.3  运营商网络问题不再只能“干着急”        20

1.4  一个存储系统master节点磁盘故障引发的惨案      23

1.5  服务器异常断电的数据丢失分析        31

第2章  中间件使用常见隐患与预防          38

2.1  高并发场景下缓存击穿问题分析        39

2.2  论如何实施限流保护   43

2.3  VIPServer负载均衡案例分析       48

2.4  瞬间高流量触发Tomcat bug引起集群奔溃       60

第3章  数据库常见问题     74

3.1  性能的杀手-SQL执行计划   75

3.2  记一次诡异的数据库延迟   84

3.3  一次AliSQL连接风暴的排查和深究    93

3.4  ORM规约变更反例       100

3.5  云数据库篇SQL优化**案例分析    104

第4章  业务研发**案例          121

4.1  分布式锁在超时情况下可能引起并发的案例   122

4.2  分布式一致性问题的另类解法   126

4.3  探索分布式故障模型相关问题处理方法的设计 空间      130

4.4  序列化结果有两种        140

4.5  JVM源码分析之不保证顺序的Class.getMethods     149

4.6  应用启动初期JIT编译引发load飙高问题         157

第5章  运行管理域稳定性建设          171

5.1  洞若观火，让故障无处遁形        172

5.2  运营商故障体系·佳实践   180

5.3  通过故障演练保障系统稳定性   186

作者集锦         191

推荐序一

我从2009年9月25日奉命组建淘宝技术保障部，到2016年4月1日移交AIS(Alibaba Infrastructure Service)给新任CTO，历时2380天、大约每3小时经历一次故障，可以说每天的生活就是从一个故障走向另一个故障，那段日子里我无时不刻不在琢磨如何保障并提升阿里平台的生产稳定性。淘宝/支付宝的可用性从2009年的99.5%到2010年的99.95%，到后来逐年提升并保持到现在的99.99%，由AIS牵头、协同集团各BU的技术小二集体为此付出了巨大而卓有成效的努力。从我的视角看，有以下三点经验：

一、做好顶层设计

“不谋全局者，不足谋一域”。生产稳定性的保障不能只埋头于一时一事的细节中，按照马老师在2009年底对我讲“不仅要救火，更是要防火”的要求，必须做好顶层制度设计：

1、研发和运维团队要能够“向对方靠近迈一步、互相理解和尊重”，这其中过程改进（SPI）和配置管理（SCM）同学们可以起到独特的承上启下贯通作用。这样技术保障部的基本组成是：

SPI + SCM + Production Engineer + DBA + System/Network Engineer

而且团队逐步要加强研发能力、能够对整个系统架构进行代码级的把控。

2、故障的标准统一以及处理流程的持续强化。2009年底我们讨论明确淘宝/支付宝的P1故障定义为“成交下跌10%且持续10分钟以上”，以此为准绳，统一思想和故障处理应急指挥体系，以及坚持事后故障复盘。事实证明，牵住了这个“牛鼻子”对稳定性工作有了很大提升。

3、坚持建设阿里经济体统一的基础设施平台。AIS从小变大的过程，就是淘宝、阿里云、B2B、支付宝等技术保障团队逐步融合的过程；也是原本分散的各种软硬件基础设施逐步融合的历程，坚持“书同文、车同轨、行同伦”。没有统一的基础设施和标准规范（包括IDC、网络、服务器、OS、中间件、数据库、业务应用、研发运维系统及工具、支持HTTPS标准等），就根本做不到今天的稳定性。

二、坚持技术创新

阿里巴巴过去18年的大发展是业务不断创新的过程，同样，阿里生产系统的稳定性也经历了持续不断的技术创新：

1、积极推动“去IOE”和金融级云数据库OceanBase的发展及成熟。此创新使得阿里交易和支付系统架构可以灵活支撑业务飞速发展，技术完全自主可控、积累了众多基础工程技术和人才，也大幅降低了技术成本。

2、“异地多活”和全链路压测。2010年我们就开始从青岛机房尝试做淘宝交易的“异地多活”，历经多年的反复技术尝试，终于有了今天北部、中部、南部的多机房同时支撑交易支付的能力。2012年双11零点惊魂促使我们下决心搞定“全链路压测”，用模拟的流量进行极限压测以获得生产系统的真实负载能力，经过2013、2014连续两年的实战摸索，现在已然成为我们双11稳定运行的利器。

3、云计算技术的逐步应用和强大。2009年阿里云正式成立，2012年双11天猫电商云平台“聚石塔”首次采用阿里云的产品支撑，到今天云计算在阿里巴巴平台广泛的使用和“云化”，都是咬牙坚持技术创新的结果。

4、统一计算平台到ODPS。没有统一的计算平台，不仅造成技术力量分散且成本不可控，更会导致数据生产和维护的混乱，是稳定性的大患。2014年启动“登月计划”，打造阿里集团统一的底层大数据平台，满足安全性、可管理、能开放等重要业务需求，在2015年6月完成了阿里所有数据业务的运行平台从Hadoop升级到飞天ODPS；同时在迁移过程中建立数据管理基本规则，做到业务的升级再造和数据通用。

三、组织管理创新

阿里经济体是一个朝气蓬勃的商业生态，一直在持续不断的进行业务创新；背后支撑这个生态的是一个超级复杂的技术体系，运行维护这个技术体系也需要进行组织管理方面的创新。

1、设置PE(Production Engineer，生产工程师)岗位，掌控业务应用的生产维护工作，这个岗位介于业务研发、DBA和系统及网络工程师之间，起到重要的桥梁纽带作用，为对口各BU的业务平稳运行负责。

2、成立GOC(Global Operations Center，全球运行指挥中心)、指定生产应急值班长，牵头负责整个阿里经济体技术平台的日常运行维护。故障的监控、报警、指挥、消防、事后复盘等全流程的运行管理，并通过持续的故障演练保障系统稳定性。特别的，2015年启动对核心交易和支付系统的“生产突袭”，是一种特别有效、真刀真枪的检验业务生产连续性能力的举措，应该长期坚持做下去。

3、面对“双11”的技术保障体系。针对每年一度的天猫全球狂欢节，日常的保障措施是远远不够的，需要成立单独的技术“团部”掌控全局、各关键链条上的BU成立“技术连部” 决策局部稳定性，以及精干的“情报分拣中心”担当·辛苦的枢纽、负责判断每条业务线情报员上报的各种异常信息并即时给出动作。

有了顶层设计、技术创新和组织变革，·终落实生产稳定性的，还是靠一线技术小二一行行的编码、一次次的测试、日复一日不厌其烦的故障排查工作，以及我们对维护生产稳定性小二们工作的重视、肯定和发自内心的欣赏。他们不是所谓的技术大牛或大V，不会在各种论坛上侃侃而谈、也不会书写高大上的PPT；他们面对日常一个个突发的故障，遭受委屈、忍受冤枉、不惧倒霉，坚忍不拔；他们是脚踏实地、埋头苦干的无名英雄，是阿里技术的脊梁。这本书《逆流而上：阿里巴巴技术成长案例集》就是负责阿里大平台生产稳定性的部分技术小二的代表，把他们这些年在基础架构、中间件、数据库、业务研发、运行管理等大型互联网平台的稳定性建设中积累的实战宝贵经验，用平实无华的语言娓娓道来，这些技术沉淀既是对过往典型故障的深度分析，也是跟同行们切磋交流的宝贵知识财富。

我要深深的感谢过往七年里为阿里生产系统稳定性付出努力的所有技术小二，也特别高兴看到《逆流而上》的出版并愉快的推荐给所有关心互联网平台稳定性的同行们。

刘振飞

阿里巴巴集团首席风险官(CRO)

原阿里技术保障部(AIS) 负责人

推荐序二

外界对于阿里巴巴技术的了解，大多要么是双11 又创造了交易和支付的世界峰值纪录，要么是阿里云技术的高大上，要么是又出了什么黑科技，非常炫。在这炫丽的背后，有那么一群技术人，是他们支撑了7X24 小时不间断的Online 服务，是他们让无数的业务想法变成了现实，他们付出了艰苦的努力，也踩过了无数的坑， 感谢在背后默默付出的阿里技术人！

这本《成长集》 ，从业务运行的角度，收集了不少的实际案例，来自阿里的多个技术团队，内容从第三方的运营商、DNS到IDC机房、服务器、网络到存储、中间件、数据库到业务系统和运行管理，几乎囊括了运行的所有技术环节。 也验证了技术之外的经验“对生产系统保持敬畏之心”“千里之堤，毁于蚁穴”，所有的这些，都极具参考价值。

共享是互联网·重要的精神，阿里巴巴技术人希望将这些血和泪的教训分享出来，和技术同仁共同成长，如果说这些分享能够给同行带来一些共鸣或者启发，那将是阿里技术人·大的幸福！

周明

阿里巴巴集团副总裁

阿里基础设施事业群（AIS）

阿里巴巴在互联网领域耕耘18年，业务领域覆盖电商、云服务、物流、客服等商业层面，流量从XX到XX，双十一·高流量达到XXX/S，用户覆盖全球各地，为了应对这样规模用户环境下能正常使用各类服务，阿里巴巴从基础架构、中间件、数据库、云计算、大数据等技术领域不断从实战中积累经验，颠覆技术瓶颈，不断创新以适应不断增长的需求。

为将阿里的技术反哺社会，共同促进互联网的繁荣向上，本书以‘成长’为题，从实际技术案例入手，详细阐述阿里在基础架构、运维保障、中间件、数据库、业务应用层和运行管理域如何突破创新，如何从问题中思考解决方案。

《逆流而上：阿里巴巴技术成长之路》主要面向互联网技术从业人员和在校师生，使读者能够通过此书基本了解阿里在各技术领域的能力，学习在如此规模下可能出现的问题以及解决方案的探讨和沉淀分享。

  阿里巴巴集团成长集编委会 由阿里巴巴集团不同业务线及不同技术领域内的人员组成的虚拟组织。技术人员都知道软件开发过程中的八二原则，理解大多数问题发生在何处，发生的原因，如何解决，变得尤为重要。阿里巴巴集团业务飞速发展，技术人员积累了大量丰富的线上问题排查及解决的案例和经验。 成长集编委会从中挑选了一些**的技术案例，侧重于对问题的还原和分析。我们希望，曾经踩过的坑都能具有其意义和使命，而后来者通过学习前人的经验，防微杜渐，快速成长。