简介

精彩点评

• 

  Alexy

  推荐

  关于架构的第1本书，关于阿里的第N本书，看完《人人都是产品经理》、《蚂蚁金服》、《智能商业》、《淘宝技术这十年》等阿里系大神写的书，对阿里的架构充满好奇，这本书满足了我所有的想象，收获3点：1所有的架构来自需求确定，不是计划和管理的结果；2团队一起面对问题解决问题，才能创造一切不可能；3完美的架构都是扛得住1111的冲击也经受住智能化转型的敏捷转型。书中从技术、管理者、架构师的角度深度讲解了阿里中台的前前后后，颇受启发。如果一个团队内的每个人都是主人翁的心态每天问自己：如果不是我,那会是谁?如果不是现在,那是什么时候?那么，这个战斗力除了肉身可以使其消亡，还能有什么能打败？我想像不到。非常受用的一本书，强烈推荐。接着我会读《在线》、《ODPS权威指南》，来和我一起阅读吧。

• 

  大耳朵豆豆

  推荐

  全文精读-总结 为什么要做中台？ 传统的系统架构是烟囱式的，有以下弊端： 1、重复建设 2、企业数据被分散在各个子系统中，系统之间的交互和集成成本高 3、不利于业务的沉淀和持续发展 为什么ESB不行？ 1、ESB是中心化架构，有单点问题，容易形成性能瓶颈 2、ESB重集成，重稳定，不利于进行业务沉淀与运营 为什么采用共享服务架构： 1、将相关业务的数据和服务能力在统一收拢，支撑所有前台业务的快速迭代 2、有利于业务的沉淀，培养既精通业务，又熟悉技术的复合型人才，同时基于海量数据，进行业务深度运营和创新 共享服务架构 提供什么能力？ 1、服务能力（B端C端、内部外部客户），主要支撑在线业务 2、数据能力（大数据离线实时接口），主要支撑业务运营、微服务运维架构 引入服务中心 1、根据业务和数据的完整性和独立性划分，比如用户中心、商品中心、交易中心等 2、务实原则，不做理想化和太超前的架构设计，尤其不要拆分太细，会造成延时过长、分布式事务过多等性能问题 服务化框架的选择？ 微服务HSF 数据库能力的扩展 1、通过服务中心，天然做了一次业务领域的垂直数据分区 2、读写分离、分库分表（异构索引表降低全表扫描频率，82法则，20%的频繁查询业务做异构索引，其他情况忍受全表扫描，降低系统复杂度） 3、不同的数据访问模式采取不同的数据库类型： 定位少量记录用关系型数据库 实时海量数据定位或者聚合计算用分布式列式存储hbase 结构化数据模型访问redis scheme扩展mongodb 离线计算hadoop 流式计算flink 系统间实时数据交互用消息队列 复杂条件实时查询采用搜索引擎 异构索引表：比如基本表用订单id做分区，可以增加一个以用户id为分区的异构索引表，避免用户维度数据查询时的全表扫描；可以类比为关系型数据库中的非聚集索引；精卫是一个MySQL的数据触发器+分发管道，可以用来构建异构索引表 分布式理论 zk属于CP，当master挂掉后，会停止服务，等重新选举结束后，才能提供服务。 实际系统中的共识系统，一般都通过维护一个单点，实现全序广播，进而实现共识；同时通过两次投票（一次选出master，一次对master发起的提议进行表决）实现共识，两次投票都必须超过半数参与者，保证两次投票至少存在一个重叠的节点，该节点的存在证明，是最近一次选出的master发起了提议，并且被大家投票通过 BASE理论=基本可用+柔性状态+最终一致，允许不同节点间副本同步的延时就是柔性状态的体现，比如MySQL Replication的异步复制 分布式事务 1、2PC，两阶段过程中，资源处于锁定状态，无法支持高并发 2、柔性事务 日志方式：通过日志进行解耦，减少资源锁定时间，在互联网业界采用日志方式实现柔性事务的比例非常大，但并没有如XA这样的技术标准和规范，实现非常的粗糙，只是简单的采用数据库进行了分布式事务过程中的状态记录，对于事务中异常处理和补偿回滚支持是明显不够的，并不能完全意义上的满足业务的最终一致性，而且一旦出现问题，所投入的人力维护成本也非常高 基于事务消息 a、本质上是通过消息，将事务解耦，减少资源锁定时间 b、在MQ发送方（即整个分布式事务的发起方）执行第一个本地事务前，会向MQ服务端发送一条事务消息（事务消息功能是阿里MQ平台特有的一个功能特性），事务消息在MQ的服务端处于一个特殊的状态，等待被rollback或者commit c、在采用消息服务实现分布式事务的场景如果出现异常时，一般会采用正向补偿的方式，会通过消息的不断重试或人工干预的方式让该事务链路继续朝前执行，而避免出现事务回滚，原本通过数据库的事务特性实现的事务执行检查和回滚都需要靠开发人员来实现 TCC:也是两阶段，通过Try实现业务的软隔离，减少资源锁定时间，这里的软隔离，比如将某个账户的一部分金额临时冻结，但是不锁定账户本身；开发成本高，每个事务操作每个参与者都需要实现try/confirm/cancel三个接口，对于开发人员的心智负担过于沉重 TXC a、相比于传统的两阶段提交方式，最大的区别是，XA在准备阶段是没有提交本地事务的（但是会锁资源），而TXC则是立即执行的，避免了在分布式事务中对于数据的长时间锁占用 b、从本质来说，将数据库提供的锁机制提升到了TXC服务端（支持横向扩展）进行了实现，实现更轻量，在同样实现事务隔离性的前提下，大大提升了整体的数据库处理吞吐率 c、包装了所有数据源，拦截每次sql执行，并自动生成undo和redo日志，支持无干预的回滚和重试 d、在SQL执行之前，将要修改的数据从数据库中获取，以Undo日志的方式保存起来，用于将来回滚；在SQL执行完毕以后，会再次获取到修改后的数据，保存为Redo日志，用于业务回滚前脏数据的校验 缓存 库存商品大促架构实战： 1、客户端设置etag 2、详情页和购买页都从缓存服务器取 3、小库存情况下：购买成功，乐观锁db扣减库存后，更新缓存，用户就能看到最新的库存 4、大库存情况下：事先将库存同步到缓存，下单时不直接扣减db库存，而是创建订单，避免了多线程修改同一行数据；创建订单和更新缓存可以采用基于消息事务的分布式事务实现 数据运营 核心是要搭建一个分布式的日志分析平台 做法是定制所有的服务层和数据层中间件，设置traceId(1.2.x)，日志上传到日志分析平台，基于日志可以进行各种后续的处理，包括：调用链分析、服务监控、业务数据监控等 平台稳定性 降级、限流、流量调度（通过hsf configserver设置权重实现） BCP（Business Check Platform)通过事件模式，监听业务数据变化触发的消息（如精卫、MQ、Mysql等平台消息）并转换为相应业务类型的事件，基于业务规则进行校验，让平台稳定性的能力从技术维度延伸到了业务维度 开放平台 淘宝将内部沉淀的服务和数据能力开放给商家或者商家IT服务商，商家IT服务商往整个体系中输入自己所擅长的垂直或细分领域的专业能力，商家提高运营效率，降低成本，最终淘宝、商家、商家IT服务商、用户都从中受益

