尽在双11：阿里巴巴技术演进与超越读后感100字

《尽在双11：阿里巴巴技术演进与超越》是一本由阿里巴巴集团双11技术团队著作，电子工业出版社出版的平装图书，本书定价：79，页数：240，特精心收集的读后感，希望对大家能有帮助。

《尽在双11：阿里巴巴技术演进与超越》读后感(一)：不可多得的好书

好书，推荐做技术特别是做leader的朋友看看此书，难得。制作精美，纸张手感也不错，比一般技术书好很多。看了最大的收获是对业务思路的启发。系统是为数据服务的，链路畅通才能更好地促进业务发展。在技术达到一定水平后，制约技术的还是业务。没有大的事业平台，不可能凭空想出技术。技术是在解决问题中前进的。

《尽在双11：阿里巴巴技术演进与超越》读后感(二)：开阔视野 了解前沿 对阿里表示敬意

1. 拿到这本书大概两个晚上就读完了，说实话挺过瘾的，阅读的过程中会有一种代入感，仿佛自己也置身于那种紧张又兴奋的双11备战过程中，有时候也会思考如果当时自己遇到这种情况会怎么处理；

2. 这本书不仅是介绍了阿里在面对越来越多用户和并发时所采用的技术和架构，更重要的是比较详细地说明了其中的演进过程，在这其中我感觉自己收获良多，特别是对于聚石塔、全链路压测、搜索推荐和中间件这几节；

3. 另外一个印象深刻的是大数据和人工智能给阿里双11带来的变化，从2014年双11人工客服被打爆到2016年智能客服解决率超过95%，这真正的解放了客服的压力，从用户来说体验也得到了提升，我想这样的例子在内部的一些项目里肯定还会有很多；

4. 所以我强烈推荐大家阅读这本书，另外阿里也贡献了很多顶尖的开源项目，分享过很多内部的实践，使得我们有机会了解这个具体的技术和业务架构，我觉得应该予以敬意。

《尽在双11：阿里巴巴技术演进与超越》读后感(三)：阿里巴巴的技术演进

第1章 阿里技术架构演进

五彩石项目对阿里技术主要有两个影响：第一，通过抽取电商公共元素，沉淀了共享服务，降低了创新和试错的成本；第二，形成了一套支持互联网业务的中间件，因为分布式所以要用中间件，而中间件的意义就像阿里技术采用了相同的铁轨宽度、电器采用了相同的电压、沟通采用了同一种语言，持续地降低了学习、研发和运维的成本。

共享服务层的建立很好地对横向业务提供了统一的数据和服务收口，比如手机淘宝、安全、商家服务（TOP），这三个横向的业务就非常依赖共享服务。

第2章 稳定，双11的生命线

全链路压测

系统保护体系主要由五大子系统构成：限流、自动降级、流量调度、负载保护和预案。

第3章 技术拓展商业边界

招商报名，活动基础设施建设

* 价格申报系统价格管控系统

会场，小二有商家共同打造的购物清单

* 主会场、行业会场、标签会场、直播会场

* 会场页面基础搭建、赛马机制优胜劣汰、会场页面平台化建设

搜索

* offline、nearline、online三层体系

* 从2013年起，淘宝搜索就进入千人千面的个性化时代，搜索框背后的查询逻辑，已经从基于原始Query演变为Query+用户上下文+地域+时间

个性化推荐

* 2015年双11主会场个性化算法，即天坑一号，包括三个层次：楼层顺序个性化、楼层内坑为个性化、坑位素材个性化

* 个性化推荐，在内容方面分为商品推荐、店铺推荐、品牌推荐、评论推荐等；从目标方面，分为点击率预测、转化率预测、成交量预测

供应链

* 消费者付款后到最后收到货，有很多个影响消费者体验的环节：截单、赠品、分仓、合单、仓库发货、退款、退换货、发票、流水

第4章 移动端的技术创新之路

Weex

奥创

TMF（交易模块化框架）：改造交易平台核心链路系统，实现业务与平台的分离、业务与业务间解耦、业务可视化配置与发布。

第5章 繁荣生态，赋能商家

聚石塔

菜鸟电子面单：

* 智能分单

* 数据改变物流：基于电子面单的二段码和三段码、全自动化分拣、全网动态路由调度等基础服务，菜鸟创建了一个数据驱动的社会化物流平台

