读书笔记 - 尽在双11

尽在双11这本书是由阿里巴巴技术团队写的一本关于支持双11购物节的技术演变情况。整本书都是围绕着为了支持公司业务需要，如何从技术架构，稳定性，移动优先，开放平台等方面，逐步迭代更新技术架构，开发支撑海量并发用户的系统。

围绕着分布式架构，阿里采用了单元化、异地多活、混合云、OceanBase分布式关系数据库等。移动端也从H5, native, 到Hybrid，一直寻找最佳方案。蚂蚁金服的体系架构也随着taobao,天猫的架构在不断改进。

在系统稳定性方面，阿里技术团队注重容量规划、全链路压测、自动化备战、实时业务审计、故障演练、系统自我保护等方面。

在技术的帮助下，阿里推出了一些很有挑战性的商业概念，包括招商报名、双11会场、智能搜索、个性化推荐、供应链系统、蚂蚁花呗等。

在移动端，阿里也是走在电商的前面，他们推出的Weex动态框架，互动游戏，VR&AR，和奥创（多端数据协议平台）&TMF框架。

在平台上，阿里的聚石塔电商平台（开放生态），菜鸟电子面单（智能数据改变物流），生意参谋，阿里小蜜（智能秘书）都非常厉害。阿里有很多中间件技术，阿里云就使用了好多中间件技术，蚂蚁金服则是金融机构间协同运维的探索和实践。

以下是我的读书笔记或划线。

Preface
1. 降级是必须的准备。降级开关，做了4次大规模功能演习。
2. 和所有系统的自我保护系统一样，这个健康检查系统会定时扫描线上机器，根据机器应答返回时间判断是否正常，将超时严重的机器从应用列表中剔除。
3. 所以2013年，集合了各个BU的力量，我们创造了一套全新的压测系统：全链路压测。
4. 作战手册（指导双11前一个星期所有准备工作的手册），写好所有的内容，细化到时间点和执行人，防止再出现任何意外。
5. 了应对物理机房的挑战，我们启动了一个全新的思路：单元化。它的理念是将系统切割成足够小的单元，每个单元都能独立承担各自的流量。这样用户流量就可以随单元增加而均衡分配，而且每个单元之间相互独立。
6. 为了能快速释放和节省双11的成本，我们实现了50%的云化，即我们用阿里云的资源扛住了双11当天50%的流量，在双11之后一周内再将机器资源释放出来，提升机器循环使用的效率。

1.1 五彩石，电商架构新起点
1. 阿里架构演进可以分为电商基础架构演进、支付架构演进、移动端架构演进和混合云架构演进。
2. HSF、TDDL、Notify这“三大件”，有效地解决了应用分布式后带来的技术扩展性问题，同时让整个系统的技术架构变得依旧如当初一样简单。
3. 单元化主要解决的两个核心问题是伸缩能力和容灾能力问题，同时单元化方案势必要对业务进行改造，但是并不是所有业务都需要去做相应的改造。
4. 所有中间件，之前所有的中间件都没有单元概念，现在因为要确保根据单元正确路由，所以所有的中间件都需要进行改造；
5. 数据同步产品，在单元化方案中，数据同步是其中非常重要的部分；
6. 一期项目最终达到预期目标，单元化的方案基本摸索清楚，各中间件改造基本完成，业务层需要做的改造也得以清晰，为单元化改造在接下来更大规模地展开打下了坚实的基础。
7. 异地双活向异地多活演进的过程中，除了继续完善之前未改造完成的一些跨单元交互节点外，同时还需要改造一些在异地双活中被遗漏的改造点。
8. 在这轮混合云架构升级中，需要达成的目标是无缝使用阿里云资源，实现云资源的快速借用和归还。
9. 问题的解决方案是，我们选择了在发布时镜像仍然要build和分发，但增加了一个hotfix的标识，对于有这种标识的实例，在拿到镜像后，不用再去新镜像组建新容器，而只是从镜像中获取相应需要更新的文件进行更新即可。
10. 我们开发了热修复技术，利用热修复进行单点代码逻辑的变更替换，用热补丁的方式。
11. 经常有业务因为各种问题导致发布阻塞，那时候发布版本非常痛苦，所有业务都要赶火车。
12. 用户在有Wi-Fi条件时自动下载及动态加载。通过这个机制可以实现所有模块的替换。这是非常大的技术改进。现在，手机淘宝的包有百级别的Bundle可以独立地参与集成。大家可能会很惊讶，我们将组件化做到了极致。
13. 2015年开始，移动圈里面讨论最多的就是动态部署、插件化的架构、容器架构如何去运行，越来越多的公司加入这个阵容中。
14. 2015年，客户端动态能力上又诞生了杀手锏技术，我们孵化了Weex动态框架。Weex在天施的带领下，走向了Apache开源，引领了行业潮流。
15. MTOP去中心化，即把MTOP这个统一API网关的功能，包括协议解析、签名安全验证等一系列功能剥离出来，分散到各个业务应用。
16. 需要架构、中间件与管控系统的支持。
17. 在金融级中间件、数据库和云计算平台的支持下，分布式架构可以完全胜任复杂、高要求的金融级交易，
18. 阿里的确走在前面了，别人还在努力c10k problem，他们已经研究每秒1亿的问题了。如何处理每秒1亿笔交易。
19. 直接叫马云计划吧😀 蚂蚁金服和阿里云共同提出了“蚂云计划”，共建新一代的金融云平台，未来服务全球5万家金融机构，共创全球化的普惠金融。

