浅谈一下中台架构

​最近很多人都在谈论“大中台小前台”这种组织模式，我公司也在建设中台，我就在想，中台到底是个什么东西，建设中台到底要怎么搞。

我带着问题读了这本《企业IT转型之道：阿里巴巴中台战略思想与架构实战》，这篇文章算是做个简单的总结与思考。篇幅有限，所以我们只谈理念，不谈具体的技术。

先从“烟囱”系统谈起

在阿里巴巴内部的早期的三大电商平台淘宝、天猫和1688，各自拥有自己的技术支持团队，他们的会员服务、商品信息、订单系统、交易支付、运维监控等，都是各自建设一套。

如果从集团的视角来看这些事业部，会发现他们的这些系统功能都非常相似，但又不能复用。这类系统被称为“烟囱”系统。

这些“烟囱”系统的存在，说明了企业在重复建设和重复维护方面，有较大的浪费。

想要打通这些“烟囱”系统，也是一件成本高昂的事情，跨团队沟通的摩擦成本较高，他们之间的技术实现还不一样，直到SOA架构的出现，才很好地解决了不同的编程语言之间的交互问题。

“烟囱”系统对企业来讲最大的弊端，是不利于业务的沉淀和持续发展。当企业想要再开一条新的产品线时，还要新招一批人从头开始建设，已有的技术能力无法充分复用，趟过的很多坑还要再趟一遍。

这些“烟囱”系统是如何产生的呢？首先，即便是现在的互联网产品，在建设的过程中也是项目制的思维，第一期做这些功能，第二期做那些功能，在资本的诱惑和残酷的竞争面前，每一期计划都排的很满，需要加班才勉强能做到按时发布。在这个过程中，如果另外一个产品线找过来说要复用一些通用能力，已有服务的提供方其实并没有太大的积极性来满足这些要求。另外，即便他们有着不错的做事态度，愿意改造已有功能来满足新业务的需求，但受限于已有服务在设计时往往通用性与前瞻性不足，改造已有功能所需的难度、成本、风险和时间周期，会让双方不约而同地打起退堂鼓。于是，一个新的“烟囱”系统就会再次冉冉升起。

众志成城，从服务重用做起

SOA架构的一个很重要的目标，就是实现可重用的服务，只不过在实际落地的过程中往往更多的是用来打通异构的“烟囱”系统，而这一误用，又反向催生出很多“烟囱”系统。

当企业的领导层充分认识到“烟囱”系统的弊端以后，就会下定决心建中台，当然也是从服务重用开始做起，建立共享服务中心。

上图展示了阿里巴巴集团的共享服务是如何支持前端业务的，以1688（B2B电商平台）、淘宝（C2C电商平台）、聚划算（团购平台）、闲鱼（二手商品交易平台）为例，每个平台都有各自的订单创建流程，各流程所包含的服务数量和流程因为业务场景的不同而有所不同，但不管是哪种模式下的订单创建无一不会牵涉会员信息的验证、商品库存的修改、订单的创建、支付记录的生成，这些相关的服务均是由各自的服务中心提供的，也就意味着不管前端业务形态如何多样，共享服务中心提供的服务都能很好地提供所包含的核心服务，让前端业务的交易信息和数据回流到对应的服务中心。

打造企业的业务服务能力绝不是靠单个SOA项目就能一蹴而就的，而是一个长期、持续的过程，企业应该避免再走入“项目制”实施SOA项目的误区，这样的项目实施完成充其量只是SOA建设的开始，企业需要多一些耐心，在接下来的业务发展过程中逐步打造这些服务，这就要求新的业务必须接入这些已经产生的服务，为这些服务能够变得更加专业和稳定带来急需的需求养分，而不能因为这些“刚出生”的服务功能简单、服务消费体验糟糕、服务不稳定等原因而放弃使用这些服务。

共享服务中心需要业务的不断滋养

一旦实现了共享服务中心，对应的通用能力就能沉淀下来。随着业务的持续发展，上层应用系统会向共享服务中心提出更多需求，从客观上会使共享服务中心的能力越来越强大，能支持的业务场景也越来越丰富。

当然，这个过程也很容易走偏，把共享服务中心建设成一个冗余了各种业务场景的四不像的东西。

业务架构师在这个过程中充当着非常重要的角色，既作为整个服务中心业务发展的领路者，也是保障服务中心核心业务保持业务通用性和公共性的最重要的捍卫者。在服务中心与前端应用进行业务的支持和对接过程中，一定会收到来自前端业务方对服务中心能力增加的需求，如果对这些需求不加任何过滤和判断，都引入到服务中心层面实现的话，势必会损害服务中心业务的通用性，过多的带特定业务属性的需求在服务中心层面实现，导致的结果就可能是随着不断业务的对接，服务中心逐渐丧失了他的业务通用性，最终变得对新的业务需求无法提供服务；同时服务中心的业务逻辑过于复杂，在增加了服务中心运营难度的同时，也为服务的稳定性带来的风险。

共享服务中心赋予业务快速创新和试错能力

说起中台，不得不说supercell这家公司。

