略说中台思想及实现思路

说到中台，大家应该都不陌生，现在到处都在提中台。但是中台是一个很虚的概念，今天我们来聊聊中台思想并且设计实现一个微型的中台，来帮助大家理解。同时也是拓展大家的技术视野。对于整个企业的业务运转来说，我们之前学到的所有技术、架构都是属于具体的务实的战术设计。而到了中台这一层，就开始进入整体的，务虚的战略设计了。重要的是要去理解做什么以及怎么做的问题，而不是怎么实现的问题。但是，这些务实的战术设计是构成战略设计的工具，所以，大家要有一定的技术基础才能去深入了解中台，中台本身是在技术的技术上实现的，而又不太关注技术的细节，即中台和技术架构的关系就像道和术的关系。

一、略说中台

 中台，是国内互联网中，继微服务之后又一个火热的概念。从2015年阿里提出"小前台+大中台"的概念后，中台成了国内微服务实施过程中绕不开的一个目标。但是，虽然中台的实施如火如荼，但是关于中台，依然是雾里看花，一百个人会有一百种理解。关于中台的知识，即使单独拉出一个专题出来，也不一定能说得清楚，所以我们这里点到为止。这一讲关于中台的讲解只是作为一个载
体，来分享一下我在参与了多个中台项目建设后的一些心得与体会。我们会以一个支付风控系统为例来讲解中台的概念。但是，需要理解，其实这种方式是不太合适的。这个风控系统，其业务体量是不足以支撑中台这么大的一个概念的。或许课后你能意识到，这个风控系统就可以是一个中台，但是他是整个中台战略中的一个部分。所以，你需要能够站在更高的角度来看后续的技术内容。这个高度要比程序员高很多，要站在架构师、总经理甚至总裁的角度来理解中台。因为关于企业中台的建设，如果不是一个比业务更高的管理层面来推动，基本上是行不通的。强行建设的中台，必然退化成一个业务的附属品。另外，你也需要有一定的业务想象力，才能理解中台的建设思路，而不是像之前的课程那样，关注于各个技术实现的细节。

二、到底什么是中台

 中台这个概念，最早是由阿里在2015年提出的"小前台，大中台"战略中衍生出来的一个概念，他的灵感来自于一家芬兰的小公司supercell。这是一家号称是全世界最成功的移动游戏公司，说这个公司你可能没什么印象，但是说到他开发出来的游戏，你可能就会有点印象了。supercell可以说是全世界最会赚钱的游戏公司，旗下推出的每一个游戏都非常火爆，包括《部落冲突》《皇室战争》，还有《卡通农场》、《海岛奇兵》、《荒野乱斗》。他有个显著的特点，就是在公司内部，任何人都可以提出自己的游戏点子，然后在公司内组织自己的项目团队，称为cell。每个cell人数不多，一般不会超过7个。每个Cell内自行组织游戏的设计、开发、快速推广。然后以最快的时间推出产品的公测版，看看游戏是否受到用户的欢迎。火爆的游戏就存活下来，反响平平的游戏就快速终止。期间几乎没有管理角色的接入，同时失败后，团队也不会收到惩罚，团队成员总结项目经验后，迅速转入其他Cell。而阿里正是在对supercell进行考察之后，才有了中台这个概念。于2015年正式开始推行中台战略，并指定了为期三年的中台战略考察期，并迅速成为了互联网企业的标
杆。

      所谓中台，就是将各个业务线中可以复用的一些功能抽取出来，剥离个性、提取共性，形成一些可复用的组件。通过这些组件，就可以使日后的系统开发成本降低，质量提高。大体上，中台可以分为三类，业务中台、数据中台和技术中台。

1、 业务中台就是抽象出来，在各个业务线都可以共用的一些业务组件，像用户权限、会员管理、移动支付等等这些公用组件，可以在各个业务线中都使用。

2、数据中台是对整个业务系统的数据进行统一存储、建模与计算，为各个业务系统的数据分析与利用提供支持。

3、技术中台就是要封装各个业务系统所要采用的技术框架，使上层业务开发的门槛降低，提升交付速度。

大家设想一下如果你是公司的架构师，你需要将公司的软件资源进行整合，你会怎么做？是整合数据和整合服务。

 另外对于中台，你需要有一个清醒的认识，虽然这个东西现在很火，互联网开口闭口都离不开中台。但是中台只是一种战略设计思想，他也有他的局限性，并不是适用于所有的软件场景。另外，中台也并不一定就是好的。中台战略涉及到对整个公司的资源进行大刀阔斧的调整，从业界的情况来看，成功的案例固然很多，但是失败的案例也不在少数。网上可以查到很多中台失败的案例，甚至在阿里内部，也不断传出要拆中台，唱衰中台的声音。所以，中台的好和坏，需要每个人自己有自己的评价与思考。

