阿里软件架构发展史。5星。

本书是阿里各技术团队对本部门的价格发展史的概括。前半部写的非常好，比较少的篇幅说明白了阿里面对的业务与技术的挑战尤其是双11带来的巨大的挑战，和阿里技术团队的应对经过。后面是一些相对外围的系统的介绍，偏简单。前半部分我给5星，后半部分3星。总体依旧是5星。

以下是书中一些信息的摘抄。#后面是kindle电子书的页码：

1：2009年我们技术部门只有几个人临时安排值班，高峰每秒只有400个请求，到2016年阿里有23个事业单位、几千位技术人员一起加入了双11的备战。杭州西溪园区1号楼的7楼、6楼和5楼都成为了双11的集中作战室，实现了每秒处理1.7万条请求的技术奇迹。#51

2：HSF、TDDL、Notify这“三大件”，有效地解决了应用分布式后带来的技术扩展性问题，同时让整个系统的技术架构变得依旧如当初一样简单。#342

3：五彩石项目将阿里电商交易的架构从2.0升级到3.0，大幅提升了系统的水平伸缩能力，异地多活则在五彩石项目之上，将阿里电商交易的水平伸缩能力再次提升为单元粒度级，架构版本也相应从3.0升级为4.0，这次架构升级从2013年开始，到2015年双11时已形成三地四单元架构（如图1-5所示）。#367

4：3.0版本之所以在更大规模时出现了水平伸缩能力问题，主要在于一个庞大的分布式系统中尚有若干集中式的节点存在，而要去掉这些集中式节点基本是没办法做到的。经过分析和讨论，我们认为一个比较好的解决办法是限制分布式系统的规模，当这个分布式系统达到一定的规模后，例如5000台机器，就再搭建一个新的。#382

5：2015年的双11意味着阿里交易架构从本地升级到混合云，具备了弹性使用云计算资源的能力，这个能力为阿里双11的成本控制提供了巨大的帮助。#531

6：OceanBase（中文名“海钡云”）是阿里巴巴/蚂蚁金服集团自主研发的面向云时代的关系数据库，从2010年6月份立项开始已经发展了六年半的时间。#598

7：OceanBase的第一个业务是淘宝收藏夹，之所以选择这个业务，是因为传统关系数据库无法满足收藏夹两张大表进行关联查询的需求，之前的解决方案无法对用户的收藏按照商品的价格或者热度进行排序。OceanBase抓住了这个业务痛点，并在底层存储引擎层面对这种场景进行针对性设计，消除了传统关系数据库最为耗时的磁盘随机读操作，巧妙地解决了这个问题。#613

8：因此，OceanBase在技术架构上做了一个折中，将写入操作全部放到一台服务器，从而规避分布式数据库中技术难度最高的事务处理。#622

9：淘宝直通车报表是OceanBase投入精力最大的一个项目。广告主通过直通车报表分析投放效果，最大的广告主需要分析的数据量有几千万行，要求在10秒以内返回结果。#639

10：最终，团队充分讨论后一致决定，坚持OceanBase的未来就是通用关系数据库。而作为通用关系数据库，OceanBase必须坚持强一致性，坚持关系数据库的SQL语义，像关系数据库一样易用。#655

11：相比传统的IOE架构，OceanBase能够将成本降低一到两个数量级，并提供更好的扩展性及高可用能力。另外，OceanBase支持平滑迁移，无须业务改造，就可以将原先使用MySQL的业务迁移到OceanBase。#685

12：全链路压测被誉为大促备战的“核武器”。如果之前关注过阿里双11相关的技术总结，对全链路压测一定不会陌生，这个词的出场率几乎是100%，从对双11稳定性的价值来看，用“核武器”来形容全链路压测毫不为过。#1099

13：经过反复讨论，最终我们找到了一个既不污染线上，又能保障压测结果准确性的方案：在所有写数据的地方对压测流量进行识别，判断一旦是压测流量的写，就写到隔离的位置，包括存储、缓存、搜索引擎等。#1149

14：为了减少熬夜，提升压测幸福度，我们启动了白天压测的项目：将线上运行的机器动态隔离出一部分放到隔离环境中，这部分机器上只有压测流量可以访问，白天在隔离环境的机器上进行压测。#1182

15：经过不断研发与测试，2016年我们在整个过程中解决了弹性服务池动态伸缩、跨地域调度、机房级容量探测与评估、故障自动隔离、全链路业务功能验证等问题，整体备战工作稳如预期。1383

16：第一个随之而生的是用于订正的数据修复平台，它是一个提供对脏数据进行快速订正并规范化用户流程的系统。#1471

17：第二个就是数据链路排查工具——全息排查平台。在阿里内部原本有一个非常著名的trace产品叫鹰眼，而让我们数据问题排查最头疼的就是到底是哪个环节改坏了，全息排查就是起这个作用的。#1471

18：2016年的双11，虽然BCP上的规则数比2014年翻了百倍，但当天大家反而对它的关注少了，因为双11前夕BCP已发现了上百个问题，而且被全部解决完毕。#1502

19：从2012年到2015年，依赖治理经历了4个版本的演进。从依赖分析、故障模拟、故障环境、故障分析等方面进行改良。保证结果准确的同时，大幅度降低实现成本，过去需要几个人做一个月的稳定性工作，现在一个人两个礼拜就够了。#1549

20：如果说故障重现是为了实现故障周期的闭环，那么故障演练则为用户提供一种定向演练的能力。#1595

21：故障突袭是一种以黑盒测试的模式验收稳定性的演练策略。#1606

22：在洪峰限流中我们采取的是令牌桶限流，在这个场景下，限流的实现通过漏桶算法来解决。漏桶算法思路很简单，水（请求）先进入漏桶里，漏桶以一定的速度出水，当水流入速度过大时会直接溢出，通过这种方式来调节请求的处理速度。#1660

23：流量调度，就是要屏蔽所有机器的软硬件差异，根据机器的实时服务能力来分配机器的实时流量。实时服务能力好的机器，多分配流量；实时服务能力差的机器，减少流量分配；实时服务能力不可用的机器，迁移流量。#1688

24：支撑这样一个花呗产品的团队你觉得会有多少人？2000人？或500人？No，我们还不到100人，包含产品、运营、技术、风险的所有花呗团队人员。几十人的团队能够实现几乎不可想象的普惠金融，促进新消费的快速发展，最核心还是在于大数据的力量。与其说花呗是一个金融产品，还不如说它是一个数据产品。#2503

25：回想过去几年，无论是移动网络速度、手机的内存容量、硬盘容量、CPU速度、屏幕分辨率，都在遵循或近似遵循“摩尔定律”。#2557

26：Weex利用H5的优势解决了Native的痛点：解决了iOS、Android等平台需要开发多套功能重复代码的问题；解决了Native无法做到即时发布及响应市场变化周期较长的挑战；提升了大规模团队在复杂集成系统平台上开发App的效率。#2605