在2015年年中，马云带领阿里巴巴集团的高管，拜访了位于芬兰赫尔辛基的移动游戏公司Supercell，这家号称是世界上最成功的移动游戏公司，以《部落战争》《海岛奇兵》《卡通农场》等游戏知名。Supercell是一家典型的以小团队模式进行游戏开发的公司，一般来说两个员工，或者5个员工，最多不超过7个员工组成独立的开发团队，称之为Cell（细胞），这也是公司名字Supercell（超级细胞）的由来。团队自己决定做什么样的产品，然后最快的时间推出产品的公测版，看看游戏是否受用户欢迎。如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，期间几乎没有管理角色的介入。团队研发的产品失败后，不但不会受到惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。

这家游戏公司经过6年的时间将游戏开发过程中公共、通用的游戏开发素材、算法做了很好的沉淀，企业的文化充分鼓励员工进行创新，甚至进行试错，才使得他们在开发的众多游戏中以最快时间找到那些用户真正喜爱的游戏。这种强大的业务试错能力是Supercell相比于其他游戏公司最大的差别，也是最核心的竞争力。其他的游戏公司难道没有想到学习这样的模式吗？答案一定是肯定的。为什么其他游戏公司不具备Supercell这样的能力呢，我觉得很多人忽略了Supercell所构建的中台能力。抛开个人水平高低的影响，Supercell公司在多年的游戏研发中积累了非常科学的研发方法和体系，使得今天公司可以支持几个人的小团队在几周时间就能研发出一款新游戏，并进行公测。

共享服务中心与大数据

对很多人技术从业者来讲，提到大数据的第一反应是什么呢，很可能是hadoop。是不是很low ？

对于很多不算成功的大数据项目，有两个最常见的失败原因。第一，数据分散在各个“烟囱”系统里面，各有各的数据标准，格式也不统一，需要耗费大量的人力物力，才能把数据放到数据仓库中做统一处理，我当年也做过这样的ETL项目。第二，大数据团队的大部分时间精力都耗费在了如何基于hadoop的技术生态来实现业务方的需求，缺少能基于数据进行业务建模的专家。

而共享服务中心则正好可以解决这两个问题。首先，从上面的架构图中可以看出，同一类型的业务数据都统一存储在了对应的业务共享中心，并且格式和标准都是统一的，不需要再ETL了，另外，共享业务中心的业务架构师既懂技术又懂业务，能够更有效地发挥大数据的威力(尽管他不一定懂hadoop)。

中台建设的三个阶段

阶段一，API as Service，属于初级阶段。这个阶段共享服务中心在完成业务抽象的基础上，通过暴露API完成能力的输出。基础中间件的能力也要在这个阶段完成API改造。这里的API不仅限于restful API，还包含消息等一切interface。这个阶段完成后，业务方就可以基于这些基础能力来支持业务系统了。

阶段二，Product as Service，属于中级阶段。随着阶段一的持续进行，API会爆炸式增长，并且还可能存在一些设计不太优雅的API，总之，API会极其庞大且复杂，需要花费较大的精力才能把它们搞明白，业务方接入会存在很大的困难和障碍。阶段二会出现一个共享服务平台，也有可能阶段一就出现了，它的目的是面向业务场景来组装复杂的API，对业务方更友好，降低业务的接入成本。如果一个企业完成了阶段二，就可以基于已有能力在短时间内创建出一个全新的业务应用，大大加快了迭代的速度。

阶段三，Solution as Service，属于高级阶段。随着阶段二的持续进行，企业会在所在行业里逐渐积累很丰富的实战经验和成功案例，此时它就像一个导师，主动地对外输出的是高质量的解决方案。运营可能是这个阶段的主要工作。

中台的绩效考核

在中台之上承载的业务会越来越多，它的稳定性至关重要。中台同时又要支持业务的持续沉淀与创新，又不能过于保守。所以中台是处在服务稳定和业务创新间平衡的一个处境中，正因为这一特殊处境，才有了针对业务中台比较有特点的绩效考核机制。

1. 稳定性是重中之重。阿里巴巴在这部分的考核比重是40%。
2. 业务创新推动业务发展。为了避免一味地求稳而减少业务尝试与创新，针对创新的场景需要留出一定的试错空间。这是一种权衡。此项在阿里巴巴的考核比重是25%。
3. 服务接入数量。中台支持的应用越多，自然体现出的业务价值就越大。考核占比20%。
4. 客户满意度。中台建成后，中台发挥的价值会越来越大，中台的这帮人会越来越嘚瑟，所以留出15%的空间，来考核他们的服务意识。

中台不适合颠覆性创新？

有人说中台不适合颠覆性创新。老实讲，我也不知道这个说法对不对。

不过从架构师的角度来看，中台是一组通用能力，是基于业务场景的高度抽象。如果有些中台无法适应颠覆式创新，我想来想去应该有两个原因，第一，架构师对业务场景抽象的不够或抽象错了，第二，随着技术的不断发展，出现了很多之前从来没有过的新业态，与已有业态有本质的不同，架构师自然无法抽象出他没见过的东西，中台自然就无法支持这种新场景。

本文首发在我的公众号老朱的读书随想，感兴趣的可以关注下。