2.1 容量规划，资源分配的指南针
1. 全链路压测
2. CSP容量规划系统，可以轻松地完成系统资源分配和容量准备
3. 故障演练，成为系统稳定性的问题探测仪
4. 洪峰流量会超出集群的极限处理能力，系统自我保护成为稳定性的最后一道屏障
5. 容量规划天平
6. 从最初的人工估算容量演变到通过性能压测评估容量，随后再一次进化到直接在线上压测评估容量，最后通过全链路压测来验证容量。
7. 容量规划公式理解起来并不复杂，预估业务量级除以单台机器的服务能力得到业务系统所需要的最小机器数，最小机器数作为理论的机器数下限，加上一个Buffer（冗余）值确保万无一失，得出最终需要准备的机器数。
8. Apache ab、Httpload、Webbench、Siege等都是非常轻量级、简单方便的工具，缺点是仅能提供Web服务压测，对于复杂请求的模拟能力有限。Jmeter、LoadRunner等具备复杂请求的模拟能力，同时支持多协议，有操控UI和比较详细的分析报表，相比前面几种工具略微偏重，有一定的学习、使用成本。
9. 线上流量复制线上流量复制压力测试主要用到了Nginx的post_action、tcpcopy、tcpdump回放等一些基础技术。是将线上某一台机器的流量扩大N倍复制到压测的目标机器
10. 线上流量复制解决了流量的真实性问题，所以能拿到非常准确的单机能力值。
11. 引流的方式有两种：第一种是把分布式系统中不同机器的流量转发到其中某一台机器来进行压测；第二种是在负载均衡端进行流量权重的调节，使流量更多地分配到某一台机器来完成压测。
12. 请求的转发方式在阿里主要通过apache mod_jk、apache mod_proxy、Nginx反向代理等基础技术实施。
13. 产线环境真实流量的压测是终极目标
14. 全链路压测平台的诞生意味着容量从规划到验证，形成了一套完整的闭环。
15. 在所有写数据的地方对压测流量进行识别，判断一旦是压测流量的写，就写到隔离的位置，包括存储、缓存、搜索引擎等
16. 自己研发一套全链路压测流量平台
17. Tair: Distributed KV store. Tair is fast-access memory (MDB)/persistent (LDB) storage service. Using a high-performance and high-availability distributed cluster architecture, Tair can meet businesses' high requirements for read/write performance and scalable capacity.
17. 改JVM时间的方式来支持应用时间的修改。
18. 随着我们对系统整体的把控上和准备工作上越来越精细，备战工作从最开始的几项逐渐细化分层到如图2-14所示的几十项，而且以后还会不断增加，越来越细。
19. 从0到百万级再到千万级QPS的压测能力”、“从0到秒级的服务无缝隔离与切换”、“从万级到几十万级的资源调度”、“从100天到8小时一键搭建交易单元”、“从0到3小时弹性伸缩完成整体容量调整”、“从1个多月到15天的备战周期”，正是技术的不断突破带来了从量变到质变的效果。
20. 我们必须要有能实时检测线上业务数据的能力。
21. BCP的全称是Business Check Platform，实时业务审计平台。
22. 我们把一条消息上的规则从多线程执行方式改成了单线程顺序执行。在执行过程中，查询过的数据缓存到了线程变量中，后续执行的规则就可以利用这个缓存，以减小对线上查询服务的压力。
23. BCP发现的脏数据，除了要找明问题原因，还要快速对脏数据进处理，防止数据的二次污染，对下游系统造成影响。
24. 第二个就是数据链路排查工具——全息排查平台。
25. 减少故障的最好方式就是让故障在可控的前提下经常性地复现。故障演练就是在这个背景下诞生的。
26. 原因是一个非核心业务逻辑被错写在核心业务的主流程中，且非核心业务对外部访问没有做HTTP超时设置。当下游业务异常时，业务线程被阻断，进而影响核心业务的主线程阻断。现象上就是主业务响应时间过长，导致整体不可用。
27. 强弱依赖是依赖治理的核心，而我们采用的评估方式是主动制造一些问题，让下游依赖的服务不可用。从上游的服务或业务表现判断是否合理，来推动架构、监控改进。
28. 不符合预期的表现都可以称为问题，问题不等于故障，问题是无法避免的。
29. 只有带来一定业务影响、满足一定标准的问题才会被称为故障.
30. 故障演练项目最初有3个人，分别是负责平台研发的中间件工程师、负责故障处理的值班经理、负责故障跟进的技术支持。
31. 除了系统功能类bug和人为失误故障，剩余的故障主要为技术缺陷导致。技术缺陷型的故障原因主要分布在网络、磁盘、进程、CPU、数据库、中间件等诸多大类。
32. 如果说故障重现是为了实现故障周期的闭环，那么故障演练则为用户提供一种定向演练的能力。
33. 演练时也暴露了监控缺失、告警缺失、告警不实时等问题
34. 宏观上，可以通过机房断网、断电的演练，推进架构的改进和成熟。微观上，也可以在大家不知情的情况下搞一些小破坏，观察系统的问题发现、自愈能力，故障处理流程是否合理.
35. 整个系统保护体系主要由5大子系统构成：限流、自动降级、流量调度、负载保护和预案
36. 洪峰限流中我们采取的是令牌桶限流，在这个场景下，限流的实现通过漏桶算法来解决。
37. 当弱依赖环节出现不可用的情况，将弱依赖自动降级，可保障核心环节的稳定可靠，在实际的生活中类似于“弃车保帅”的策略。