• 

  668

  推荐

  本书结构清晰，讲述阿里技术的发展史。是比较好读的一本书，建议配合《淘宝技术这十年》一起看效果更佳。通读下来，对阿里中台由来及建设过程有了进一步的了解，以及熟悉了一些阿里技术产品。 下面整理了下各个主要章节的读书笔记。 第一章 介绍了阿里中台战略的起因是马云和高管受 supercell 公司的影响。 第二章 主要是讲中台架构的价值。 从技术方面讲，是SOA面向服务的，相互解耦的，也导致各子系统的数据都在一块，为大数据分析提供了更好的环境。 从业务方面讲，中台系统可以推动业务创新，减少业务快速试错和迭代的成本，当然业务也会倒逼中台进行迭代升级。 从公司组织形式讲，中台架构是团队可以更小但是更有战斗力。 第三章 主要介绍了淘宝在构建共享服务体系是在中心化和去中心化服务框架上的抉择，以及介绍了最终实现的 HSF ，一个去中心化的分布式服务化框架。 第四章 介绍了淘宝服务中心划分的经过，按时间先后依次拆出来用户中心、商品中心。还有比较大的交易中心和店铺中心。然后逐渐演化出其他中心。 服务中心是领域概念的体现，不仅仅是只对外提供接口，还处理自己领域的事情。还可以再进行细拆，比如交易服务中心内部还分购物车服务和订单服务等。 这块跟 DDD 的领域应该是一致的。 服务中心的划分原则，高内聚低耦合，保持数据完整性，不断发展建设，业务可运营。 这块不就跟 DDD 里面划分限界上下文原则一致嘛。 第五章 服务中心最容易出现的瓶颈在数据库。解决数据库瓶颈主要的两个措施是读写分离和分库分表。 分库分表的原则：数据尽量平均拆分，尽量降低事务边界。 针对分库分表后可能出现的分表全表扫描可以通过建异构索引解决；复杂查询通过搜索引擎平台来解决。 淘宝分布式数据服务产品有 Cobar,架TDDL（Taobao Distributed Data Layer),DRDS（Distributed Relational Database Service）。实现数据异构复制的产品是精卫填海。 第六章 主要介绍分布式架构下实现最终一致性主要的两个手段：补偿事务和两阶段提交。并且介绍了支付宝基于此理念开发的 XTS 框架（细节暂时还没看明白(>﹏<)）。 另外讲缓存应用时提到： 小库存秒杀商祥页库存从缓存读，支付时使用悲观锁机制扣减数据库库存并同步更新缓存，来保证不超卖； 大库存促销 数据库库存先同步到缓存内，商详页库存读缓存，下单时先生成一个用户不可见状态的订单，支付时走队列顺序扣减缓存库存，扣减成功后更改订单状态为用户可见，这样将原本需要频繁更新数据库库存转为更新缓存，大大提高了性能。 第七章 主要介绍阿里的分布式服务调用链跟踪平台——鹰眼，通过对应前端 url 的全局唯一 TraceId 识别是哪次请求的，使用 RPCID 来确认服务调用的先后顺序。 必须一提的是 TraceId 是通过 HSF 等中间件层来传递的，对业务开发人员完全透明。 第八章 介绍从共享服务中台角度提高平台稳定性的几个手段和产品。 限流和降级：TMD 从平台流量入口实现限流，现。Sentinel 哨兵平台实现服务层限流，同时也提供服务层降级的功能。 流量调度：通过修改 HSF 系统中 configService 中对应服务提供者的权重，实现服务层流量调度。 开关平台：switch 开关平台。 容量压测和规划：通过线上真实流量导流到待测机器评估出单机性能。 全链路压测：模拟更真实流量，提前发现问题。 业务一致性检验：BCP 实时业务审计平台。 第九章 阿里服务中心如何一步步升级为共享服务平台（Shared Platform as Service, SPAS），API -> Product ->Solution as Service. 共享服务平台的任务是 能高效率的对接前端业务，业务持续沉淀和创新。 总结共享服务平台的 KPI 是 保证服务稳定（比例最大），服务创新，服务接入量，服务使用方满意度。

