简介

精彩点评

• 

  Black

  推荐

  从阿里本身业务，以及电商类业务去考虑确实不错，但是如果生产制造，能源等其他企业来说，技术平台可以改革，但是很多比如平台零售特有的分仓，主仓等等这种就会有问题，行业迹象比较明显。

• 

  李剑

  推荐

  六个小时，先通读了一遍，囫囵吞枣，不求甚解。本书其实是一部互联网技术发展史，从初期服务器搭建、数据库垂直水平扩展，到中间业务发展推动技术架构革新，厚中台薄前台思想沉淀，再到后期高可用、灾备、监控、限流等理念完善，无不浓缩着阿里技术先驱的工匠精髓。 当然，阅读此书需要一定的技术功底。行外人，初读不识书中意；行内人，再读已是书中人。选一个静谧时光，泡一杯温馨咖啡，读这本技术历史，细品珠玑，沉思现状，洞悉未来，快哉矣！

• 

  振杰

  推荐

  让人对阿里的技术现状，特别是演进的脉络有了整体的认识。好的架构是生长出来的，是不断发现问题，不断自我否定，敢于试错，善于复盘，强于改进的结果。如果说阿里的技术架构并非试用所有行业，其思考方式和破茧成蝶的能力绝对值得所有公司借鉴。

• 

  高斌

  推荐

  第二次读，第一次在一年以前，每次感悟都不一样，也许和这一年的实践和思考有关[微笑]

• 

  林之晓

  推荐

  服务化中台打造了规模服务能力，沉淀了行业领域经验，更可以通过开放平台等形式输出变现。对企业的业务创新试错，海外扩张都提供了极大便利。

• 

  赵元芳

  推荐

  中台建设关乎技术架构，业务架构，组织架构，对企业转型至关重要。

• 

  莫問

  推荐

  通过共享业务中台将企业中多套系统共性的能力沉淀下来，各业务方只需基于中台能力去做更多的整合和创新，可以免去很多多余的开发，不但减少了成本，而且业务响应也会更加及时。同时中台的存在会打破之前的烟囱式开发数据对接困难的情况，为后期大数据的发力做好了铺垫。 一个企业若真要实施建设一套共享业务中台阻力肯定也是巨大的，毕竟这会动很多人的蛋糕，这需要企业的CIO拥有极强权威和魄力，各职能部门有清晰的认知和配合的态度，过程必然不会顺利，若真要涉及组织架构变动，某些尸位素餐的领导们必然会奋起反抗，推诿扯皮甚至中伤破坏这种事，呵~

• 

  2046

  推荐

  这本书最大的价值不是技术，而是对技术如何与业务融合这个It业的永恒话题，给出了阿里的思维。这种思维直接影响了组织架构，也影响了新业务的创新与试错方式，及数据运营，KPi 考核。 对于微服务、服务中心、中台的各种大众误解，在这本书中也给出了清晰的校正。这种超越技术本身看待技术的格局与高度，值得所有从事技术的人借鉴。

• 

  丁凌云Leo

  推荐

  第一本打了5分的书。 书的本身没有绝对的好坏，只有对于读者相对的好坏和意义。 作为对技术有初步了解的产品经理，也时常看到听到“大中台小前台”概念，但本书的阅读让我对这个概念有了系统性的理解，也知道了“概念”落地时会遇到的问题。 讲架构，这本书本身各章结构就很有逻辑性，遇到现状-》解决方案-》引起新的问题-》解决方案……循环、螺旋式解决。 其中，还有对难点、如何做的更好、商业性的补充～ 