生意参谋

* 阿里数据及产品部在2013年规划建设、2014年落地的公共数据称one data，对数据进行规范化和数据建模，从根本上避免数据指标定义不一致、重复建设的问题。

* 门户方面，实现了多岗多面、多店综合。数据内容方面，强调全渠道和全链路。产品形态方面，把数据披露、浅度分析作为基础，拓展增值产品，为商家提供深度分析、诊断、建议、优化和预测服务。

阿里小蜜

阿里中间件

《尽在双11：阿里巴巴技术演进与超越》读后感(四)：后信息化时代的“最佳实践”

这本书一定要从中观上看，如果只从微观上看的话，很容易因为看的细节过于真切而忽略掉本书的真正价值。因为从微观上近距离观察，这本书只是描述了阿里巴巴作为一家领先的互联网电商企业，其IT应用如何伴随着业务发展不断推进的历程，以及这个历程中IT团队的奋斗、经验和收获。如果我们在这本书里只是看到这个图景的话，那么这本书的读者群体，或者可能从本书中获益的人群就可能仅限于从事电商业务的其他互联网企业人士。但是如果我们能够向后跨出一步，跳出细节，忘掉阿里巴巴的具体业务，以一种中观的视角再次看待这本书的话，我们就将得到一个截然不同的图景。那么如何得到这种中观视角呢，很简单，让我们抛开阿里巴巴业务的具体性和特殊性，忽略到阿里IT应用的具体形式和表象，回归到阿里IT技术的应用的实质，不难发现，无论阿里的IT技术应用还是IT应用技术本质上都是“围绕业务问题，满足业务需要，驱动业务创新，拓展业务边界”，而这一点一直就是企业信息化的基本原则，同时也是基本使命。

所以在这种中观视角下，阿里的IT技术演进就绝不再只是作为一家互联网电商企业的技术演进，而实质上更是一家企业信息化工作演进的缩影，而作为缩影，阿里的特殊性是IT切入的逻辑与时间与传统企业不同，而这种特殊性在企业信息化的维度上并不形成传统企业与互联网企业的分水岭，即使有人有，那也只是观念上的。

正因为有这样的中观图景，所以这本书的读者群体就绝不只是从事电商业务的其他互联网企业人士，而是所有从事企业信息化的群体，所以可以说所有公司都可以从阿里的IT技术应用中有所借鉴。

这种借鉴可以分很多个层次，其中最高的，也是最重要的是理念层次上的借鉴，在这个层次上要颠覆传统信息化的一些迷思。传统信息化领域中存在着许多似是而非、害人不浅的迷思。比如某家在ERP领域中占据领导地位的厂商，其销售精英经常挂在嘴边的一句话就是“他们家的ERP软件融汇了上百位管理学大师的思想，凝结了企业经营管理的最佳实践”。这句话确实很能唬人，很多人真心相信，但是这句话对吗？直接回答这个问题可能有难度，似乎没有直接的答案，我们换个问题就会好一些。因为“最佳实践”其实就是别人的成功经验，所以我们新的问题是“我们直接照搬比人的经验可行吗？”这个问题刚好有一位管理学大师研究过，他在《经验的疆界》中专门讨论了经验的适用性问题，他经过论证指出经验要想发挥作用，是有条件的，不顾条件地生搬硬套，就会吃亏，适合自己的才是最好的，世界上根本没有一个统一的“最佳”存在，如果真有的话，这种“最佳”就是空泛的，因而也就百无一用了。而阿里巴巴的IT技术演进过程就没有遵循所谓“最佳实践”，当然也压根没有什么“最佳实践”可以遵循，而是在吸收消化先行者的经验基础上，结合自己的企业实际情况，围绕要解决的业务问题去开拓去创新，进而完成了自己信息化水平的追赶和超越，在不断拓展业务边界的同时，也在不断拓展IT的边界，在解决了企业内业务问题的同时，开始了IT服务的输出，IT产品的输出，所以阿里的IT成功，不是来自于“最佳实践”，如果阿里真有“最佳实践”也是阿里IT团队创造出来的“最佳实践”，但是阿里的“最佳实践”同样绝对不会是其他企业的“最佳实践”，他们的“最佳实践”也需要他们自己去创造。

《尽在双11：阿里巴巴技术演进与超越》读后感(五)：阿里软件架构发展史。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