3.1 招商报名1，活动基础设施建设
1. 由一台高性能服务器进行数据分组和分发，然后交由30台服务器集群进行任务的消费和处理，单机QPS可达2000多
2. 谷歌，其搜索引擎的三大核心：一是网页内容的数据化，二是基于PageRank的算法引擎，三是谷歌巨大的产品创新
3. 数据化、算法和产品就是在反馈闭环中完成了智能商业的“三位一体”。
4. 引擎需要支持千万商品级的排序，而且可以横向扩展支持亿级商品量的排序，每次排序的耗时不能超过1分钟。
5. 实时指标计算的核心是基于Storm的实时计算引擎Galaxy和实时调度引擎Gallardo，系统的架构可以高性能、横向线性扩展。
6. 技术的演进是伴随解决实际业务问题和痛点发展和进化的。
7. 核心：分布式状态机（DSM）驱动的微服务架构。服务力求小粒度且避免事务类服务产生API调用依赖。通过单据状态的消息队列来触发各个与之绑定的服务，做到服务间解耦和提高可复用度。这正解决了2.0架构的服务治理问题。
8. 普惠金融最早由孟加拉的尤努斯开创，他创办的格莱珉银行专门提供给因贫穷而无法获得传统银行贷款的创业者，他因此而获得2006年度诺贝尔和平奖。
9. 它每天处理3PB的数据、数亿级的实时消息，还部署了复杂特征的防套现机器学习模型等。
10. 稳定压倒一切，降级一切有容量稳定性风险的逻辑。
11. 通过异步消息弱化信用支付与贷款业务间的强耦合
12. 对于各种外部核心依赖，都要假定其是不可靠的，需要产出其不可靠时的应急预案，同时确保应急预案的成本复杂度可控。
13. 除了针对每个预案的单独演练，2016年我们对于所有的预案按照双11当天的执行计划，进行了完全真实的彩排。
14. 提前制定了预案的启动条件，非重大事件无须走决策流程，由执行人员根据条件自行判断执行，可以大幅提升应急速度。