• 

  lee

  推荐

  也是很不错的一本书、企业IT架构转型和实战，阿里也从烟囱式架构演进soa再到微服务等等、主要还是那些人会去思考、现在有什么痛点、怎么去改善这些痛点、阿里参观了supercell、业务的试错真的很重要、比如pdd、头条都会在各个看好的市场线进行试错、比如众安在国内有保险、也单独搞了海外保险市场和grab、income深度合作、香港又有虚拟银行、听说今年也在开始尝试基金代销。试错固然重要、还需要看管理层的决定和观念、之所以架构会变化、无非就是感觉要么哪里写的不爽了、问题排查不方便、业务需求过多但没时间去开发、是否考虑合理性、好的架构个人觉得在领域划分合理、代码风格一致、服务可服用可组合、代码和架构的扩展性很重要‼️当然性能和高可用也很重要、服务只要上线、监控真的很重要、不要放过任何一个error或者warn、好好打印日志 基础功还是需要持续锻炼、多思考多找痛点、发现问题尝试去修改去交流

• 

  杨征

  推荐

  阿里中台架构前世今生，六七成比例技术性较强，涉及应用选型仅求混个眼熟，全链路压测平台是经过三年趟出平稳度过双11大促峰值的最佳实践，打通链路尽早发现网络、应用、中间件、存储各个环节存在的问题，遗憾的是第一个案例不够详细，无完美架构，符合战略方向和业务发展、能连贯迭代创造价值的就值得

• 

  Pareto Gao

  推荐

  基于分布式和共享理念进行架构转型，以服务中心引领业务创新与发展，写得透彻明白。赞👍

• 

  Shirley

  推荐

  作为一名非计算机专业的互联网从业人员，读完对于“中台”以及“服务”相关又多了一层认识，非常推荐码农阅读此书。

• 

  郑同学

  推荐

  01懂业务 懂业务是指，能对业务的下一步发展有着自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有的业务提出创新的想法，为企业带来新的业务增长点。 02微服务 SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。 03服务中心建设 服务中心建设要考量的三个重要方面 共享服务中心的架构目的是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重用性；通过服务化来达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。 所以，所有的原则和方法都是为了这些目标服务的，“以终为始”再来看服务中心建设的原则和方法就会明确很多。 从设计层面来看 主要是要遵循面向对象的分析和设计的方法，即业务和系统建模遵循面向对象的基本原则，这些是多年软件工程学的沉淀，服务化不是开创一套新的设计方法，而是一个指路的明灯。 从运营层面来看 服务中心应该是一个完整的业务模型，要有数据运营和业务整合的价值，前面在介绍淘宝的服务中心时，一直在强调服务中心的发展变化性和可运营性，比如淘宝的商品中心，绝对不只是简单的商品增删改查的服务接口，而是建立一个全球最大的商品库，同时提供该商品库的管理运营的方法和配套工具服务。当然淘宝的商品中心建立成这样是淘宝的电商业务决定的，并不意味着其他业务系统也要按这样的标准去建立自己的商品中心，一切要根据业务来做判断。 从工程层面来看 共享服务的架构是基于分布式架构，分布式架构解决了一体化架构在大规模应用上的问题，但是也引入了分布式事务、问题排查等方面的一些难题，所以在规划服务中心的时候，一定要综合评估业务层对服务中心在数据库、业务以及运营方面的需求和技术上需要的投入。不能图一时之快把业务拆得非常彻底，到最后却不得不用很大资源投入来解决技术上面对的问题。 总体上，我们从这三个维度出发来决定服务中心的设计和评估。 04平台性能问题 解决平台性能问题的核心就是数据库事务的异步化。通俗来说，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。

• 

  JianXu

  推荐

  这本书是公司总部框架组的Dennis推荐我读的。首先这个概念就很好，书中一开始就讲了阿里巴巴是怎么一步步进化到大中台的，在这个过程中是怎么决策的。然后针对几个比较大的技术块做了介绍，比如数据分库，怎么做一致性，流量怎么管，框架层面的分布式流量，监控系统，压测系统.... 最后一段讲中间件商店和生态系统那一段也很不错。我们公司platform 这一块我也希望有一天能成为这个样子。将业务沉淀到平台层，然后促使业务可以快速搭积木。同时如果搭好的积木效果好，就会又沉淀到平台层。