• 

  Jason

  推荐

  作为一名产品汪来看本书，总共花了七个多小时读完，是一本难得的从宏观角度领悟技术大拿们技术思维的好书！总体上文章循序渐进，行文流畅，从公司面临的问题出发，到组织架构前后演进历史，逐层推进介绍了技术架构师们如何跟进改造技术服务体系建设以保证业务和公司的发展，让我感觉自己也深处那个改革的潮流中。再结合自己所处公司的环境也正进行大刀阔斧的组织架构升级，核心理念也是基于“前台和中台分离”来重构技术体系，不得不说阿里巴巴不愧是一家除了业务领先具有前瞻性之外也给业界在复杂系统的架构上输出了很多宝贵经验。 但个人又觉得，“大中台小前台”这个理念并不是万能的钥匙，并不适用于所有公司。每个公司的发展包括业务层面以及系统架构层面，都需要结合自身所处阶段来进行解构和重塑，只有业务发展到一定阶段再来按此思路升级整个系统才是明智的，否则前期只要能够SOA化快速响应业务发展方为上策。 最后，我想说的是，本书虽然只是介绍了架构升级转型的思路，并未code by code的说明如何架构该系统，但这个时代并不缺会coding的人，思想价更高。也强烈推荐深处互联网时代的IT人都阅读一下！ 以上观点若有不妥还请指正！