4.1 Weex，让双11更流畅
1. Weex是一个移动端动态化框架，它能够吸收H5和Native的优势，同时保证易用性。
2. AJAX逐渐成为PC Web开发的标配，PC Web也逐步走向了历史的颠峰
3. Node引发的前端工具和服务端热潮，Gulp引发的流式构建热潮逐步侵蚀Grunt市场，Swift逐渐进入iOS开发领域，等等。
4. 为了将性能做到极致，我们进行了大量的尝试，使用了多种优化手段。
5. 未来已来
6. 创立了Buy+（败家）这个品牌，走出了电商的VR之路。
7. 原理是把一个全景视频拍完以后，再制作一个倒播的视频，用户在正向走动时会播放正向的视频，逆向走动时会播放倒播视频。

5.1 聚石塔，开放的电商云工作台
1. 服务化看似美好，但对于内部来说框架限制太重，性能、调试、维护、协作效率都会受到影响，最后决定以API的形式来实现接口互通。
2. 技术上，分布式日志框架做到每3分钟统计一次结果，分析规则动态化配置；主动通知服务支持HTTP长连接与流式通信，实现实时通知；引入权重线程池，实现服务异步处理隔离，保证了平台的稳定性。
3. 2012年到2014年，开放生态全面开花，开放平台API数量从900增加到2500，日均API调用量从25亿增长到160亿。聚石塔从无到有，资源规模短时间内达到上万台
4. 随着移动互联网时代的来临，用户寻求服务的方式发生了新的转变，电话依然存在，但是会越来越少。
5. 分布式服务框架Dubbo、分布式数据库中间件Cobar、分布式队列模型的消息中间件RocketMQ、分布式缓存Tair等一系
6. 同时针对分布式服务体系下所衍生出的服务管控问题，阿里中间件团队历时两年半开发出了鹰眼EagleEye，提供了针对分布式应用架构所需的服务链路、服务分析、实时业务指标监控和报警等功能，很好地填补了开源产品Dubbo服务管控缺失的不足。
7. 除了分布式服务框架、分布式数据库、消息服务、缓存等支撑双11核心交易业务所需的中间件平台，也发展出了全链路压测、限流降级、流量调度等，以及在淘宝平台面对访问洪流的冲击、机房断电、网络异常、应用出错等复杂异常时，都能稳定运行的稳定性平台，这些技术的理念和实践也已经被国内各大互联网公司参考和借鉴。
8. RocketMQ 成为全球继ActiveMQ、Kafka之后，分布式消息引擎家族中的新成员。
9. 在电信运营商的选择上也采用双活策略，4根专线至少由两家运营商提供。

展望
1. 从最初的业务解耦到分布式，从开始的单机房部署到现在的多城多单元，我们的系统架构逐步承接更多的流量和更大的挑战。
2. 从原始的线下单机单应用压测，到线上缩容压测，再到最后的线上全链路压测。
3. 各个应用的自我保护和自我恢复技能每年都在增强
4. 技术架构全面云化已经成为双11技术的必经之路，只有这样才能用更低的成本提升用户体验，去迎接零点那突如其来的最大的高峰。