下载掌阅APP，畅读海量书库
立即打开
IT行业的中台概念是阿里提出的，图2-9所示为阿里IT架构的演进过程。
图2-9
●第一阶段（2003年）：阿里上线了个人与个人（Consumer to Consumer，C2C）淘宝电子商务网站。
●第二阶段（2008年）：阿里从淘宝抽调了开发人员研发上线了企业与个人（Business to Consumer，B2C）的淘宝商城，后改名为天猫。同一批开发人员要完成两套独立架构体系的开发、运维。
●第三阶段（2009年）：将淘宝和天猫两个独立体系的交易、支付、会员等业务的共性逻辑抽取出来共享使用，避免了重复建设，加强了相互协同，减轻了运维压力。这时已经有了中台的思想。
●第四阶段（2010年）：上线团购入口聚划算，天猫和淘宝接入后销售额大增。
●第五阶段（2011年）：各方都希望接入聚划算，聚划算对接压力极大，架构上要求与聚划算业务对接必须通过标准接口完成服务。
●第六阶段（2015年后）：业务应用中淘宝、天猫、聚划算、飞猪、闲鱼等系统的建设都会涉及会员、商品、交易、评价等功能，把这些功能都抽取出来，统一对外提供服务。这样业务应用就不需要开发这些功能了，只关注自己的业务流程设计、页面展示和流量即可。形成的阿里共享服务体系由共享业务事业部负责独立运营，并成为业务中台战略的核心部门。
通过这个演进过程可以看出，每一次的架构演进都是一次中台化的抽象，向下整合、向上共享复用。经过6个阶段后阿里的中台整体IT架构大体如图2-10所示。
图2-10
●阿里云提供所有的硬件、系统软件、网络资源服务，可以理解为资源中台。
●阿里云提供开发平台和软硬件自动化运维能力，可以理解为技术中台。
●共享业务事业部提供全集团在业务开展中公共的、通用的服务能力，而这些能力是全集团的核心业务，可以理解为业务中台。
●淘宝、天猫、飞猪等使用公共的服务能力即可，不需要自己开发，它们只需关注自己的业务。更为重要的是上层业务应用，如淘宝和聚划算之间不用再进行对接了，因为它们的业务能力都是由共享业务事业部提供的，所有的应用只需要使用共享业务事业部的服务即可完成各业务应用的交互。这样就完全不需要传统的ESB去集成。中台架构在共享业务事业部实现了服务复用、数据共享、能力复用、快速创新和试错学习。
以前，一个企业的信息平台一般分为前台和后台。前台是由各类前台系统组成的集合。每个前台系统就是一个用户接触渠道，是企业最终用户直接使用和进行交互的系统，如用户直接使用的PC网站、手机应用、微信公众号、小程序等都属于前台范畴。
后台是由各类后台系统组成的集合。每个后台系统管理企业的一类核心资源，如财务系统、企业资源计划（ERP）系统、客户管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
很多企业的后台系统在立项建设时不是为了服务于前台系统，也不面向最终用户，更多的是为了实现管理手段的电子信息化，提升企业的管理效率。这类系统一部分是当年花大价钱采购的，需要每年支付大量的服务费，版本老旧、变更困难；另一部分是自建的，年久失修，同样变更困难，对业务的响应慢，往往改个小功能还要花一大笔费用，从集团公司最顶层看各成员企业有几百个信息系统。很多系统都是这样，不仅仅是慢和贵，更重要的是被系统供应商给“绑架”了，很多系统代码的产权是谁的都说不清楚，而且几乎看不到哪个系统有扩容规划、灾备演练、降级限流等架构的实际落地和执行。
此时前台和后台就像汽车上两个转速不协调的齿轮，赛车手希望前台的4个轮胎转速越快越好，而发动机作为一台汽车的“心脏”，其“齿轮转速”则不是越快越好，它需要考虑车速、挡位、油耗、温度和安全等综合指标。因此中台要找到一个最合理的平衡点来保证前、后台的协调一致。前台想要快速响应前端用户的大量需求，要求能够快速创新迭代，所以要求转速越快越好；后台由于对应的是相对稳定的后端资源，系统变更困难，越稳定越好，因此希望转速越慢越好。随着企业业务的不断发展，前、后台架构导致的“齿轮不匹配”问题就逐步显现出来。后台变更越来越困难，但还要响应用户持续不断的需求，导致业务逻辑直接在前台实现，致使前台系统不断膨胀和复杂，形成了一个个烟囱式系统，最终业务沉淀不下来、系统交互困难、用户响应能力低下。
中台将前台与后台的“齿轮转速”进行适配，将后台资源集成开放以响应用户的需求，将前台的稳定通用业务能力逐步下沉至中台以提高前台的用户响应能力，又可以将后台需要频繁变化或是需要被前台直接使用的业务能力抽取到中台实现，为前台提供更强大的“炮火”支援。2020年新冠肺炎疫情爆发，全国驰援武汉，我们国家表现出了强大的中台整合能力，一方有难八方支援。政府从各地组织医疗资源和抗疫物资，通过疫情数据和病症情况的实时监控，不停迭代医治方案，很快控制住了疫情的发展，体现了在中台的支持下前台快速的应变能力；一省驰援一市的方案体现了微服务化的分而治之架构；国家将抗疫的经验分享给其他国家、援助医疗物资，体现了中台的共享复用。但我们从数据上了解到还有一些国家对疫情的控制没到位，更能体现出IT中台架构的建设风险比较大。中台架构如图2-11所示。
图2-11
业务中台将后台的资源进行抽象、包装、整合，转化为前台友好的可复用、共享的核心能力，实现了后台业务资源到前台易用能力的转化。
数据中台从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装等过程，构成企业的核心数据能力，为前台基于数据的定制化创新和业务中台基于数据反馈的持续演进提供了强大支撑。
业务中台与数据中台相辅相成，互为支撑地构建起了“火力”强大的“后方炮火群”。
通过分析可以从中发现，中台不是一个具体的应用。在“万物互联”时代，应用都被切分成碎片化的业务场景组合来不断迎合用户快速变化的新需求。而比较稳定和核心的，就是中台了。这也正是这两年中台“火”起来的原因。我认为企业真正的核心竞争力就是中台的服务能力，是需要自己完全掌握的核心能力，而前台和后台完全可以通过外包等方式去实现。
业务中台在前台和后台之间是双向驱动的。它把前、后台通用的能力整合后，对前台应用进行支撑，不对后台系统进行支撑，这个大家都能理解。但前、后台的通用能力是如何整合的呢？从我们的实施经验看，更多的是需要前台应用的不断加入和丰富，来“滋养”中台的“长大成熟”。换个说法就是要有源源不断的业务需求进来，架构师来分析哪些需求适合下沉到中台实现并加以设计。如果把个性化明显的需求也放在中台就缺少了灵活性，其他前台应用又不能共享，只为某一个前台使用，从架构上来说是不应该的，但恰恰我们在中台上线大概一年后真就是这样干的！至于为什么，后面再说。总之，中台架构没有一个标准的设计可照搬使用，成功的案例仅可作为架构设计的参考，需要根据自己企业的实际情况灵活适配和调整。如果企业没有系统架构师，只靠承建商来收集需求进行架构设计，可能结果并不会太理想。一个企业发展了多年，积累了大量的显性和隐性的业务流程、复杂的组织结构和角色分工，承建商很难深入了解业务流程在现场的实际执行情况，他们主要基于原有的中台建设经验在了解企业的业务需求后进行架构设计和实施，等项目上线后可能又会建设其他行业的中台。业务人员只有在真正使用后才能发现系统的问题并提出需求，不过此时的变更非常困难。但项目制的建设就是这样。如果能像我们集团这样，甲方的架构师全程参与中台的设计和建设，并对微服务有深刻的理解和开发经验，而且在集团工作多年，对集团内的IT系统大致清楚，业务知识有一定的储备，对组织内的职责权限也有个大概的认识，基于这些实际情况去设计架构，能够判断出业务中台应该从哪些业务场景作为突破口更能落地，中台系统应怎么样最大化支撑和引领业务的发展，做出来的产品更“接地气”。企业的业务中台一定是逐步完善和长期迭代出来的，而不是一步就设计出来的。
我们在实施中台架构的两年中发现，中台还干了一件很有意义的事。企业在多年的信息系统建设中或多或少会存在一些“僵尸系统”，属于无人管理的状态，运维人员又不敢直接将之删除。中台架构遵循“厚中台、薄应用”的原则，统一了服务并使之通过业务应用层提供。如果某个系统在应用层没有使用任何服务，那它很可能是无效的，也不需要接入业务中台，可以直接被淘汰；已接入的系统通过中台的承上启下提供服务，有归口，由运营团队统一管理生命周期。
上面的案例介绍了企业单个IT系统从无到有、从单一到全面的发展过程，这个过程可以理解为纵向的架构演进，图2-12展示了某集团企业IT架构的横向扩展。
图2-12（a）所示的4个系统分别是由集团下属的4个成员企业独立建设的，集团的汽车运输公司在建设机场大巴系统时，很难主动和地勤公司航班延误服务人员沟通乘坐大巴的旅客的航班延误后的服务。
图2-12
图2-12（b）所示的4个系统在建成使用过程中多多少少会涉及多方交互，例如航班延误后地勤公司需要联系汽车运输公司安排车辆将航班延误旅客运输到酒店休息，此时这2个系统就需要做接口进行点对点对接。这里最大的问题是沟通协调，4个系统在技术层面打通已经比较困难，更为困难的是4个系统对应的是4个不同的实体组织，实现图中的所有线条关系难度极大。
如图2-12（c）所示，通过ESB实现了多个系统的对接，解决了点对点沟通成本大的问题，每个系统只需和ESB对接即可。但我们发现ESB仅仅从技术上弥补了多系统的业务交互的缺陷，每个系统还是在独立建设，最后再考虑ESB集成，这种方式并没有根本上解决跨组织的业务协作问题。从我的经验分析，ESB很难适应需求的多变，而且ESB被当作技术集成工具，并不打算对业务进行整合和逻辑处理。
图2-12（d）中箭头方向发生了变化，业务中台对外提供业务能力的支撑，是面向服务的架构，而不去做多系统的集成打通。各业务系统基于业务中台提供的旅客行程、个人信息、行李、联系方式、用户画像等能力构建自己的业务场景实现，各系统之间是不需要交互的，只需在业务中台获取相应的能力即可。这也就是业务中台最核心的价值。