• 

  季称利（纯阳子）

  推荐

  纯阳书评第322期《纯阳子和你聊聊中台（二）》（借本书宝地，发表本人对中台的看法。）上一篇聊中台的文章发布以后，有不少朋友反馈称，文章前边讲中台思维的本质很有新意，可惜后边就写的有点虎头蛇尾。尤其是后边阐述技术如何破解“先整合、再共享”这种思想所造成的系统脆弱性和瓶颈性问题，篇幅太少，就那么几句话，给人的感觉是花了很大力气抛出问题，但是说到解决问题时，又语焉不详，草草收工。自己看了一遍，确实如此，所以索性另辟一文，专门探讨以上问题。 上文说到，中台的降低了成本，带来了效率，但也带来了系统的脆弱性和瓶颈。群体中单个事物各自保有自己共性的时候，事物所形成的系统具有很强的稳定性，而把群体事物中的共性抽离出来成为群体共享中台以后，中台的崩溃就会带来系统的崩溃，所以中台本身就成了痛点。这个问题导致中台的坏处大过带来的好处，所以中台就没有机会发展起来。 接下来我们进入今天的正题，为什么技术的进步为中台的发展创造了条件，为了说明这个问题，我们先研究一下中台的关键痛点是什么？而要想研究中台的关键痛点，又必须研究中台的结构，昨天我们提到如果从思想的角度看中台的话，中台会体现在各个层面上，体现在组织上就是组织中台，体现在业务上就是业务中台，体现在数据上就是数据中台，而体现在技术上就是技术中台。显然在以上罗列出的四个中台中技术中台是最基础的中台，最脆弱的中台，同时也是最容易形成系统瓶颈的中台。没有技术中台的支撑，提到的其他三个中台，以及没有提到的未来或有的其他中台，轻则无法有价值的运行，重则压根就无法存在。比如说用于集团企业内部财务共享的财务中台，从人员的角度讲涉及到了组织中台，从财务业务处理的角度讲也涉及到了业务中台，从全集团财务数据的沉淀、汇总分析的角度讲又涉及到了数据中台，但是这所有的中台要稳定运行，或者要成立的话，必须要有一套高度可靠的信息系统，而后者就涉及到了技术中台。可见说相对于其他几个层面的中台，技术中台是对中台能否成立影响最大的因素，而且是唯一一个刚性因素。所以说解决了这个刚性因素的高可用和资源瓶颈问题，中台具备了成立的基本条件。 而近些年互联网公司推动并引领的微服务架构、云计算、DevOps、容器等技术的发展恰恰能够解决技术中台所需要解决的脆弱性和资源瓶颈问题。先说脆弱性，传统IT技术下系统是单体架构，部署在小型机中，尽管可以通过一些硬件冷备、数据库热备等技术提高系统可用性，但是系统还是会出现宕机，停服务，更何况系统还需要不断停服务升级打补丁。接着上边的例子，我们可以看到，如果有公司在这样的技术条件下做财务中台，会死的很难看，因为一旦系统宕机，或者停机升级，意味着全集团的相关财务工作马上停滞，无法再开展，相关业务会受到影响，而一旦这样的系统真的崩溃，可能整个集团相关业务都跟着崩溃。而采用资源的弹性伸缩、应用的出错容忍、服务的故障迁移等技术后，这样的情况就可以有效改善，服务都部署在容器中，一个服务有问题了，系统可以自动侦测到这个故障服务，然后直接把它干掉，再重新启动一个服务，一台X86物理主机坏掉了，几乎对应用没有任何影响，因为服务部署在云上，把这台物理主机上跑的东西随机搬个地方就可以了。系统要升级，也没问题，新旧服务同时并行，逐个替换，逐渐的增加新的服务，下线旧的服务就可以了，用户什么都没感觉到，升级就完成了。到了业务高峰期了，用户多了，访问量上来了，系统会自动监控到在用系统资源的使用率，需要的话自动启动服务，增加资源，然后等业务高峰过去以后，系统再自动下线服务，这样系统的资源瓶颈问题也就搞定了。这些技术的应用，既有效保障了系统的高可用，大幅消减了系统脆弱性，又解决了系统的资源瓶颈问题，且还因为这一切都是系统自动完成的，无需人工干预，而保持了相当高的效率水平。 综上所述，正因为技术的进步解决了中台的脆弱性和瓶颈性问题，中台的好处显著大过中台的风险和成本，中台就在经济上可行了，希望这次把这个问题给一次说清了。