参考文章

三、怎样构建中台

 中台的建设，也不仅仅是技术方面的问题，而是涉及到整个企业内资源调度的综合性问题。很多企业在组件软件开发团队时，都会优先基于业务的横向分割，形成产品、设计、开发、测试、运维这样大的组织结构，称为烟囱式团队。例如阿里早期的团队建设是这样的：

 这种模式没有太多的历史技术和业务的包袱，在业务简单、参与的人比较少的时候，往往可以获得一个比较快的支付速度。但是随着项目的不端推进，业务变得越来越复杂，参与的团队会越来越多，这时候这种烟囱式的团队建设就会体现出很多的弊端。例如最为明显的就是功能重复建设以及维护会带来重复的投资。另外更深层次的问题在于，这种烟囱式的团队，团队之间的沟通和协作会非常困难。即不利于企业的业务经验沉淀，也不利于技术梯队的建设。在企业长期的发展过程中，就会体现出人力资源内耗严重，项目新需求研发越来越慢，交付的产品质量越来越低。
       例如阿里在09年就成立了共享事业部，尝试对于烟囱式团队进行改造。经过多年的摸索，才逐渐将平台化建设的思路给梳理清楚，并形成了中台这样一个具体的体系。 

 
 究其原因，是因为从需求到交付的整个过程中，要经历的部门越来越多，部门之间的沟通成本也越来越大。例如要开发一个完整的需求，需要找各个团队要人，而分配过来的人可能又不懂这一方面的业务，互相沟通就会消耗大量的资源。于是也有企业会按照业务线划分业务部门，甚至有的大型项目，也会以业务为单位，外包给不同的公司，组建跨多个公司的复杂团队。但是随着业务部门的划分，业务之间的沟通又变得更加艰难。在面对复杂业务时，无法及时做出变化，造成团队响应缓慢，跟不上业务变化，从而在互联网的竞争当中错失先机。

         而具体到我们所讨论的代码层面，烟囱式的团队必然造成烟囱式的开发。每个团队都按照自己的技术栈形成自己的代码库。这里面有大量的像JDBC连接池这样的重复的功能。代码量增多了，其中隐含的BUG也会增多。测试团队所要覆盖的用例也随之增多，运维团队需要保证的维护方案也跟着增多。这样，整个团队的工作量一直增加的同时，代码的交付速度与交付质量也就跟着下降了。

          如何打破这个问题呢？阿里的中台战略就提出需要打破部门之间的隔阂，将横向的烟囱式架构竖过来，以业务需求为单位形成一个个快速组合的需求团队。每个团队都直接面对客户。例如电商中，要开发购物车功能，就由产品经理牵头，组建购物车团队，负责整个功能的设计、开发与上线。购物车功能开发完后，团队就解散，去做其他的功能。而当购物车功能需要进行变更时，再重新组建起需求团队，团队成员对整个购物车功能都是相当熟悉的，团队之间的沟通也是非常顺畅的。并且，由于团队人员不断的经历不同的业务线，企业内部的部门信息墙也就自然的被打破了。然后再结合微服务的技术架构，每个团队可以自己维护自己的微服务。开发完成后，也可以自行打包，独立发布，不需要等待其他团队，这样交付速度自然就提升了。

 

 然而，组建这样的团队对成员的要求是非常高的。每个需求团队中都需要有一个或多个组织者，这些组织者必须即懂业务，又懂开发，甚至还要懂测试和运维。所以在阿里内部，诞生出了非常多的业务架构师，这些业务架构师不同于一般的架构师，即能讨论技术架构，又能设计业务框架，无论从哪个方面来说，都是牛人。这种模式虽然好，但是如果每个企业，每个团队都照这个标准来组建，那企业的人力成本就会过高。这样的团队建设是没办法真正落地的。那如何解决这个问题呢？解决问题的关键就在于中台。中台的本质就是提炼各个业务的共同需求，进行业务和系统抽象，进而形成通用可复用的业务模型，打造成组件化产品，形成系统化的能力输出，供各个业务部门使用。简单来说，就是业务需要什么业务，需要什么资源，可以直接找中台，不需要每次去改动自己的底层。例如，如果一个支付企业在电商、零售等行业已经形成了非常丰富的支付业务能力，支持了非常多的支付场景，就可以沉淀形成支付中台。后续如果需要开发团购业务，需求团队就完全不需要自己开发支付方面的功能模块，直接找中台要就行。而在团购业务发展过程当中，有可能出现一些新的业务场景，需求团队可以交由支付中台统一提供支持，这样支付中台又能够进一步扩展
