关键词：
阿里中台战略思想与架构实战》读书笔记
maquewy 关注
4.3 2018.08.02 22:01 字数 4114 阅读 18480评论 7喜欢 57赞赏 1
背景
最近公司如火如荼的进行中台建设，各种业务中台涌现，迫切想知道中台的发展规划和关键解决问题，比较庆幸看到了这本书《企业IT架构转型之道-阿里中台战略思想与架构实战》应该是标题中台两个字吸引了下~
感触
最近跟朋友聊天，听书介绍，管理培训，最大的收获其实就是思维的转变，思维转变了很多事看着就会更加清晰。别有洞天的震撼。看完了后久久不能平静，里面的很多架构演进，有的比较有幸的看到了参与了，有的正在经历，有的可能即将要经历，觉得井上面的那片天有些扩大的感觉，这种感觉很奇妙~
借鉴
1.阿里中台战略的由来很有意思，是阿里高管15年参观世界上最成功的移动游戏公司supercell，这家典型的小团队模式进行开发的公司，可以最快的推出游戏内测版，不受欢迎，可以迅速的放弃这个产品再进行新的尝试，期间几乎没有管理角色的介入，团队失败后，不但没有惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。它的核心竞争力就在多年的游戏研发中积累了非常科学的研发方法和体系，也就是中台能力。以至于很多模仿者都无法替代。
2.美军在二战时，以军来为单位作战；到了越战时，以营为单位作战；到了中东战斗的时候，以7人或者11人的极小班排去作战，这是今天最灵活的军事组织，也是核心竞争力和打击能力最强的一个组织。而美军之所以能灵活作战，敢放这么小的团队到前方，是因为有非常强的导弹指挥系统，有非常强大的中台能力，能支持这样的小团队快速做判断，并且引领整个打击。
美军作战图
3.名创优品的共享思维，共享店铺，共享设计师，共享生态链
共享店铺，名创优品用匠人打造物美价廉爆款商品后迅速吸引力大批传统服装行业的店铺商拿着最好地段店铺来跟名创合作，店铺共享，极大程度降低边际成本。
共享设计师，同时名创为了将设计多元化搭建了设计师平台，设计师可以拿着自己的设计来找名创合作，一次性买断版权或者靠订单分红，聚拢了大批设计专家，当一系列生态搭建好了之后，名创开始走向了更大一步的共享共享生态链，
共享生态链，全球国家店铺加盟，遍布全球，统一的培训店长，发货供货进销存，由集团统一培养配送，店家只需要将名创当成一处投资即可。目前名创销售额约1000亿 850亿来自海外。
经典案例
阿里巴巴在2003年时成立了淘宝事业部，2008年时成立了天猫事业部，没过多久，天猫与淘宝并驾齐驱，此时淘宝的技术团队同时支持着淘宝和天猫的业务。
这样的组织架构阵型决定了技术团队会优先满足淘宝的业务需求（屁股决定脑袋，大家都懂的），使得天猫的业务团队怨声载道，严重影响了天猫的业务发展。
另一个业务架构层面的问题：当时淘宝和天猫的电商系统是完全独立的两套体系，但同时都包含了商品、交易、评价、支付、物流等相同功能。
早期淘宝与天猫
为了解决以上两大问题，在2009年，“共享事业部”应运而生，主要成员来自于之前的淘宝技术团队，在组织架构上与淘宝、天猫同级别（如上图），集团希望以这样的方式更好地让技术团队同时支持好淘宝和天猫的业务，并将两套电商的业务做了梳理和沉淀，把两个平台中公共的、通用的业务功能沉淀到了共享事业部，避免功能的重复建设和维护，更合理地利用技术资源。然而，接下来的发展事与愿违。虽然组织架构上共享事业部和淘宝、天猫平级，但在对业务的理解和贡献上来说，显然淘宝和天猫拥有更多的话语权，结果是共享事业部在两大业务部门的夹缝中生存。
到此，共享事业部的发展与大多数人的期望有很大偏差。
共享事业部同时满足着淘宝和天猫高压态势的业务支持，在资源固定的情况下，就算团队成员再怎么加班加点，也很难及时、周到地支持好两大业务部门，结果就是业务部门对共享事业部的满意度不高，而共享事业部的同学们内心有苦说不出，只能默默流泪。
2010年聚划算出现了。聚划算平台刚一上线，就展现出强大的流量吸引力，所以一时间大家趋之若鹜，纷纷对接聚划算平台。
后来1688也参与其中，三大电商运营人员各展所长，争占聚划算平台上的有利资源，面对如洪流般的业务对接需求，当时刚成立不久的聚划算团队应接不暇（图）。
这时，集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享事业部！正是有了这“点睛之笔”，共享事业部便有了一个极强的抓手，将原本与三大电商平台对话权不平等的情况拉平，这使得“共享事业部”成为了阿里巴巴集团的核心业务平台。
从2009年开始建设的“共享事业部”为阿里巴巴的架构转型奠定了基础。
2015年年底，当大多数企业忙着进行年度总结和规划时，阿里巴巴集团宣布全面启动“中台战略”，构建符合DT时代的“大中台、小前台”组织机制和业务机制：作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务进行强力的支撑。
收获
烟囱式架构
早期淘宝天猫1688三套电商体系架构完全独立，各自应用独立运维和开发，三座“烟囱”分别矗立支撑着当时阿里集团最为核心的电商业务。
原因：
1.开发团队思考的电商模式不同，需要独立建设
2.新业务团队认为在之前基础上搭新业务会有太多的技术和业务的历史包袱，还不如重新构建
弊端：
1.重复功能建设和维护带来重复投资
2.打通烟囱式系统间交互集成协作成本高昂而比如订单信息 用户信息不得不打通后获取全局会员及消费数据
3.不利于业务的沉淀和持续发展
专家的养成
我们从小学开始学习很多基础知识，更多的是知识点的掌握；随着我们掌握知识点的增多，我们开始有意识地将一些知识点组合在一起，解决一些复杂的问题，关联这些知识点的过程实际上是将这些相关的知识点串成了知识线；随着在知识领域的继续积累，越来越多知识线的汇聚，我们有机会更全面地了解到这一知识领域（知识面），从而构建了对这一领域自身的知识体系，而这时的你相信已经成为这个领域的专家。
可以看到上图中共享交易事业部对于不同业务中交易场景的支持，1688（B2B）淘宝（B2C）天猫（B2C)的各自业务架构师对各自负责的交易流程的业务会非常的精通，不过在某种程度上看到的都只是哥哥业务场景中对交易业务的点，而图片下方的交易中心中的业务架构师所接触的来自不同业务模式下的所有交易相关的需求，这样的阵型是的负责交易中心的相关人员更容易扩展到线和面的维度全面掌握交易的业务。结合上面的理论，共享服务体系能很好的培养出特定领域的专家。
专人做专事？
整个技术团队作为一个组合精密的流水生产线，源源不断的业务需求涌进这条生产线后团队各司其职的人员协同配合，争取最快实现业务需求的满足。优点是可以不断打磨梳理出一套合理且高效的组织架构，但是弊端也会使流水线上的不同角色人员的技能的持续提升会出现发展瓶颈，做了3年开发跟做了5年开发人员可能在开发能力上灭有太大的区别，根本原因就是这两年的差别仅仅是用自己熟练的技能多生产出几个不同的系统。
业务架构师
业务架构师是共享服务中心发展的领路者，也是保障服务中心核心业务保持业务通用性和公共性的最重要捍卫者，能力模型是典型的即懂技术，也对负责的业务领域有相当理解的，通过共享技术的不断沉淀让部门从企业中的“业务支持”的组织职能，转变为基于企业核心业务和数据运营的团队，这个团队会更快更好的支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，这种人才的价值将成为公司最宝贵的资产。
业务架构师一般会一直关心和思考以下问题：
1.当前的业务流程设计中，我依赖了哪些应用，哪些服务？
2.整个链路的依赖路径是怎样的？哪些服务对当前业务处理来说是最为核心的？这些依赖如果出错，会有什么影响？
3.一次业务请求处理的时间到底花在了什么地方？是因为某一个服务耗时很长，还是因为某一个数据库的访问操作自救，需要清晰直观的定位
4.我所负责的业务链路中，过去一段时间哪些服务是出错率比较高的，哪些服务是业务链路的处理瓶颈。
中心化与去中心化
中心化ESB企业服务总线实现的SOA方案根本诉求是实现异构系统（自研应用，商用套件应用，定制开发应用）间的交互，降低了系统间的耦合，更方便高效的实现了对新系统的集成。
弊端“中心点”带来平台能力难扩展问题业务响应慢，由于需要跟企业总线多次交互，对总线的访问和计算压力都很大，以及潜在的“雪崩”影响
去中心化分布式框架除了对SOA特性的实现和满足外，有效的避免了中心热点，雪崩等弊端。
共享服务化中心设计原则
1.高内聚，低耦合原则
2.数据完整性原则
这个原则与“高内聚，低耦合”一脉相承，是把这个思想穿透到数据模型层面，因为服务化架构一个很重要的业务价值就是数据模型统一。这里特别强调大数据的思维，不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据。
3.业务可运营性原则
服务中心首先是从业务出发，单纯的技术层面抽象出来的服务框架一般不作为一个可运营的服务中心。期望服务中心是承载业务逻辑，沉淀业务数据，产生业务价值的业务单元
数据分久必合合久必分
尽可能水平拆分
1.基本拆分 主从同步读写分离
2.水平拆分 基于ID进行hash取模方式实现
3.异构索引表 降低全表扫描
精卫同步
可图形界面配置化一站式同步全链路监控任务调度平台
多条件频繁查询引入搜索引擎平台
采用异构索引的方式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能力的最有效技术手段，但是对于多条件频繁搜索则不建议异构索引，而是建议将数据同步至专业搜索引擎平台，入Lucene,Solr,ElasticSearch等。
异步化
1.业务流程异步化
对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理
2.数据库事务异步化
将大事务拆成小事务，降低数据库的资源被长时间事务锁占用而造成数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。
3.事务与柔性事务
传统事务
CAP 一个分布式系统最多只能在同时满足Consistency一致性 Availability可用性 Partition tolerance分区容错性这三项中的两项
BASE 是指基本可用（Basically Available） 柔性状态(Soft State) 最终一致性(Eventual Consistency)
一阶段事务 二阶段事务 比起一阶段提交，二阶段提交在执行同样的事务时会耗时更多时间，而事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量打到一定数量的时候，就会出现大面积事务积压甚至出现死锁，系统性能和处理吞吐率就会严重下滑
柔性事务
1.引入日志和补偿机制
事务日志记录事务的开始结束及参与者，参与者节点需要根据重做回滚记录到REDO/UNDO日志，当事务重试回滚时，可以根据这些日志最终将数据恢复到一致状态
2.可靠消息传递
要求消息至少投递一次，需要消费幂等
3.实现无锁
由于锁占用大量数据库资源，那么选择放弃锁也是解决问题的一种思路，通过其他手段保证最终一致性和隔离性
4.乐观锁
事务消息
柔性事务的思路，消息服务在其中扮演了事务日志的职能，对全局事务有一个统一的记录和调度能力，事务的参与者通过对消息订阅关系建立了事务间的关联。在采用消息服务实现分布式事务的场景如果出现异常时，一般会采用正向补偿方式，即不会像传统事务方式出现异常时依次回滚，会通过从消息的不断重试或人工干预让事务链路继续朝前执行，而避免出现事务回滚。
事务消息应用
事务消息回滚
总结：其实都不需要两阶段提交这样低效的方式来解决分布式事务问题，可以结合配合方案
1.应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时
2.远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用
业务一致性平台
服务依赖链路众多，业务域数据不一致问题涌现，业务稳定性保障迫在眉睫，要解决这个问题，就需要实现业务处理的过程中，实时监测到业务不一致的问题，在消费者发现该问题之前系统就应该发出了报警，并且转交相关人处理。也许在用户开始投诉前，这个问题就被纠正过来了，这样影响面也就很小了。
目标：
1.高实时的发现业务脏数据或者错误逻辑实现，第一时间发现并及时通知技术保障人员，而不是等待客户反馈。
2.方便的接入各种业务规则，通过脚本规则编写的方式，让各应用快速接入
3.整合订正工具，形成规范的脏数据订正流程
4.业务上线的实时监控，新上线业务可以方便的进行校验
为了避免对业务的侵入，采用的是实践模式，把业务数据变化触发的消息转换为相应业务类型的事件，放入到事件执行队列进行规则检查，实现将数据变更日志接入平台。通过事件的类型和状态，从规则库中获取对应的业务规则去做业务校验。
思维脑图
小礼物走一走，来简书关注我
企业it架构转型之道，阿里巴巴中台战略思想与架构实战
前言： 晚上11点多闲来无事，打开QQ技术群，发现有关‘中心化与引擎化‘的话题，本着学习的心态向大佬咨询，大佬推荐一本书，我大概看了有四分之一的样子，对于我这种对架构迷茫的人来说，如鱼得水，于是特来此推... 查看详情
中台方法论及案例收集
...c;我略作整理归纳，便于查阅，未来会持续更新。阿里巴巴中台缘起阿里，也是落地最好的案例，阿里系出品相关的文章必须首推，尤其是阿里的这本中台战略思想和架构实战这本书，系统的总结了中台核... 查看详情
语言之争与读书有感
...中的妙处。 过年几天时间，我在家里认真的拜读了由阿里巴巴中间件团队技术改造过程中的若干问题而整理输出的技术书籍《企业IT架构转型之道-阿里巴巴中台战略思想与架构实践》。这本书系统的介绍了阿里巴巴启动中台... 查看详情
厉害了！阿里p8架构师用4大技术文档带你深入解读爆火的中台战略
前言根据百度指数搜索“中台”，可以发现中台这个概念从2019年5月21日起突然火了起来，并持续火爆。如果对2019.5-2020.7进行一次关键词盘点的话，中台绝对要算一个。从概念的认知，到实战经验的分享，再到中台战略引起的思... 查看详情
中台方法论及案例收集
...c;我略作整理归纳，便于查阅，未来会持续更新。阿里巴巴中台缘起阿里，也是落地最好的案例，阿里系出品相关的文章必须首推，尤其是阿里的这本中台战略思想和架构实战这本书，系统的总结了中台核... 查看详情
阿里及各大企业中台架构详解
...运维负责。ebay中台架构staffjoy中台平台不等于中台？阿里提出中台战略后，很多企业开始拿着自己的系统与阿里的中台对标。有的企业在十多年前就完成了大一统的集中式系统拆分，实现了从传统大单体应用向大平台... 查看详情
3.数据中台---数据中台建设与架构(代码片段)
第3章 数据中台建设与架构3.1 持续让数据用起来的价值框架 业务数据化=>数据资产化=>资产服务化=>服务业务化3.2 数据中台建设方法论 1种战略行动 把用数据中台驱动业务发展定位为企业级战略，全局谋划。 在中台... 查看详情
《docker技术入门与实战》读书笔记
更改ubuntu的源debhttp://mirrors.aliyun.com/ubuntu/xenialmainrestricteddebhttp://mirrors.aliyun.com/ubuntu/xenial-updatesmainrestricteddebhttp://mirrors.aliyun.com/ubuntu/xenialuniversedebhttp://mirrors.al 查看详情
《尽在双11》－－阿里巴巴技术演进与超越读书笔记
第一章，阿里技术架构演进1、金融级系统的6个关键支撑目标：a、高可用--实实在在的4个9。系统可以容忍各种硬件故障，可以在服务不中断的情况下升级，关键系统，具备异地容灾能力b、安全--及时，多层次检测防御安全攻击... 查看详情
阿里云产品之数据中台架构
1.场景描述客户打包买了很多阿里云的产品，但是阿里云不负责实施，基于阿里云产品与客户需求，拟采用的数据中台架构，有类似需求的，可以参考下，拿走不谢！2.解决方案阿里产品大数据架构图：从下到上，简要介绍下各... 查看详情
《docker技术入门与实战》读书笔记与实践
创建支持SSH的服务的镜像Dockerfile内容FROM ubuntuMAINTAINER from www.mtian.net by mtiannetRUN echo "deb http://mirrors.aliyun.com/ubuntu/ xenial main restrict 查看详情
《reactnative入门与实战》读书笔记
ReactNative介绍 它的底层引擎是JavaScriptCore，调用的是原生组件而非HTML5组件（HTML+CSS+JavaScript构建的组件）。运行时，可以做到与NativeApp媲美的体验，同时因为JavaScript代码可以使用后端强大的Web方式管理，既可以做到高效开发... 查看详情
《大型网站技术架构:核心原理与案例分析》读书笔记
...一起读的另外一本书是《淘宝技术这十年》，都可以算是阿里系的书籍。说真话，毕竟是个小菜鸟，对于大厂还是有很多的憧憬的，对于技术大神完全是抱着膜拜和学习的心态，心里无限憧憬着如果以后能有这些人物万分之一的... 查看详情
《大型网站技术架构:核心原理与案例分析》读书笔记系列
作者：13GitHub：https://github.com/ZHENFENG13版权声明：本文为原创文章，未经允许不得转载。笔记目录1.《大型网站技术架构:核心原理与案例分析》读书笔记2.大型网站技术架构(二)--大型网站架构演化 查看详情
中台服务架构的一点思考
...想是伴随着企业规模不断扩大、业务多元化而形成的。如阿里巴巴将集团20多个核心业务中公共的、通用的业务以服务的方式沉淀到了共享业务事业部，这套共享服务体系为阿里巴巴集团的核心业务赋能，真正发挥服务重用的价... 查看详情
构建数据中台的组织架构
一、中台是一种企业架构1.TOGAF企业架构标准TOGAF是一套企业架构标准。企业架构是指整个公司或企业的软件和其他技术的整体观点和方法。企业架构又细分为业务架构、应用架构、数据架构、技术架构几个方向。其中业务架构的... 查看详情
构建数据中台的组织架构
一、中台是一种企业架构1.TOGAF企业架构标准TOGAF是一套企业架构标准。企业架构是指整个公司或企业的软件和其他技术的整体观点和方法。企业架构又细分为业务架构、应用架构、数据架构、技术架构几个方向。其中业务架构的... 查看详情
hadoop大数据分析与挖掘实战（读书笔记1）
第一章节是从一个餐厅的角度出发，引出来许许多多的相关概念。第一个概念就是什么是数据挖掘，这个简单，望文生义就好了。它的名字本身就诠释了它的内涵。基本任务还是得记一下：1分类与预测。（有点像量化，股票交... 查看详情