淘宝架构演进背后——零售业务中台架构设计探讨及实践
行业背景
零售行业困局
目标
业务中台的理念
服务如何沉淀
技术体系与建议
业务中台的技术要求
产品体系与建议
全渠道营销解决方案
泛电商解决方案
客户管理系统解决方案
行业背景
政策因素：包括供给侧改革，合理调整产能，增加有效和中高端供给。中国制造2025，信息技术与制造技术相结合，推动生产管理和营销模式变革。“十三五”规划纲要，加快建设数字中国。
时代发展：大数据、云计算推动了电子商务快速发展。企业服务技术加强，互联网应用与企业传统软件相结合。物流、支付等技术逐步完善，对制造业的支撑能力逐步加强。
企业自身发展因素：从客户需求入手，倒逼企业结构转型。与客户建立沟通渠道，促进销售增长，提升服务质量。
零售行业困局
信息不对称被打破，消费者主权时代到来。互联网/移动互联网、社交应用的高速发展，万物更易互联；商品、商业行为不对称已经被打破，传统营销已经失效。
传统渠道扩展野蛮生长模式已经过去。租金成本、人力成本、制造成本不断上涨，行业集团陷入关店潮。
运营效率低，高库存、高缺货。供应链速度慢，运营效率低，库存分布不合理，高缺货与高库存并存。
所以，新零售的实质就是零售数据化，尽可能借助互联网、物联网、云计算、人工智能和大数据等技术实现零售的“线上+线下+物流”互联互通。
我们定下了四个目标：经营思路要从以产品为中心转变为以用户为中心；不仅在交易时与客户有互动，在交易前和交易后也要与客户有互动；营销渠道从传统媒体扩展到口碑传播；从规模化、标准化生产变为能够满足个性化和定制化需求。
目标
会员体系：线上会员、线下会员的融合与打通，一致的用户画像。
商品体系：线上商品、线下商品的融合与打通，一致的商品信息。
订单体系：全渠道下单体验，实时订单管理与跟踪，高效的运营支撑体系。
O2O服务：线上下单、线下消费、线下服务，极致的用户体验。
售后体系：流畅的互动平台，高效的安装服务，人性的客户关怀。
业务中台的理念
业务中台的核心价值就是能够让任何一条业务线都具备整个公司的核心能力
阿里业务中台的位置。所有业务共享单元的能力共同支撑了阿里巴巴整个集团业务的发展。业务中台能够赋予整个企业快速进行业务创新的能力。
SIP做的系统都是以一个业务域从头到尾打通为主。而业务中台是水平的，在这个平台上需要建设自己核心的业务中心。比如在维护、建设前端业务线的时候不能有自己的会员中心，必须把所有的会员纳入到会员中心里。这样不仅可以快速创新和试错，也可以防止业务做大后会员之间的打通。所以使用业务中台的第二个好处是其数据层面本身就是打通的。
业务中台为企业提供快速试错创新，能给企业带来的业务中台建设的方式不是一蹴而就的，它是随着企业本身信息化建设持续进展和业务不断创新最终沉淀下来的。
服务如何沉淀
这里大概有三个最基本的核心要求和两个基本能力。第一个是开放，所有业务中台的信息必须对外开放，能够极大促进企业本身业务能力的发展。
第二个是滋养。现在传统企业也需要业务创新，只有新的业务不断出现、不停地试错才能让业务中台做的更好，才能真正沉淀出哪些是企业独有的。
第三个是数据，线上线下数据产品的创新和对数据的应用。
在此之外，有两个基本的能力保障。
服务，能力是以服务的方式对外提供的，所以必须确保服务足够核心。我们在抽象定义业务中台的时候会面临个性化诉求，在服务层面上我们会做一次明确的定义，我们只能做到80%的抽象，还有20%的个性化需求是会以特定方式做二次性开发。
稳定，专业、专注带来稳定。这点对于传统企业的技术团队是很好的
传统企业对业务中台一般会提两个问题：需要配备多少人？需要花多长时间才能把业务中台建设出来？面对这两个问题，业务中台需要做到外松内紧，也就是说对外体系要做到创新、应变、开放、高并发、可扩展，对内体系要做到严谨、规范、集中、可追溯、可深挖。
业务中台的技术要求
架构方面：去IOE架构；共享服务化；低耦合高内聚、弹性伸缩；支持二次开发；完全分布式。
技术方面：开发体系基于最佳实践；采用先进成熟的技术；具备良好的开放性和可移植性；整体协作，快速迭代。
性能方面：7*24小时不间断稳定运行；系统平均无故障率≥99.9%；支持高开发；响应时间不超过1秒。
安全方面：系统、数据库具备高可用性；具备安全备份策略；数据不丢失；可防止网络攻击和黑客入侵。
架构蓝图最底层是阿里云平台，中间建议采用互联网技术做技术平台服务。基于阿里云平台架构，以共享服务体系为核心建设业务中台体系；基于阿里的中间件技术体系，建设业务中台；通过共享服务打通商品、会员、库存、订单、结算，快速支持上层业务。
产品体系与建议
全渠道营销解决方案
全渠道是指以实体门店、电子商务、移动互联网为核心，通过融合线上线下，实现商品、会员、交易、营销等数据的共融共通，为顾客提供无缝化体验。主要是指会员通、商品通、交易通、营销通。
泛电商解决方案
常见的电商模式包括：平台电商，招商为主，平台服务于两端；垂直电商，商品自营，采销一体或生产到销售；混合平台，招商+自营相结合。企业电商与上述三种都不太一样，它需要对接上述三种平台，还需要兼顾线下门店的销售，比纯粹的电商类平台更复杂。
商品要解决的两大问题：一是众多商品的分类、抽象和定义；二是用户购买路径的可定义，购买路径由类目+属性构成的导航来支持，需要有搜索参与。
商品设计的目标必须能支持多种不同商品的灵活构建，总体思路是采用类目属性体系。
客户管理系统解决方案
客户管理系统一般存在三个问题：客户数据不完备，因为大量线下、渠道用户数据未纳入，现有用户中心管理不到30%用户，用户基本信息字段缺失，姓名、电话、住址等，用户订单等业务数据缺失；客户数据不一致，相同用户，姓名/称呼不一致，基本信息登记混乱，订单等业务数据各系统不一致；客户数据缺乏共享，各渠道单独注册用户，数据大量重复、用户体验差，售后、客服的用户信息来源多样化，效率低、用户体验差，不同系统用户数据割裂，无法360度画像，用户分析和营销缺乏精准度。
所以需要统一用户管理，为线上线下渠道提供统一用户管理，包括统一注册通道、账户管理、基本信息用户清洗去重机制等；统一用户登录，为多渠道提供统一单点登录管理，提升客户体验，支持账号密码、手机、微信、二维码等多种认证和安全管控手段，支持页面H5代理、api oauth等方式接入；数据共享，各个业务系统客户数据打通共享，对应的业务部门协同服务，让客户得到统一的消费体验。
售后服务解决方案
基于收集到的各种用户信息，如用户基本资料、购买情况、浏览行为、售后服务情况，建立用户画像、用户标签、用户购买喜好、同人模型。用户模型可以为各个业务系统提供支持，建立完整的用户profile，形成完整的CRM体系，可以有效的形成服务闭环，提升整体服务体验
当时，张勇担任阿里巴巴集团CEO不久。他解释，在大中台、小前台的组织机制中，作为前台的一线业务会更敏捷，更快速适应瞬息万变的市场，中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。
几年过去，中台对于阿里业务支撑与带动作用非常明显。阿里巴巴集团CTO、阿里云智能总裁张建锋在不同场合多次提到，由于智能中台，“每年几万亿的交易额，内部只有几百个运营。”阿里财报显示，2019年财年，阿里巴巴中国零售市场的总GMV为5.727万亿元，2020财年，这一目标是1万亿美元。
同时，阿里中台已经成为一种可以复制和输出的能力。张建锋表示，如今在海外再造淘宝天猫，可能只需要两三个月时间，盒马仅用4周就开发上线。
去年以来，腾讯、百度、京东等互联网公司先后效仿阿里设立中台。这些公司的目的很明确，试图通过中台实现技术的内部协同、节省资源，同时提高效率、加快创新。
数据存储能力：在处理数据之前，首先是要收集用户的数据并进行存储，在淘宝这款亿量级APP上，存储的数据是海量的，体现了阿里中台的数据存储能力。
数据治理能力：虽然存储大量的数据，但就意味着耗费的各项成本也是巨大的，为了节省成本和提高运转的效率，阿里并不会将所有的数据都收集起来，因为数据中往往存在大量的无用数据，中台则将这些数据进行处理，选取对于此时有用的数据，这样处理下来，中台的负担也就大大减少。
数据计算能力：试想11秒订单额就达到了1亿元，每秒发生的订单数以万计，没有强大的计算能力，又如何反馈到数据大屏上。
大家除了听到淘宝的总成交额之外，也肯定会听到：手机销售额XX第一、第二、第三，销售额达到XX元；智能门锁XX品牌位列第一，上升多少位；销售额排名前五分别是XX城市；城市最受欢迎的产品是XX等等。淘宝已不局限于汇报自己卖了多少东西，达到了多少销售额，而是分别统计了不同的分类、不同的城市、不同的产品的数据情况。这其中，体现了阿里数据中台强大的“标签能力”。
用户数据标签：中台在获得用户数据后，给用户的每一个特征打上标签，用户所属区域、用户性别、用户喜爱购买的产品、用户使用时长、用户消费额……都被打上了标签，当需要统计某项数据时，再把需要的标签进行组合。
商品分类标签：中台给商品分类打上标签，是为了日后方便统计，每一个商品，都可以带有多个标签，例如小米9，带有的标签可以有：手机、小米、骁龙855、三摄等等。当中台将标签进行组合的时候，就是一份完美的数据报告。
为什么淘宝要公布这些数据？
为什么淘宝要不辞劳苦地去弄这么多的数据，再以各式各样的方式公布出来，笔者想，可能是因为以下的几点：
股价的影响：作为一家大型上市公司，股价就是公司的大动脉，你公布了一份漂亮的数据报告，就相当于向外界宣称，我的公司规模非常大，并且是拥有非常强大的盈利能力的，此时投资者才会更有信心去买你的股票，或者留住股票；股东对于自身持有的股份也会更加具备信心。公司的股价高，不仅外界有更多的人才想要进入公司工作，内部人员对于自身的公司也会更加地认可。
商家间的竞争：淘宝会公布产品之间的TOP排名，当商家得知自己的排名之后，下一年双十一会想各种办法去增加自己的销售额，从而提升排名，商家之间的竞争其实也帮淘宝带来更多的收益。
数据、中台能力的体现：如果说做中台总是在背后默默地付出，那么双十一的数据大屏、各类数据排名报告则是中台部门能力展现的最好一次机会，事实也证明，阿里的中台部门双十一的成果已经获得了足够高的热度及关注，数据能力毋庸置疑。
我们又能学习阿里什么？
很多人会说，阿里是一家大公司，无论人力、资源都非常多，做出来的中台肯定厉害，我们这些小公司完全没中台的概念，更不要说去做中台了。但其实，哪一家公司不是从小做到大呢？在阿里刚开始做中台的时候，投入的资源肯定比不上淘宝的前台产品，但正是阿里中台团队的决心，向整个公司证明，中台也能做好，中台能为公司带来巨大的利益，那么，我们又能学习阿里什么？
给予耐心，支持给中台团队：做中台，并不像做前台业务一样马上就能见到成效，往往一些公司投入了资源、时间去做，但短期内没看到成效后，就马上停止了中台业务，首先作为公司技术负责人，应保证中台的方向是对的，若方向没问题，请给予耐心，以及足够的支持给负责中台的团队，请相信他们，日后中台能给整个公司带来极大的帮助。
没有中台成品，先树立中台概念：如果小公司当下没有足够的资源去做中台，并且对小公司来说做中台的性价比也不高，但可以先树立中台的概念，具备数据思维，要去思考哪些数据对我们公司的业务足够重要，去思考怎样处理这些数据，方便运营的同学做出决策。
指标不应以“多”为荣：很多公司为了体现自身中台的实力，往往把所有的指标数据、各种字段都往数据仓库中塞，但最后往往发现真正有用的就那一小部分的指标，其中带来的数据损耗是巨大的，系统处理数据的时候会浪费掉许多资源，因此，负责中台的同学应去与运营同学讨论，需要的数据到底是什么，再将数据拆解为指标、字段，将无用的去掉，有用的留下。
合理利用开发资源，开发最好的中台产品：手动做100个报表，比不上做一个BI报表工具，很多时候公司为了满足短期的需求，往往业务方需要什么报表，就去开发什么报表，往往导致报表数量越来越多，变得越来越乱；但从长远考虑，如果时间允许，其实可以集中更多的资源去开发一个BI报表工具，用户只需自由选取需要的指标、字段，再填写筛选条件，提交任务之后，系统自动执行sql，等任务执行完毕后，一份自定义的报表就诞生了。
在前台业务逐渐成熟的当下，如何做好中台，是一件值得琢磨的事情
1、哪些不是中台，而是应该叫平台
做开发，有所谓的三层技术架构：前端展示层、中间逻辑层、后端数据层。我们现在讲的中台不在这个维度上。
做开发，还有所谓的技术中间件。一开始我们没有中间件的概念，只有操作系统、数据库这些简单玩意，后来有了所谓的分布式计算，才有了所谓的中间件。如分布式组件容器（如EJB容器/COM容器），如分布式事务（有了分布式事务协调中间件），如需要在分布式应用之间传递数据就有了分布式消息队列…。从而，中间件成了一个独立市场。但是，我们现在讲的中台也不在这个维度上。
现在到了云计算时代，云计算整个大体系被简单粗暴分为SaaS、PaaS、IaaS，有人就混淆视听，就把PaaS叫做中台，中台就滥了：Spark/Hadoop叫做中台、TensorFlow 人工智能叫做中台、IoT物联接入平台叫做中台、音视频处理（如转码/裁剪/鉴黄等）也叫做中台。麻麻蛋。现在是个东西就叫做中台。但是，我们真正要讲到的中台也并不在PaaS这个维度上。
2、我们为什么需要中台
因为这是一个企业信息化的新时代。为什么这样说呢？
过去企业信息化的主流重心是企业内部信息化。但现在以及未来的企业信息化的主流重心是企业外部信息化。
我过去已经说了，中国互联网从1998年算起（新浪搜狐网易都在那一年成立），到现在20年了。20年，其实就两个阶段。按to C的分法就是PC互联网时代、移动互联网时代，按to B的分法营销时代、交易时代。第一个10年（1998-2008），不管你是搞音乐图片视频，还是你搞新闻、爬虫新闻、博客论坛，本质上就一个事：做内容拉消费者流量然后拉企业广告变现。到了第二个10年（2008-2018），给企业倒流量，企业已经不信了，你给我多少点击量没用，我归根到底还是得看我卖出了多少东西。所以中国互联网进入了交易时代。
为啥从2008年之后，中国电子商务公司如雨后春笋爆发，就是因为这个历史大规律背景。从现在开始到未来十年（2018-2028），进入了第三个时代。因为在第二个十年，有了消费者也有了订单了，但是上游生产、采购、研发设计不给力啊。市场机会转瞬即逝，谁快谁就能抓住机会。所以中国上游生产、采购、研发设计必须要变革，来适应下游消费者订单。
这就是中国互联网企业纷纷进入to B市场纷纷进入企业服务领域的根本历史大背景。什么to C流量红利没了成红海了，什么中国人力成本高了需要精细化运营了，这纯粹都是外行瞎逼逼、脑子进水了。
我过去已经说了，中国企业软件，从内部单部门单岗位应用，进化到内部多部门多岗位应用，后来又到整个企业乃至整个企业集团的全部应用。再往大长，就必须要突破企业边界，进化到企业的衣食父母（客户）的信息化，这就是我说的连接客户（消费者），让消费者直接参与到企业IT业务流程处理中。进而再进化到连接企业的上下游，为消费者需求与订单进行通力合作、敏捷互动。最后再进化到连接社会基础设施，如工商税务海关银行、交管车管、国土住建、社保民政、质检安监…。
所以，现在以及未来的企业信息化的主流重心是企业外部信息化：连接消费者、连接产供销研上下游、连接社会基础设施单位。
因为要连接消费者。也就是说，消费者在哪里，我们就要连接哪里。这势必造成了IT应用微型化、场景化、碎片化。尤其现在是移动互联网时代，App技术特性决定了流量是被碎片化的不能聚合的。
另外，中国的消费者变化快（也有人说这是中国消费者不理性不成熟的表现），这也势必造成了IT应用要快速迭代改变。
另外，中国的消费者是巨量的。中国每一个省就相当于欧洲的一个国家的大小、GDP规模、人口数量。
所以，我们必须把我们过去铁板一块的应用拆分拆分。与外部连接相关的的应用场景，一定要做成微型化、场景化、碎片化、微服务Open API技术，这样便于快速连接、快速迭代改变。
3、业务中台
咱们就拿所谓的新零售举例子吧。过去的零售渠道很经典，现在，光互联网零售渠道就有很多，还有线下零售渠道，现在还有大客户零售渠道。过去支付方式也很少，现在线上线下很多支付方式。过去消费者来源很少，现在无界零售，有消费者流量的地方就是消费者来源。
所以，在新零售的IT面前，统一会员、统一营销、统一订单、统一库存、统一支付、统一信用…，这些就成了需求。这就是中台。而这些中台，我们叫做业务中台。
当然，按照这种思维来分析应用功能模块，你肯定会类推出财税中台、人力资源中台、供应链中台、新制造中台….。
中台还有好几种，我接下来一块块说。
4、应用中台
除了刚才上述讲的业务中台，还有一类中台是应用中台。
做商业应用级别的基础设施，就必须拥有应用中台，如企业云盘、音视频会议、企业直播、IM、多触点交互机器人、聚合支付、电子发票、电子合同、电子凭证、银企直联…
他们都带有业务应用特征，不是纯技术。但是他们又不是具体的业务场景应用，不是类似零售、制造、人力、财税、OA、供应链、CRM这样。
所以，我把他们这些都叫做应用组件，他们组成了应用中台。
5、技术中台
还有一类是技术中台，过去我们把他们叫做技术平台。
但是我这里讲的技术平台不是指通用IaaS、通用技术中间件，我讲的还是企业应用的技术平台。
为啥过去叫技术平台，现在就叫技术中台了呢？
因为过去技术平台是恒定的。也就是说，你发布了一个版本，你用一年它也是这个功能能力，你用十年它也是这个功能能力。功能能力是不变的。
但是，有了数据和AI驱动，这个技术平台就不恒定了。它里面的很多功能特性就在天天进化、天天模型、参数在自动调节。所以我们就把技术平台升级到了技术中台的概念层面。
所以我老呼吁，不要把中台部署到企业内部私有环境中，这是错误的方向，这是老旧的技术平台的思维。如果部署在企业内部私有环境中，它就接受不到社会360度海量数据的训练了，它只能接受你这一家企业单点的数据训练了，所以它就成三岁小孩了，智力不增长了。
如果你部署在公有云或者专属云上，就会接受我们日常360度的数据训练，它的智力就会天天进化，随着社会动态变化不断自动调节适应了。
你可以把和外部连接的应用放到公有云上，因为他们是外部连接型的，你把他们放到你的内部私有环境中他们就跑不起来了。
你当然可以把你只内部的应用放到你的内部私有环境中。要把公有外部连接的应用和纯内部使用的应用连接在一起，这就需要到了技术中台。按照这个角度来看，中台也不应该部署在私有环境中啊。它一定要放在混合云环境中，这样才方便公有云应用和私有云应用连接打通。
在技术中台这里，最核心的就是集成中台：
1、集成各类企业内部ERP
2、集成各类公有云SaaS
3、集成各类互联网电子商务Open API
4、对外统一开放API，便于外部生态应用接入与融合
你看，大量都是内外连接能力，需要经常变动、需要内外通畅。
6、数据中台
所谓的数据中台，是带有产业主数据、画像标签、业务模型、业务算法的。
所谓的数据平台，才是那些最基础最通用的什么Hadoop、Spark、Flink、Impala、HBase、Flume、Mahout、ElasticSearch…。
平台化架构由于缺乏对于前端业务一以贯之的端到端的支撑能力，平台与平台之间存在gap。平台化架构按照康威定律，必然是几个平台，几个团队，涉及到巨大的沟通成本而导致协作困难。平台化架构在数据化运营上存在短板，往往需要把多个平台的数据集成到一起并加工分析而产生新的支持到业务的价值。
中台思想的提出
马老师参观一个著名的游戏公司Supercell之后提出了中台思想，简言之就是“小前台、大中台”。 Supercell从表象看有200多名员工，一个游戏通常4-5个人研发，截止到2016年3月，Supercell面向全球市场推出了《部落冲突》、《卡通农场》、《海岛奇兵》和《皇室战争》四款游戏。大致可以分析Supercell采用的策略：
必须容忍很多失败：比如一个新项目在测试之前，团队就要设定一个指标，比如玩家留存、参与度，我们把这个目标告诉全公司的人，游戏进入测试之后，如果达不到指标，它就会被取消。
快速尝试：曾经在两年内，他们只发布了一款游戏《皇室战争》，但期间取消了9个项目，和若干很多优秀的创意原型。
招聘足够优秀的人：采用倒三角的模式组织团队，一个游戏公司等于若干创业小团队，小团队可以决定做什么，但没达成目标就必须中止。这决定了团队的每一个人是足够super的cell。
Supercell由于其游戏业务的特点，或与其它业务的研发模式不同。但有一个共同性思考，就是一个良好的中台首要的支持前台业务的快速创新。几个人干1-2个月，业务可以close，不用心疼。但如果百人月的产品，试错成本太高，时间方向也不满足高速变化的市场需要。
类比美军作战模式，就可进一步感受中台的作用。美军在二战时期，以军为单位作战；越战时变成以营为单位作战；中东战争时期进化为7人或11人的极小班排作战。之所以美军的“小前端”如此灵活，因为有强大的中台能力，给前端军队提供各种资源支持以及中台炮火群支持打击。
From：陈华编著《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》图2-4 战场中的中台阵型
中台思想的解法
我理解，中台不是凭空而来，亦不是平台化架构换个名字。中台化架构是平台化架构的自然演进。一定规模的互联网IT公司都可能有一个叫共享平台或者平台技术这样的部门，就是把业务基础设施和技术基础设施下沉，然后由对应的研发和产品部门去负责。但久而久之，共享平台就成了资源中心，前端业务找你就是要人干活，平台做的也是接客干活。如前文所述，各平台接客模式协同负责度高，周期长。一个商业系统不仅仅是组织几个component，而是需要解决方案。中台提供的能力可以是service、可以是由service组合的组合能力、亦可以是解决方案(solution)的直接输出。
中台是平台的自然演进
前面提个平台化目标是高内聚、低耦合；职责边界清晰；易于集成等。那么中台化架构进一步可总结为：高内聚、低耦合；数据完整性原则；业务可运营原则。当然，从架构方法来讲，宜采用渐进式架构的演进原则。如果一个中台把若干平台聚拢起来，对业务支持的SLA没有变化、也没有在业务运营上有所改变，一定是失败的。
以上图为例，业务在发展过程中，会有若干业务系统。平台化的架构是按项目模式，把公共平台和业务系统的架构师，开发，测试，产品搞在一起协同、排期、研发、上线。中台化架构可以在进一步把平台能力按能力、服务、实体进行管理。把平台划分为系统运行、业务运营2部分。实现80% 甚至更多的业务需求由业务团队自助进入。这反映到前端业务上支持效能提升了，中台的代码基本不用研发，沟通成本也急剧下降。其2，中台的架构师和研发队伍可以把精力放到中台能力提升，从运营视角发掘类似业务全息查询、数据产品这样的创新。
阿里巴巴电商中台的思想
电商中台的负责人玄难提到：我们讲整个淘宝最早是一个系统搞定，后来不行，必须分拆，用分布式架构，后来每个系统又很复杂了。阿里的生态太大了之后，其实每个人进来已经不知道阿里有什么了，所以必须通过中台把我们有什么能力要呈现出来，让业务方根据自己的需要去选择去使用。同时，我们在架构上能让业务方在这些能力上可以自己去定制，组装成自己的业务。当前的问题通过中台的思路去解决，慢慢这个矛盾就会变低，但必然会产生新的矛盾，就需要用新的思想去解决。
同时，电商业务中台，有四件事情肯定要去做：
第一，保证阿里的业务跑得更快，更稳定。比如保障双十一稳定，同时不断提升前台业务的开发效率。
第二，产生创新。有三种形式，一种是我们看到了某个业务模式比较好，我们会把它变成一种基础能力，提供给更多业务方用；第二种是打通业务之间的连接，例如把阿里生态中A业务和B业务连接，提供给客户新的价值；第三种是通过自己的思考形成新的产品能力，就像前面提到的「地动仪」。
第三，根据集团的需要进行新业务孵化。孵化到一定阶段，觉得可以独立发展的，我们分拆出去，就像我们现在重点投入的海外市场。
第四，人才的培养。在中台，我们能看到集团所有的业务，同时也支撑所有的前台业务，相对来说系统性思考，全局性思考会更好一些。所以，我们也会根据需要给前台业务培养和输出人才。
中台不只一种解法
实现中台有不同的方法和实施路径，但可以总结出类似的目标和价值。
赋予业务快速创新和试错能力
打造数字化运营能力
改变组织阵型带来组织效能提升
有人讲，是否是足够庞大的组织才需要中台思想呢？我觉得不尽然。先说庞大的，曾经淘宝使用近百人、几个月的浴血奋战搞了一个统一的CRM平台。但是大部分商家并不买账，最后这个系统下线了。因为淘宝的几百万商家划分不同行业，规模也有很大差异，不可能靠一套系统解决。后面淘宝通过开放生态建设，把消费者服务、商家IT服务、商家运营服务做了分类，依托15万家ISV来搞定几百万家商家不同需求。按我的理解，这就是中台化实践，通过开放赋予不同业务，不同商家业务创新的机会。同时通过一系列运营服务比如数据分析工具促进了商家业务量的变化，是运营赋能业务的体现。
第2个case，来自转瞬之夏《一次交易失败引发的血案和思考》。故事大概是这样的：
任何一个合格的产品负责人，都会具有一个特点，就是喜欢使用、捣腾自己的产品以及同行的产品。就拿今天来说，抱着思考产品特性和探究异常处理逻辑的想法，我故意在收银台签约并支付时，输错3次短信验证码，果不其然，在点击支付时，系统报交易存在风险，交易失败。
一切都和预期一致，于是我想，简单测试完了，估计是触发了风控规则，，找客服帮我解锁吧。但想了想，正好可以验证下这种输错验证码被拦截的常见场景，客服处理起来效率怎么样。
于是我找了在线客服，然后角色扮演一位不小心输错验证码而被锁的可怜顾客，并只提供少量信息。我本以为是很简单就能定位的事，所以也估计客服也能很快就能解决。但实际情况是，客服给了我一个完全错误的解决方案，而且把出现异常的原因认定为我输错了银行预留手机号导致的。
……
作者提出的关注客户，关注客服，关注体验的观点，我很认同。但这个问题具备普遍性，想站在中台的角度多说几句。站在平台化思考问题，对于你的服务对象，可能是割裂的。
平台化的协作可能是这样的，YY一张图：
从上图可以看到，用户可能在做某项业务比如购买的时候到收银台；他没有正确完成签约；触发了风控规则。那么一般而言，如果客服是人肉服务模式的话，通过知识库查询对应问题的答案告知客户，或者找产品，产品找开发，开发找安全团队的开发或产品，进行一系列讨论，最终给出答案。
回顾一下，我前面提出的平台化思路的不足，平台职责明晰，但如果站在用户（商户）服务和支持的视角，就全然不是那么回事了，用户对了解内部职责的划分没有兴趣。他们只想快速，准确的给我解释，告诉我怎么做。
那么，我们把接触客户的部分当作客户服务中台，把共享服务当作共享业务中台，前端Bu业务作为xx业务中台。这些中台之间需要按照服务对象来梳理能力，并互相协同。
如上图所示，业务共享中台和业务中台的业务产品上下线、对客可见的规则变更类需要联动到服务中台的知识库、help页面。而服务中台运营对产品分析，产品改进提出反馈。业务共享中台拥有全部的基础数据和系统链路资产，可以提供用户画像数据、业务全息查询等工具给服务中台。有此可见，多个中台互为消费关系，虽然各中台职责分明，但如何更好的服务业务，服务用户，提升企业运营能力甚至支持产品创新都是最基础的原则。
总结：平台化相比于烟囱型架构基于提升效能，消除重复，职责聚焦的视角而来；而中台化是平台化的自然演进，以进一步通过改变组织阵型提升效能、数据化运营、更好支持业务发展和创新。任何应用架构、组织架构都没有终点，只有“合适”。当非关键冲突变成关键冲突的时候，又是新一代架构要持续升级的时候了！
QA：
Q：银行的组织架构也划分了前台、中台、后台。 前台通常是以客户为中心，和客户直接打交道的岗位；中台一般不直接接触客户，但要负责制定业务策略、风险控制等；后台主要是业务的处理和支持。 前中后台分离后，通过流程银行来支持业务运营，建立呼叫中心、单证中心、集中作业中心等，提高效率降低成本、降低人员要求，让专业的人做专业的事情。 IT架构为适应业务架构，通常也是划分了前台、中台、后台系统。 而基础的技术支撑平台则是共享的，如开发工具、开发框架、运行平台、基础设施（云服务、中间件）、基础组件（认证、安全、通讯、加密、审计等）。 等）。那么这里的中台化是不是就是银行组织结构的中台？
A：
我觉得不尽然。不同平台无论在业务的组织形态还是上下游关系上有”前台”、“中台”、“后台”的分野，但如果是分离提供服务支持业务的模式，那么就没进化到中台模式。中台模式可以构建解决方案能力，快速支持业务，消除平台之间的gap、通过组织变革配套促进创新。传统的前台业务比如to C的客户接触、受理也可以升级中台思维。能不能做全渠道打通？能不能提升用户体验、精准服务用户？等等，跳出柜台受理、网银受理的界限和框框，全渠道全业务，或有更好的用户黏性也未可知。
2017年8月12日，袋鼠云首席架构师正风在“网易博学实践日：大数据与人工智能技术大会”进行《淘宝架构演进背后——零售业务中台架构设计探讨及实践》演讲分享。传统零售行业如何选择应对新经济模式下的IT系统建设？
如今零售行业面临的困局有：信息不对称被打破，消费者主权时代到来。互联网/移动互联网、社交应用的高速发展，万物更易互联；商品、商业行为不对称已经被打破，传统营销已经失效。传统渠道扩展野蛮生长模式已经过去。租金成本、人力成本、制造成本不断上涨，行业集团陷入关店潮。运营效率低，高库存、高缺货。供应链速度慢，运营效率低，库存分布不合理，高缺货与高库存并存。因此，新零售的实质就是零售数据化，尽可能借助互联网、物联网、云计算、人工智能和大数据等技术实现零售的“线上+线下+物流”互联互通。
经营思路要从以产品为中心转变为以用户为中心；不仅在交易时与客户有互动，在交易前和交易后也要与客户有互动；营销渠道从传统媒体扩展为口碑传播；从规模化、标准化生产变为能够满足个性化和定制化需求。
业务中台的核心价值就是能够让任何一条业务线都具备整个公司的核心能力。SIP做的系统都是以一个业务域从头到尾打通为主，而业务中台是水平的，在这个平台上需要建设自己核心的业务中心。业务中台为企业提供快速试错创新，能给企业带来的业务中台建设的方式不是一蹴而就的，它是随着企业本身信息化建设持续进展和业务不断创新最终沉淀下来的。
关于服务沉淀，有两个最核心的要求和两个基本能力。第一个是开放，所有业务中台的信息必须对外开放，能够极大促进企业本身业务能力的发展。第二个是滋养。现在传统企业也需要业务创新，只有新的业务不断出现、不停地试错才能让业务中台做的更好，才能真正沉淀出哪些是企业独有的。第三个是数据，线上线下数据产品的创新和对数据的应用。
服务，能力是以服务的方式对外提供的，所以必须确保服务足够核心。
业务中台的技术要求：
（1）架构方面：去IOE架构；共享服务化；低耦合高内聚、弹性伸缩；支持二次开发；完全分布式。
（2）技术方面：开发体系基于最佳实践；采用先进成熟的技术；具备良好的开放性和可移植性；整体协作，快速迭代。
（3）性能方面：7*24小时不间断稳定运行；系统平均无故障率≥99.9%；支持高开发；响应时间不超过1秒。
（4）安全方面：系统、数据库具备高可用性；具备安全备份策略；数据不丢失；可防止网络攻击和黑客入侵。
架构蓝图最底层是阿里云平台，中间建议采用互联网技术做技术平台服务。基于阿里云平台架构，以共享服务体系为核心建设业务中台体系；基于阿里的中间件技术体系，建设业务中台；通过共享服务打通商品、会员、库存、订单、结算，快速支持上层业务。
一、什么是业务中台
概念来自于阿里，介于前台和后台（此后台指的是云计算、数据库、消息队列、缓存等基础服务）
采用共享式架构设计解决以往烟囱式架构设计的资源浪费、重复造轮、试错成本高的问题
阿里的中台架构：
二、业务中台的好处
传统烟囱式架构的缺点：
项目制下的产物，相似功能重复建设，比如各业务中通用的用户、订单、会员、评价等功能，开发和维护成本高
数据分散，格式不统一，无法进行某个领域的业务建模
团队成员按照项目组织，经常项目做完即走，无法深入了解业务，无法培养领域专家
创新业务试错成本过高，限制企业创新能力
中台架构的优点：
通用的业务能力沉淀，合理使用技术资源；数据集中，建模完整。
团队成员专注某个领域，形成业务专家
厚中台，薄应用的设计，创新业务试错成本低
形象的描述为：
美军二战时以军为作战单位，越战时以营为作战单位，中东战争时以7-11人的小班为作战单位，是当今世界上最灵活的军事组织。
美军之所以敢把小的团队投放前线，得益于中后台强大的导弹指挥系统。
三、业务中台的特点
开放：内部开放，易于接入
服务：提供统一服务，服务能力需要不断提升
滋养：需要不断业务滋养发展，无法一蹴而就，服务不需要“业务稳定”
稳定：利用专注专业的能力带来服务稳定
数据：线上和线下数据结合，充分发挥大数据的威力
四、业务中台建设原则
高内聚、低耦合原则——高内聚是指同一个服务中心内的服务模块应该相关性、依赖性很高，而服务中心之间应该隔离性较大，尽可能追求低耦合。
数据完整性原则——与上一条原则一脉相承，让业务相关的数据统一起来，尽可能让数据模型统一，为以后的大数据建设做好基础。
可运营性原则——这里的可运营性包含2层含义，一是指能快速满足上层业务的需求，同时利用业务不断滋养平台，二是指共享服务中心这个平台的可运营性，数据模型统一之后可以较低成本的引入大数据技术，让数据来源、数据分析、数据业务价值自然行程闭环，所以通过服务中心引入大数据来产生业务价值也是服务中心建设原则之一。
渐进性原则——该原则是从降低风险和实施难度的角度出发，有些人可能会觉得服务中心是基础建设，所以从一开始设计了太多的原则从而导致项目周期延长，数据过于分散也会产生数据库性能以及分布式事务的问题，其实服务化架构就是一种敏捷实践，我们推荐小步快跑而不是推倒重来，通过真实的业务需求锻炼出高价值高可靠的共享服务。
五、业务中台的稳定性
限流和降级
流量调度
业务开关
容量压测及评估规划
全链路压测
业务一致性
六、业务中台与前端应用协作
业务中台对前端核心业务的紧密沟通机制，比如定期参与前端的业务周会
建立分歧升级机制，解决有分歧的情况
岗位轮转推动真正换位思考
业务持续沉淀及共建模式
七、业务中台绩效考核
服务稳定是重中之重
业务创新推动业务发展
服务接入量是衡量服务价值的重要考核
客户满意度促动服务的提升
https://yq.aliyun.com/articles/63156
阿里巴巴多次在关键时刻进行架构升级，然后变成新一轮高速前行的助推器。昨日（12月7日），阿里巴巴集团宣布其组织结构全面升级，建设整合阿里产品技术和数据能力的强大中台，进而形成“大中台，小前台”的组织和业务体制，使前线业务更加灵动、敏捷。同时，更多年轻人将接替重要岗位。
“阿里的业务线太多了，这样的调整从管理的角度来说，是内部业务的融合并进，同心协力。”河豚品牌CEO王鹏辉向《每日经济新闻》记者表示。与此同时，互联网分析师独孤依风也评价称，“阿里此举可提升办事效率，协同效率，做到快速决策，为其国际化市场做铺垫。另外基于大数据技术驱动，为其市场化，用户体验化，做迅速呼应。”
打造“大中台”体系
“这一次的改变可以说是集团发展的必然，中国所有的大公司都会面临一个问题：即企业做大之后，如何还能继续保持高效的创新、快节奏和高效的工作环境。”互联网资深观察家、速途网副总编丁道师在接受《每日经济新闻》记者采访时表示，这几年，不仅是阿里，包括腾讯、联想、百度都在做优化人力资源结构的事。
据悉，阿里此次将设立中台事业群，原中国零售事业群总裁张建锋将担任阿里中台事业群总裁。中台事业群下辖搜索事业部、共享业务平台、数据技术及产品部。中台事业群将是未来阿里集团前端业务灵活发展、快速升级的最强有力保障和支撑，是阿里布局未来发展在组织结构上的重要战略变革。
阿里巴巴集团CEO张勇昨日在员工公开信里中介绍，张建锋将作为阿里集团和蚂蚁金融服务集团统一中台体系的总架构师，全面负责两大集团中台体系的规划和建设。
此外，在“大中台”的支撑下，阿里电商事业群将打破树状结构，转变为一批快速决策、敏捷行动的“业务小前台”，由张勇率领。天猫、淘宝和手机淘宝三大核心业务将实施“班委会”集体负责制度，班委由阿里一批年轻业务骨干担当，其中有7位是“80后”管理者。
“中台战略可以视为阿里巴巴集团正在开启第四方平台战略的一个布局。”丁道师表示，“‘中台战略’作为一个介于‘前台’和‘后台’的战略，并不直接承担义务，因为其不卖产品，也不直接和客户打交道，更多的是统筹第三方平台的机构，其主要通过大数据作为基础来统筹和优化第三方平台。”
首次组建平台治理部
值得注意的是，张勇在员工公开信里还明确，阿里妈妈、阿里云和菜鸟网络三大业务将继续面向市场更为独立地发展，实行总裁负责制。同时，阿里巴巴集团重组阿里巴巴集团商家事业部，提供以大数据为基础的工具和服务赋能商家；首次组建平台治理部，由集团副CFO郑俊芳兼任，负责电商平台的规则、知识产权保护等事宜。
“平台治理部独立出来也是一个看点，内部反腐升级为一个独立的部门，就电商企业而言还是一件很大的事情。”在TMT独立评论人、夸客传媒CEO王如晨看来，过去一年多，阿里在此方面遭遇的质疑太多，并一直延续到最近。
王如晨认为，“面向未来而言，这次（组织架构升级）可以说是化解风险的一个手段，过去一年，阿里其实很紧张，首先，上市后“假货”问题是一大方面；其次，上市后要如何解决增长的问题。”
多年以来，阿里巴巴集团经历了多次组织结构变革。最为人知的即2011年阿里集团将淘宝一拆为三，将淘宝、天猫（当时的淘宝商城）、一淘分拆独立发展。直接促成了天猫和淘宝高速增长。今年“双十一”，天猫创造了单日成交912亿元的业绩。
阿里巴巴集团财报显示，今年三季度，阿里巴巴集团GMV（一定时间内的成交总额）达7130亿元人民币，同比增长28%，约占当季中国社会消费品零售总额的9.6%。截至9月30日，零售平台年度活跃买家达到3.86亿，已经成为世界上最大的电商公司。
http://www.easemob.com/news/3172?utm_source=edm&utm_campaign=170&email=van201314@163.com
二十年前，CRM叫九七。 那时，办业务必须去营业厅。营业员在九七系统里录入用户信息、业务办理信息。然而，随着业务和客户的增多，几个人能开发搞定的九七系统，逐渐膨胀、臃肿。
这时，系统开始分成前端、后端。面向客户的前端叫BS系统，面向网络、运维的后端叫OS系统。 然而，随着时代的变化，系统平台化逐渐成为标配，基础设施、人工智能各种领域不断出现各类平台。同时，平台化对于软件开发人员、企业都产生了很大的影响。 企业平台化源于以用户为中心的产品出现，互联网时代用户是商业战场的中心，为了快速响应用户需求，系统必须走向平台化。通过不断快速响应、探索、挖掘、引领用户的需求，使得企业得以生存和持续发展。
海尔早在十年前开始推进平台化组织的转型，提出了“平台自营体支撑一线自营体”的战略规划和转型目标。构建了“人单合一”、“用户付薪”的创客文化，将平台化提升到了组织的高度。
华为在几年前提出了“大平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火”形象诠释了大平台支撑下小前台的作战策略。
阿里通过多年不懈的努力，在业务的不断催化下，将自己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。
然而，随着互联网进程的推进，新业务模式不断涌现：O2O线上线下协同、全渠道无缝购物体验、异业合作能力支撑。大多数企业的后台开始出现问题，要么前台无法用，要么不好用，或者变更速度跟不上前台节奏。 大部分企业后台系统，创建之初的目标不是服务于前台系统创新，是为了实现企业业务资源的电子化管理，解决企业效率问题。
这类系统有些花大价钱外购，每年支付大量服务费，但版本旧，定制困难；还有些花大价钱自建，漏洞多变更困难。
最终后台问题集中在慢、贵，响应业务慢，改小功能又花费高。 于是，“数字化平台战略”出现，也就是我们常说的“中台”。
初了解“中台”，不清楚与“前台”、“后台”外是什么样的区别。随着参与的企业中台项目顺利步上了正轨，试回再次回顾中台并梳理成文，与大家交流。
首先我们先明确前台、后台的概念：
前台：企业的最终用户使用的产品，是企业与用户的交互的产品。如用户使用的网站，手机App，微信公众号等都是前台。
后台：后台通常管理企业的核心资源，如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这些系统构成企业后台。
而中台，从企业内部来看，本质上是企业组织架构、技术架构的优化，核心思路是“能力共享”，是企业级的各个业务线和各个渠道可以复用的能力。就企业与企业间看，也存在泛复用能力。
如对于电商系统来说，不论是什么类型的电商，其基本模块都应包括：商品、订单、支付等，因此，做为服务器“中台”可以成为行业解决方案。
中台支撑前端需求，并且快速响应。同时，中台的搭建和迭代依赖于前端，包括：
1.中台需求来自前台
这里也能看出中台、平台的区别：平台侧重提供现有能力，而中台要响应前台需求，前台需要什么我就做什么
- 中台的迭代源于新业务、新服务接入
接入前端越多，中台越完善，越丰富和立体，因此中台要积极地引入更丰富的新业务。 中台的核心任务是制定标准、机制，把不确定的业务规则、流程确定下来，减少沟通成本，最大程度地提升协作效率。
因此：
中台的目标：减少沟通成本，提升协作效率。
中台的实现手段：制定标准和规范。
原则：集中管控，分布式执行。
中台类型繁多，常见的有：
业务中台
数据中台
营销中台
技术中台
运维中台
不但如此，听说滴滴还做了ux中台。从理论上来说，前台业务重复部分都可以做成中台。
例如：登陆页面
大部分产品的登陆流程差不多，如果某个企业具有整合开发的能力，可以输出一个技术中台，在新产品做登陆页时，直接复用做个性化开发。
由此，不难发现中台的优势在于：
减少重复
阿里开始做中台是发现淘宝、天猫两个电商系统完全独立，但都有商品、交易、支付、物流和评价等相同的功能。尝试复用的构想下，构建了“共享业务事业部”。之后，融入1688、聚划算、闲鱼等更多独立系统，沉淀形成了统一的用户中心、商品中心、交易中心、评价中心等。
打通多渠道
传统平台通常会拓展多个渠道，如：线上app、小程序、公众号、线下门店，但尤于独立的技术架构，各系统渠道数据独立，无法多渠道共享，影响用户体验。
另外，对于用户数据来说，每个用户在各个渠道产生的行为数据都不同，独立系统下，构建完整用户画像并精准营销基本属于空想。
中台不但可以存储原始数据，也能构建事实数据标签，甚至预测标签，前端数据都可以调用。而且，系统数据表结构需求发生变化，出现新数据需求时中台也可以快速修改。
加快需求上线
中台对前台需求的快速响应，实质是开发思路到运营思路的转变。去除所有系统从0到1的开发套路，而是从运营角度思考，从己有的1中拿出可以共用的部分做模式化优化开发。
https://zhuanlan.zhihu.com/p/41899967
腾讯召开了“腾讯全球数字生态大会”，在会上，多位腾讯高管提到”开放中台能力，拥抱产品互联网“。至此，“中台”2个字开始频繁出现在资讯报道、公众号文章和知乎上。
在2019年5月21日后的2个月内，在百度指数中，与“中台“相关的高频搜索词有：什么是中台系统、中台是什么意思、数据中台、中台系统、系统、互联网中台是什么意思、中台产品经理，业务中台、中台战略、中台概念、数据中泰、什么是中台部门、数据中台是什么意思，等等。从搜索词上可以看出，搜索去向的相关词，大部分还集中在“what”的阶段，即“什么是中台”，“中台是什么意思”，“什么是中台系统“的阶段。
本文，将试着回答”什么是中台系统“（中台的概念很多，本文主要讨论的是“业务中台”）
一、中台概念产生的背景
1.1、阿里的“大中台，小前台”战略
说起中台的背景，最先想到的应该是阿里巴巴提出的“大中台、小前台”战略。阿里CEO张勇在2015年12月7日以公司内部信的方式，正式从公司集团层面提出了”大中台、小前台”的中台战略，该战略的价值为：前台可敏捷快速适应瞬息万变的市场，中台集合集团的技术和数据能力，对前台进行强力支撑。
参考 《企业IT架构转型之道》书中第1章的描述，阿里中台的产生历程，实际上是阿里共享业务事业部演进历程，阿里并非凭空提出来1个“中台战略”，实际上是阿里一直都在对“中台”进行演化推进；演进到了2015年，中台战略不管是组织架构上，还是从技术和业务上，趋已成熟，顺势把“中台概念”归纳总结出来，并作为公司的1个战略。
1.2、阿里共享业务事业部的发展史
根据《企业IT架构转型之道》的描述，阿里共享业务事业部共经历了3个阶段：
第1阶段：淘宝技术团队，作为淘宝网的技术团队，同时支撑淘宝和天猫的业务；
第2阶段：淘宝技术团队改组为共享业务事业部，同时满足淘宝和天猫高压态势的业务支撑，夹缝生存；
第3阶段：因聚划算的出现，集团层面决定三大电商平台（淘宝、天猫、1688）与聚划算对接，必须通过共享业务事业部，从此，共享业务事业部有了1个极强的业务抓手，并使之成为阿里巴巴集团业务的核心业务平台；
阿里巴巴共享业务事业部
共享业务事业部，就是阿里巴巴中台（更确切说，是”业务中台“）的雏形。
1.3、中台解决什么问题
从阿里共享业务事业部的发展史可以看出，共享服务架构解决是企业”烟囱式“系统建设带来的3大弊端：重复功能建设和维护带来的重复投资、打通烟囱式系统间交互的集成和协作成本高昂、不利于业务沉淀和持续发展。共享服务架构的建设，摆脱了”烟囱式“系统建设方式所带来的种种发展桎梏。
二、中台的本质和价值
2.1、中台的本质
中台的本质：共性服务与资源的有效复用，概括为四个字就是：服务复用。
BAT各家定义的”中台“，从本质上，均可概况为服务复用。
在2019年腾讯全球数字生态大会上，CSIG事业群总裁汤道生提到的数据中台和技术中台。其中提到“我们的用户中台，可以为客户提供用户增长、用户沟通、用户数据保护、会员管理等完整工具。以汽车行业为例，利用用户中台，我们为车企打造了智慧车销方案，覆盖售前、售中、售后全周期，提升车企获客、待客、留客的效能”
2019腾讯全球数字生态大会
2.2、中台的价值
中台的价值，即服务复用后的直接结果：“降本增效”。
降本增效，可以从下面几点理解：
共性业务的无需重复投资建设，建设成本和维护成本降低；
可以快速进行服务能力迭代，高效支撑前端业务变化；
三、公司要不要做中台？
从百度指数可以看出，2019年“中台”这个词很热，比较夺人眼球的资讯标题有：公司不做中台，会死吗？笔者的回答是：不会死，而且要做之前，先要判断“要不要做中台”
回顾近期各家对中台的阐述，大家对中台的理解和定义还处在百家争鸣的阶段。笔者认为，要不要做中台，按照顺序，可以问下面2个问题：
在公司内部，有没有共性业务？
这是前提条件，一定要在集团（公司）内部，找到共性业务或需求，最好是有较多的内部共性业务和需求。
在目前的大厂中，共性业务最多的是2家：阿里巴巴和滴滴出行。阿里巴巴有大量的电商系统，比如天猫，淘宝，1688，闲鱼等，电商系统的共性部分包括商品中心、订单中心、用户中心、支付中心、物流中心等；滴滴出行有大量的打车系统，比如快车，出租车，专车，豪华车，代价等，打车系统的共性部分包括：司机端、乘客端、订单中心、计费中心等。
有没有需要快速响应的业务需求？
因为在进行第1步的共性能力抽离过程中，也是需要耗费大量成本的；在考虑需不需要建中台时，需要考虑未来的收益；如果前端的业务经常需要变动，特别地，新的业务类型和之前的业务相似度很大时，就需要考虑通过中台的方式来支撑了。
如果以上2个问题的答案都是肯定的，那么就可以考虑建中台了。
四、结语
中台的概念非常多，最热的三个中台概念是，业务中台、数据中台和技术中台。各个中台概念的解构思路类似，本文从业务中台的产生的背景、中台的价值以及要不要做业务中台这三个方面，给出了笔者的个人思考和理解。
后续，继续推出第2篇“怎么建中台？”以及第3篇“为什么说所有中台都是业务中台”。
http://www.uml.org.cn/zjjs/201911134.asp?artid=22642
一、阿里业务中台架构图
基础设施服务，即IAAS层，提供硬件底层支持。
基础服务层，即PAAS层，包括分布式服务框架、分布式数据库、分布式消息、分布式存储、分布式事务、实时监控服务等等。
互联网业务中台，包括各服务中心的抽象出来的各种业务能力，包括交易中心、支付中心、营销中心、结算中心、用户中心、账户中心等等。也包括非业务类服务，如日志分析中心、配置中心、序列中心、基础中心。
业务应用，经过调取业务中台，组装形成独立业务服务能力的业务应用。
交易来源，就是前台用户使用的各个端，如淘宝App、PC站等。
二、业务中台化-产品形态
阿里的电商生态，就是要根据对商业的理解，把一些基础逻辑梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？领域服务和领域服务之间的流程链接标准是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。
电商业务中台由一系列：业务能力标准、运行机制、业务分析方法论，配置管理和执行系统以及运营服务团队构成的体系，提供各业务方能够快速，低成本创新的能力。
三、业务中台化-全局架构
中台建设需要一个中心化控制单元，就是我们的运营平台。它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。
其中能力地图是一个最基础的设施，要能把电商生态里面的能力都呈现出来，并在过程中不断的优化完善。就象我们现在出行离不开XX地图一样，今后所有的业务方需要做业务规划，业务创新，都可以到这儿来寻找需要的基础能力。
四、业务中台化 - 业务创新和智能化
为了能将业务逻辑本身与实现逻辑分离，可以将业务逻辑下发给不同实现的执行系统，引入竞争，方便业务平台的改造升级，我们要将控制信息从业务平台中抽离到业务中台，以业务身份为主线来进行组织管理和呈现。并以生态角色的视角来重构信息架构。这样的变革对我们原来的系统架构提出了更高的要求。
通过业务中台化，我们把所有业务的数据汇集沉淀。每个业务它是怎么出来的？出来之后做了哪些业务需求、业务活动？每个业务活动的效果是怎么样的？都可以沉淀下来。
五、阿里核心业务架构
通过阿里云平台将技术中台进行部署，对集团内共享业务单元提供支撑，并最终对前台各业务线提供服务化能力输出。
六、阿里数据中台架构
阿里巴巴提出的数据中台模式正是为解决这些问题而生，并通过实践形成了统一全域数据体系，实现了计算存储累计过亿的成本降低、响应业务效率多倍提升、为业务快速创新提供坚实保障。
全域数据采集与引入：以需求为驱动，以数据多样性的全域思想为指导，采集与引入全业务、多终端、多形态的数据。
标准规范数据架构与研发：统一基础层、公共中间层、百花齐放应用层的数据分层架构模式，通过数据指标结构化规范化的方式实现指标口径统一。
连接与深度萃取数据价值：形成以业务核心对象为中心的连接和标签体系，深度萃取数据价值。
统一数据资产管理：构建元数据中心，通过资产分析、应用、优化、运营四方面对看清数据资产、降低数据管理成本、追踪数据价值。
统一主题式服务：通过构建服务元数据中心和数据服务查询引擎，面向业务统一数据出口与数据查询逻辑，屏蔽多数据源与多物理表。
极大的丰富和完善了阿里巴巴大数据中心，OneData、OneID、OneService渐趋成熟并成为上至CEO、下至一线员工共识的方法论体系。
七、阿里技术全栈全景图
阿里技术全栈包含：移动中台、业务中台、数据中台、基本中间件、基础设施、前台业务、后台业务。
移动中台，包括移动网关、开发套件&框架、消息推送、移动IM等等，提供了限流、负载、鉴权、消息推送、开发框架等等，使得移动端应用开发效率更高。
业务中台&数据中台，将业务、数据抽象和沉淀形成服务能力，对前台提供调用。
八、阿里技术平台底座
在阿里集团内部，所有业务中台、前台，共享一个技术平台底座，将阿里多年技术沉淀的价值最大化，提供运行更稳定、架构更灵活的技术支撑。
九、阿里中台组织架构
阿里巴巴集团在近期的组织结构调整中，组成由“小前台，大中台”互为协同的创新管理模式。
原阿里巴巴中国零售事业群总裁张建锋将担负起“中台”的重要工作，负责共享、数据、搜索，以及闲鱼、淘宝头条等创新孵化业务。
十、业务中台建设路径
阿里对业务中台建设路径进行了总结提炼：
1）决心变革
企业内达成战略共识，一把手牵头，做总体规划、分步实施，找准切入点，解决具体业务问题。
2）成功试点
通过分析调研，明确业务目标和范围，完成技术平台引入、中台建设方法论宣导，进行试点，梳理标杆，积累经验。
3）持续融合
总结出适合企业自身的理念和规范，优化组织、提升中台效率。
十一、企业中台战略升级的4个方面
阿里建议企业实施中台战略的4个升级：
1）战略升级
通过中台建设，落地企业数字化战略。
2）组织升级
组织架构需要与中台架构相匹配，根据企业实际情况优化组织效率。
3）流程升级
将企业现有流程进行梳理，优化及固化企业流程，提升企业运作效率。
4）技术升级
通过互联网技术，对企业基础技术设施进行升级，降本增效。
十二、阿里中台的能力开放
阿里基于阿里云、ET大脑、业务&数据双中台，将阿里10多年的技术能力向社会进行开放。
十三、阿里业务中台建设方法论
1）中台建设的基础协议
就是要根据我们对商业的理解，把一些基础协议梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。
2）中台的基础设施：中心化控制单元
就是运营平台，它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。
http://www.uml.org.cn/zjjs/201911134.asp?artid=22642
作者：网易云
链接：https://www.zhihu.com/question/308314004/answer/854690680
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
不同的团队对中台有不同的理解，但中台项目要成功，还是有必要对中台的概念做一个比较准确的定义。网易副总裁、网易杭州研究院执行院长汪源的观点：中台是支持多个前台业务且具备业务属性的共性能力组织。三点含义：中台必须具备业务属性。中台是一种共性能力组织，支持了多个业务。中台支持的是多个前台业务。业界常说的中台，包括业务中台，数据中台、用户中台、搜索中台、推荐中台、技术中台、组织中台等，根据这个定义，容易知道：所有中台都是业务中台，没有别的类型的中台。数据中台、搜索中台、内容中台、零售中台等等，都是特定形式的业务中台，也还是业务中台。技术/算法/移动/研发中台当前基本不存在。
当前最需要建设的中台有两种：狭义的业务中台：一般指在线业务为典型特征的中台。在OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。数据中台：一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。对业务中台来说，比较符合的场景主要有：业务系统研发团队至少大几十人（含外包的），需求多变化快，系统又涉及多个领域（比如做ERP、电商的），业务逻辑比较复杂。这时业务中台可以把系统和业务领域划分清楚，提高研发效率。做相似行业的外包项目为主，业务规模也做的比较大的（一年有两位数的项目）。这时业务中台可以提升软件复用，降低定制化成本，提高研发效率。如果你做外包，每个项目都完全不一样，那中台也救不了你。对数据中台来说，比较符合的场景：数据产品比较多，每天要看数据如果没数据就不知道怎么工作的运营人员比较多的业务。比如电商就是典型。尤其是数据产品和运营人员还在多个团队。用数据的姿势比较复杂，问题比较多，比如经常出现指标不一致、数据出错、想要的数据不知道哪里有等问题。网易杭州研究院建设中台，源自并行支撑多个业务的需求，追求技术体系化，对抗重复建设，建立共享能力团队，提高创新的速度和效率，提高成功率。要建设中台，需要考虑组织、支撑技术、方法论这三个方面，往往还需要咨询服务。支持业务中台的技术体系，包括微服务、DevOps、云原生和分布式事务等，在网易，是网易轻舟微服务平台，提供微服务应用全生命周期的完整支持，包括下一代微服务Service Mesh支持、经典微服务框架NSF、包括CI/CD的DevOps、分布式事务框架GXTS、APM、API网关、GoAPI全自动化测试以及容器应用管理服务等。支持数据中台的技术体系，包括指标管理、数据服务、元数据管理、数仓开发与管理、数据安全管理、数据资产管理、大数据计算引擎、数据集成/同步/交换引擎等，在网易，是以网易猛犸为核心的网易全链路数据中台解决方案。关于中台的全面科普，可以参考汪源的中台系列文章，系统地回答了什么是中台、怎么建中台的问题，并给出了网易杭研的实践案例
https://www.zhihu.com/question/308314004?sort=created
https://bigdata.163yun.com/middlePlatform?channel=M_zhihu_308314004
https://zhuanlan.zhihu.com/p/78441670
中台的概念一热，很多似是而非的东西都在往中台的概念上凑，一下子出现很多中台，如业务中台、数据中台、技术中台、算法中台、移动中台等等。特别是很多原来称作平台的，现在也都摇身一变成了中台，赶时髦。
一个概念太过宽泛是不利的，如果随随便便都是中台，必然导致很多所谓的中台项目失败，导致中台无用论。所以有必要对中台的概念做一个比较准确的定义。
什么是中台？
要定义中台，重要的是要能比较明确的区分中台和平台。中台和平台都是某种共性能力，区分两者的重点一是看是否具备业务属性，二是看是否是一种组织。中台是支持多个前台业务且具备业务属性的共性能力组织，平台是支持多个前台或中台业务且不具备业务属性的共性能力。
为什么要强调中台必须具备业务属性？可以来看一个例子。我们可以分析什么叫数据中台。如果一个企业把所有业务的数据都存储在Oracle里，我们能说这个Oracle数据库是数据中台吗？显然大家都会说不是（否则中台不是几十年的老古董了？）。那么现在很多企业换成了Hadoop，所有业务数据都在一个Hadoop集群里，能说是数据中台吗？显然也不是，这个Hadoop无非跟原来的Oracle一样存了一堆数据而已。有人说这是因为这个Hadoop集群只是一个系统，中台必须是一个组织。那么我们再加上建设和维护这个Hadoop集群的团队，整个加起来就是中台了吗？
仍然不是，因为这个团队是不需要为业务负责的，不具备业务属性。而现在大家比较公认的数据中台，指的是确保OneID、OneData得以实现的组织，使得数据不再是各前端业务独立管理，而是通过统一的团队在数据标识、指标、数据仓库等方面实现了跨业务的整合。之所以这样大家会认为是名符其实的数据中台，是因为指标一定是面向业务的，数据仓库的建设一定也包含了一些业务逻辑。所以那个大大的Hadoop并不是数据中台，而是大数据平台。
我们还可以看到是中台还是平台与所在的业务环境相关。同样的能力对A业务来说可能具备业务属性从而是中台，但对B业务来说没有业务属性从而是平台。比如说IDC建设和运维对AWS来说可谓至关重要的业务中台，而对绝大多数企业来说只能说是平台。PaaS平台对SaaS厂商来说是业务中台，但对绝大多数企业来说也只能说是平台。
所以，不具备业务属性的能力，即便是共性的，即便有一个专职的部门在做，即便对业务非常重要，也不能称之为中台，而还是应该称之为平台。否则就会出现很多与业务八杆子打不着的各种中台，混淆视听。因此，应该说所有中台都是业务中台，没有别的类型的中台。数据中台、搜索中台、内容中台、零售中台等等，都是特定形式的业务中台，也还是业务中台。
中台的定义还要求以下两点：
- 中台是一种共性能力组织，支持了多个业务。
- 中台支持的是多个前台业务。
第一点不用多说，只支持一个业务的能力至少暂时不能称为中台（当然可以有进一步建设为中台的规划或可能性）。之所以强调第二点是因为有太多的公司的业务不是靠前台打下来的，而是靠财务后台做账做出来的。理论上可以有，但我们应该支持这样增强做账能力的中台吗？对于那些专业提供做账服务的公司，还真需要这样的中台，但这时做账就是它的前台业务了。
中台的定义并没有限定中台的建设层次。中台可以在很多个层次上建设，并不是说必须是企业或集团级别的。BU和BG层面建设中台往往更常见，也通常很有意义。即便更小的层面比方几十人的小部门，中台也很有价值。比如一个小团队也可以做电商业务，这时如果有一套好用的电商中台那就帮了大忙了，而事实上业界也有很多公司在提供这样的能力。
典型的中台有哪些？
除了常说的业务中台，我们还经常听到数据中台、用户中台、搜索中台、推荐中台、内容中台、技术中台、算法中台、移动中台、研发中台等等一系列的XX中台的说法，但这些中台未必都是真正的中台。
前面已经说过，广义上讲业务中台包含了所有中台，不同的XX中台都是业务中台的细分方向，反映的是该中台在业务领域或者技术上的某些特征。但大家往往只用业务中台来指称在线业务中台。基于这个假定，当前典型的真正的中台大致只有以下几个：
01（狭义的）业务中台
一般指在线业务为典型特征的中台。在OLDI（Online Data-Intensive）时代，越来越多的企业的核心业务都是在线业务，因此把在线业务中台简称为业务中台。但对那些不是以在线业务为主的企业，它需要的业务中台可能就不是在线业务中台了，而是数据中台或别的什么中台。
02数据中台
一般指以数据采集、数据集成、数据治理，指标体系和数据仓库统一建设等数据管理活动为典型特征的中台。同样，在OLDI时代，数据中台越来越重要。狭义的业务中台也就是在线业务中台负责OLDI中的OL（Online），数据中台负责OLDI中的DI（Data-Intensive）。
03用户中台
用户中台可以认为是一种特殊的数据中台，一般以用户ID统一、全域用户画像建设、全域会员体系建设等为典型特征。用户中台很通用，比更广义的数据中台往往更常见。很多企业没能力建设更全面的数据中台，但建设了会员中心等用户中台。
04内容中台
内容中台往往也可以认为是一种特殊的数据中台，一般以内容的采买、内容爬取、内容的加工处理、内容安全保障等为典型特征。
05搜索推荐中台
这两个中台比较像，因为搜索和推荐的技术比较相似。这两个中台一般是为推荐和搜索系统提供一套相对标准的工作流程，同时支持流程各环节的可定制能力，从而支持多个前端推荐搜索业务的快速开发。
当然还有很多其他根据业务需要建设的中台，比方说对美团/饿了吗来说，本地配送体系可以建设为中台，前提是这个体系不仅用于送餐。在电商行业，往往渠道运营用单独的系统和团队来支持各个BU（一般按品类分），也可以说是中台。
技术/算法/移动/研发中台当前基本不存在
一般来说，没有技术中台，这是因为以技术为典型特征，又具备业务属性的中台太难找了，没有一个很好的案例。可以看看业界所谓的技术中台，包含了从IaaS到中间件等一系列在线业务技术，但能称这些为中台吗？可以把里面每个模块都拿出来分析，保证你找不到一个跟业务相关的字眼。所以这些并不是中台。
其实A公司也只说业务中台和数据中台。其他的中台都是某些咨询公司或不明真相的群众牵强附会造出来的。
并不是说不能有技术中台，而是没必要特别的称作技术中台而非业务中台。对于提供技术服务的企业，它的业务前台就是技术前台，它的业务中台就是技术中台。比方说SaaS厂商的中台往往是个PaaS，这时这个PaaS可以称之为技术中台，但也是这个产商的业务中台。同样的一个PaaS，对于大多数别的企业，就变成只是支撑业务但本身没有业务属性的技术平台了。所以，为了避免混淆，导致把平台说成中台，不如坚持认为不存在技术中台。
同样的道理，移动中台似乎只对做移动应用开发业务（比如说很多外包产商）的企业来说才是中台，但对这些企业来说移动中台也就是它的业务中台，所以也宁可不搞出一个移动中台这样的新名词为好。
那么，什么才是研发中台？H公司有专职的研发部负责支持所有前端业务的研发，让听得见炮火的人指挥战斗，可能是名副其实的研发中台。
总之一句话，当前并没有好的技术 / 算法 / 移动 / 研发中台，那些出来宣传这些中台的要么是自己搞不清中台概念，糊涂，要么就是骗子。不过没有这些中台说明整个行业在这方面的积累还不够，是一种不足，希望过几年有真正的这些中台出来。
这是关于中台系列的第一篇，目的是厘清什么是中台，什么不是中台。下一篇将讨论什么时候要建中台及怎么建设中台，敬请期待。
作者简介
网易副总裁，网易杭州研究院执行院长 汪源
2006年获浙江大学计算机专业博士学位，之后加入网易公司。现作为网易杭州研究院执行院长，全面负责网易集团公共技术支撑工作与云计算、大数据业务，主要包括云计算与服务端架构、前端技术、大数据挖掘分析、信息安全、多媒体、运维、质量保障等方向。
https://zhuanlan.zhihu.com/p/78441670
https://zhuanlan.zhihu.com/p/78444055
https://zhuanlan.zhihu.com/p/78449592
在做淘宝机票、彩票系统的时候，页面端也有很多东西需要复用，最直观的是页头和页脚。一开始我们每个系统里面复制了一份过去，但奇妙的是，那段时间页脚要经常修改，例如把“雅虎中国”改成“中国雅虎”，过一段时间又加了一个“口碑网”，再过一段时间变成了“雅虎口碑”，最后又变成了“中国雅虎”。后来我就把这部分velocity模板单独拿出来了，做成了公用的模块。
类目属性服务化
上面这些都是比较小的复用模块，到2006年我们做了一个商品类目属性的改造，在类目里面引入属性的概念。项目的代号叫做“泰山”。如同它的名字，这是一个举足轻重的项目，这个改变是一个划时代的创新。
在这之前的三年时间内，商品的分类都是按照树状的一级一级的节点来分的，随着商品数量的增长，类目也变得越来越深、越来越复杂，这使得买家找一件商品要逐级类目点开，找商品之前要懂商品的分类。
而淘宝运营部门管理类目的小二也发现一个很严重的问题——例如男装里面有T恤、T恤下面有耐克、耐克有纯棉的，女装里面也有T恤、T恤下面还是有耐克、耐克下面依然有纯棉的，那是先分男女装再分款式再分品牌再分材质，还是先分品牌再分款式再分材质再分男女呢？
这时候，一位大侠——一灯出来了，他说品牌、款式、材质这种东东可以叫做“属性”，属性是类似tag的一个概念，与类目相比更加离散，更加灵活，这样也缩减了类目的深度。这个思想的提出，一举解决了分类的难题！从系统的角度来看，我们建立了“属性”这样一个数据结构，由于除了类目的子节点有属性，父节点也可能有属性，于是类目属性合起来也是一个结构化的数据对象。这个做出来之后我们把它独立出来作为一个服务，叫做catserver（categoryserver）。跟类目属性密切关联的商品搜索功能也独立出来，叫做hesper（金星）。catserver和hesper供淘宝的前后台系统调用。
现在几乎没有什么类目的商品在淘宝上找不到（除了违禁的），但最初类目属性改造完之后，我们很缺属性数据，尤其是数码类的数据最缺。那从哪里弄这些数据呢？我们跟“中关村在线”合作，拿到了很多数据，那个时候，很多商品属性信息的后边都标注着“来自中关村在线”。有了类目属性，给运营的工作带来很大的便利。我们知道淘宝的运营主要就是类目的运营，什么季节推什么商品，都要在类目属性上做调整，让买家更容易找到。例如夏天我要用户在女装一级类目下就标出来材质是不是蕾丝的、是不是纯棉的，而冬天就要把羽绒衣调到女装一级类目下，流行什么就要把什么商品往更高级的类目调整。
这样类目和属性要经常调整，问题就随之而来了——调整到哪个类目，那类商品的卖家就要编辑一次自己的商品，随着商品量的增长，卖家的工作量越来越大，然后我们就发现卖家受不了了。
到了2008年，我们研究了超市前后台商品的分类，发现超市前台商品可以随季节和关联度来调整摆放场景（例如著名的啤酒和尿布的关联），后台仓库要按照自然类目来存储，二者密切关联却又相互分开。然后我们就也把前后台类目分开了，这样卖家发布商品选择的是自然类目和属性，淘宝前台展示的是根据运营需要而摆放的商品的类目和属性。改造后的类目属性服务取名叫做forest（森林，跟类目属性有点神似）。catserver还在，提供卖家授权、品牌服务、关键词等相关的服务。类目属性的服务化，是淘宝在系统服务化方面做的第一个探索。
虽然个别架构师具备了代码洁癖，但淘宝前台系统的业务量和代码量还是爆炸式地增长了起来。业务方总在后面催，开发人员不够了就继续招人，招来的人根本看不懂原来的业务，只好摸索着在“合适的地方”加一些“合适的代码”，看看运行起来像那么回事，就发布上线了。在这样的恶性循环中，系统越来越臃肿，业务的耦合性越来越高，开发的效率越来越低。在这种情况下，系统出错的概率也逐步增长，常常是你改了商品相关的某些代码，发现交易出问题了，甚至你改了论坛上的某些代码，旺旺出问题了。这让开发人员苦不堪言，而业务方还认为这帮人干活越来越慢了。
以稳定为中心
大概是在2007年底的时候，研发部空降了一位从硅谷来的高管——空闻大师。他告诉我们一切要以稳定为中心，所有影响系统稳定的因素都要解决掉。例如每做一个日常修改，都必须整个系统回归测试一遍；多个日常修改如果放在一个版本里面，要是一个功能没有测试通过，整个系统都不能发布。我们把这个叫做“火车模型”，任何一个乘客没有上车，都不许发车。这样做的最直接后果就是火车一直晚点，新功能上线更慢了，我们能明显地感觉到业务方的不满，空闻的压力肯定非常大。当时我都不理解这种一刀切的做法，为了稳定牺牲了发展的速度。
但是到现在回过头来看看，其实我们并没有理解背后的思路。正是在这种要求下，我们不得不开始改变一些东西，例如把回归测试日常化，每天晚上都跑一遍整个系统的回归。还有就是在这种要求下，我们不得不对这个超级复杂的系统做肢解和重构，其中复用性最高的一个模块——用户信息模块开始拆分出来了，我们叫它UIC（userinformationcenter）。在UIC里面，它只处理最基础的用户信息操作，例如getUserById、getUserByName等等。
另外一方面，还有两个新兴的业务，也对系统基础功能的拆分提出了要求。在那个时候，我们做了淘宝旅行（trip.taobao.com）和淘宝彩票（caipiao.taobao.com）两个新业务，这两个新业务在商品的展示和交易的流程上都跟主站的业务不一样，机票是按照航班的信息展示的，彩票是按照双色球、数字和足球的赛程来展示的。但用到的会员的功能和交易的功能是跟主站差不多的，当时做的时候就很纠结，在主站里面做的话，会有一大半跟主站无关的东西，重新做一个的话，会有很多重复建设。
最终我们决定不再给主站添乱了，就另起炉灶做了两个新的业务系统。从查询商品、购买商品到评价反馈、查看订单这一整个流程都重新写了一套出来。现在在“我的淘宝”里面查看交易记录的时候，还能发现“已买到的宝贝”里面把机票和彩票另外列出来了，它们没有加入到普通的订单里面去。在当时如果已经把会员、交易、商品、评价这些模块拆分出来，就不用什么都重做一遍了。
拆分核心模块
到2008年初，整个主站系统（有了机票、彩票系统之后，把原来的系统叫做主站）的容量已经到了瓶颈，商品数在一亿以上，PV在2.5亿以上，会员数超过了五千万。这个时候Oracle的连接池数量都不够用了，数据库的容量到了极限，上层系统再增加机器也无法继续扩容了，我们只有把底层的基础服务继续拆分，从底层开始扩容，上层才能扩展，这才能容纳以后三五年的增长。
于是那一年我们专门启动了一个更大的项目，把交易这个核心业务模块也拆分出来了。原来的淘宝交易除了跟商品管理耦合在一起，也在支付宝和淘宝之间跳来跳去，跟支付宝耦合在一起，系统复杂，用户体验也很不好。我们把交易的底层业务拆出来叫交易中心TC（tradecenter），所谓底层业务是例如创建订单、减库存、修改订单状态等原子型的操作；交易的上层业务叫交易管理TM（trademanager），例如拍下一件普通商品要对订单、库存、物流进行操作，拍下虚拟商品不需要对物流进行操作，这些在TM里面完成。这个项目取了一个很没有创意的名字——“千岛湖”，这帮开发人员取这个名字的目的是想在开发完毕之后，去千岛湖玩一圈，后来他们如愿以偿了。这个时候还有一个项目也在搞，就是淘宝商城，之前拆分出来的那些基础服务，给商城的快速构建提供了良好的基础。
类目属性、用户中心、交易中心，随着这些模块逐步地拆分和服务化改造，我们在系统架构方面也积累了不少的经验。到2008年底干脆做了一个更大的项目，把淘宝所有的业务都模块化，这是继2004年从LAMP架构到Java架构之后的第二次脱胎换骨。这个项目取了一个很霸气的名字，叫“五彩石”（女娲炼石补天用的石头）。这个系统重构的工作非常惊险，有人称之为“给一架高速飞行的飞机换发动机”。
“五彩石”项目发布之后，这帮工程师去三亚玩了几天。他们把淘宝的系统拆分成了如下架构：
其中UIC和forest上文说过，TC、IC、SC分别是交易中心（tradecenter）、商品中心（itemcenter）、店铺中心（shopcenter），这些中心级别的服务只提供原子级的业务逻辑，如根据ID查找商品、创建交易、减少库存等操作。再往上一层是业务系统TM（trademanager交易业务）、IM（itemmanager商品业务）、SM（shopmanager，因为不好听，所以后来改名叫SS，即shopsystem，店铺业务）、Detail（商品详情）。
拆分之后，系统之间的交互关系变得非常复杂，如图2所示。
拆分之后每个系统可以单独部署，业务简单，方便扩容；有大量可重用的模块以便于开发新的业务；能够做到专人专事，让技术人员更加专注于某一个领域。这样要解决的问题也很明显：分拆之后，系统之间还是必须要打交道的，越往底层的系统，调用它的客户方越多，这就要求底层的系统必须具有超大规模的容量和非常高的可用性。
另外，拆分之后的系统如何通讯？这里需要两种中间件系统，一种是实时调用的中间件（淘宝的HSF，高性能服务框架）、一种是异步消息通知的中间件（淘宝的Notify）。另外还有一个需要解决的问题是用户在A系统登录了，到B系统的时候，用户的登录信息怎么保存？这又涉及一个session框架。再者，还有一个软件工程方面的问题：这么多层的一套系统，怎么去测试它？这些问题在后来的发展中都进行了解决
http://www.uml.org.cn/zjjs/201812261.asp
https://www.jianshu.com/p/cd13daeda4f9