自己支持的支付场景，以后在设计新的业务时，提供更全面的支付场景支持。这样，新业务的设计与开发可以像拼积木一样简单快速，而中台也能在业务实施过程中，不断吸收养分，逐渐壮大起来。整个中台体系在企业内就形成了一个良性循环。在中台建设过程中，数据中台、业务中台和技术中台往往是一个相辅相成的建设过程，针对不同类型的中台也会有不同的建设重点与思路。

四、设计一个可以落地的微中台

       中台战略的形成，往往需要经过三个阶段的转化。第一个阶段是从单体应用到微服务应用的转化：这个阶段跟业务系统转化是相同的。第二个阶段是从微服务应用向平台化的转化：在这个阶段会逐渐将各个业务线的共有能力提炼并沉淀，集中形成一个一个的平台。第三个阶段是从平台化建设向中台战略的转型：经过平台化的建设阶段后，技术中台就基本成型了。在以后的阶段，针对这些技术平台，再逐渐调整公司的整个组织架构以及资源投入，就形成了完整的中台战略。

 

 这个技术中台是更为广义的技术中台。在这个技术中台中需要实现的，是统一各个需求的技术栈以及由此衍生出来的测试、发布、运维等一系列的技术动作。通过这样的技术中台，各个业务团队的技术门槛得到极大的降低，开发的工作量减少了，测试运维的工作也都比较固定了，整个团队的工作模式也就越来越高效，可以将更多的精力集中用来深刻理解业务，并快速响应业务需求的变化。
       而在中台建设过程当中，技术中台往往是最为重要的一环。技术中台团队，往往需要由最精锐的开发人员组成。这样的技术中台需要功能全面、简单易用、部署简单、易于升级等等非常多的特点。下面列出几点我之前参与建设的技术中台的特点，或许能够让你对技术中台有个大致的概念。

1、 技术栈统一：采用SpringCloud技术栈，提供统一的架构支持。同步服务调用、异步消息通信，再到数据存储等功能，提供基于SpringBoot的拔插式支持，各应用只需要按需组合即可。在此基础上，提供统一配置、统一版本管理等集中式的管理方案。

例如框架中各种maven依赖的版本，只提供几个统一的框架版本供业务进行选择。框架版本内的各个组件版本采用集中配置的方式也集中到maven仓库中进行管理。这样，框架版本内部对某些组件版本进行版本微调时，对业务可以做到基本无感知。

或许你听说过在2020年fastjson爆出了一个高危漏洞，在行业内造成了非常大的影响，各个应用都需要尽快升级fastjson版本。而在我们的技术中台架构中，只需要在maven仓库中对fastjson的依赖版本进行统一升级，各个业务应用基本上不需要做改动，只需要随着迭代进行一次常规升级就避免了这个问题。

2、解决方案统一：对微服务调用、MQ异步通知、日志脱敏、传输数据加密、缓存一致性等各种功能在框架中提供统一的解决方案。这些解决方案，大部分是以API的形式提供，业务方只需要进行调用即可。而如果不能形成API接口的，集成到代码静态检查规范当中，在编译发布的阶段给出统一的指导。

3、运维与框架统一：将外部依赖的组件与框架形成统一。例如某业务可能需要用到MQ做异步通信，会由技术中台团队完成MQ的部署，并且将MQ相关的实现以及配置信息一并上传到配置管理中心。业务团队在使用时甚至都不需要知道MQ部署地址，就可以直接拿来用。

4、部署与运维统一：以Jenkins为基础，定制整套完整的部署运维方案。业务团队只需要往Git仓库中提交代码，后续项目打包以及测试环境的部署全部自动完成，不需要人工参与。

5、上线方案统一：对线上环境，机器配置与服务部署都形成统一的标准，业务团队申请线上资源时，只需要申请自己需要什么，而不用管具体的细节。

所以，技术中台并不等同于框架设计，他的落地方案是多种多样的。我们可以说用SpringCloud做微服务是最好的，但是对于中台，很难说某一个公司的落地方案就一定是好的。不要简单的认为跟着互联网大厂学习了一下他们的技术或者架构，我们就做好了中台了。中台没有最好的，只有最适合的。从这个角度来说，我们这个简单的风控中台，对于我们的某个平台来说就可以是最好的中台。

到此、中台思想即实现思路简要分析完了，下篇我们实战实现一个简单的中台案例，敬请期待！