阿里巴巴中台战略

2015年阿里巴巴集团启动了中台战略，目标是要构建符合互联网大数据时代的，具有创新性、灵活性的“大中台、小前台”的机制，即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场，而中台将集合整个集团的运营数据能力，产品技术能力，对各前台业务形成强有力的支撑。

那阿里集团为什么要建立一个“大中台、小前台”的架构呢？我们从阿里共享业务事业部的发展史说起。起初，阿里只有一个淘宝事业部，后来成立了天猫事业部，此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系，两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因，阿里集团又成立了共享业务事业部，其成员主要来自之前的淘宝技术团队，同时将两套电商业务做了梳理和沉淀，将两个平台中公共的、通用的业务功能沉淀到共享事业部，避免重复建设和维护。后来上线的聚划算、1688、菜鸟物流等业务，均是基于这个“大中台，小前台”思路建设的。如下图所示：

前文说到的烟囱式的系统架构，相信IT行业的朋友们都有过亲身经历。我们来总结一下这个模式的弊端主要有哪些：

1.重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力，财力，更重要的是时间！在目前高速发展的互联网市场大环境下，商机是稍纵即逝的。

2.打通烟囱式系统间交互的集成和协作成本高昂。各大企业不得不借助ESB产品，构建企业服务总线，打通各系统间的交互问题。当然，我们并非是要完全否定ESB系统，它的确是能在某种程度上实现系统间的互联互通，但这种“中心化”的服务架构缺点也有不少。“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中心点，而这个中心点的能力是很难进行扩展的；也许有人会说我可以通过增加中心服务总线实例的节点数量，以达到线性的扩展平台能力。但这种做法其实过于理想化了，我来举个例子，说明一下这种模式的“雪崩”隐患。假设企业的服务总线集群数量是10台，每个负载量是80%。当访问峰值来临时，有可能因为某一个应用的不规范调用或者某个服务提供者出现了异常，导致了其中1台“罢工”。此时，服务路由压力就落在了剩下9台上，每台的平均负载量就变成了88%（个别服务器会更高），出现问题的概率就增加了。此时假设又有一台不堪重负也“罢工”了，就会出现后面的8台服务器在访问峰值时会瞬间被访问洪流冲垮，这就是“雪崩效应”。（想起了原先公司经常出现的大面积死机白屏…）

3.不利于业务沉淀和持续发展。很多企业经常上演这样的一幕：一个系统上线运行5、6年后，原先的系统升级改造已经不能满足当下的业务发展诉求，需要整体升级，而这样的升级往往意味着对原有系统推到重建，之前多年的业务服务能力没有多少被沉淀下来，造成巨大的资产流失。

那“大中台，小前台”的共享服务体系到底有什么优点呢？说到这，我先来给大家举个例子吧。

大家都知道特种部队在现代战争中是个狠角色，特种部队强大的战斗力绝不仅仅是因为他们当中每个人都身体健壮、思维敏捷、百发百中，而是因为他们拥有一群强大的后盾来支持他们。特种部队虽然人数不多，但可以调动鹰眼、武装直升机、无人机、轰炸机、火箭、×××、甚至是航空母舰。这就是为什么他们十几人可以打败对方几百人上千人的原因。还有个简单例子，一架飞机在天上飞行，通常机舱内只有1-2名飞行员，当飞机出现故障时，仅靠飞行员自己是无法快速、准确的定位问题、解决问题的。而地面指挥中心是有非常多的专家工程师，他们可以快速的帮助飞行员定位问题，并提出解决问题的方法。上述两个例子就是“大中台，小前台”的典型应用，其中的“大中台”就是把所有与势能相关的公线资源全部收纳，组成一个“火力中枢”。

我总结共享服务平台体系的优点主要有如下几点：

1、服务可重用。通过松耦合的服务带来业务的复用，不必为不同的前端业务开发各自对应的相同或者类似的服务。例如淘宝和天猫不必各自开都开发一个评价服务。

2、服务被滋养。作者在书中提出了一个观点：服务最不需要“稳定”。一个服务如果一味追求不变，那就是固步自封，就会逼着其他系统去建同样的“轮子”。服务需要被滋养，不停的滋养，只有滋养才能最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产，而服务所需的滋养正是来自新的业务不断的接入。

3、服务助创新。大家都知道创新不是一件容易的事情，因为有些本质上的创新按照传统的开发模式是需要从分析、设计、开发，每一个环节都从0开始的，这样一来就会导致投入成本大，开发周期长，可能等你开发完了，商机已经被别人抢占了，公司领导可能考虑到上述因素就把你这个想法PASS掉了。而共享服务平台中的诸多服务是经过清晰的沉淀，可以通过重新编排、组合，快速的响应市场，达成创新，武侠小说里不常说天下武功，唯快不破嘛。

4、服务敢试错。说到试错，其实试错和创新有着千丝万缕的关系，有时甚至可以划等号，部分试错是会变成创新的。共享服务平台由于具备快速编排、组合服务的能力，可以以较小的成本投入来构建出一个新的前端业务，即使失败了，公司损失也很小。这在传统模式构建的系统中是几乎不可能达成的。

5、服务造BD。如今BIG DATE（大数据）成为近年来互联网和IT行业最为炙手可热的名词，很多企业甚至将互联网转型的期望完全寄托到大数据上，企业纷纷上马大数据项目。但多数项目在落地实施时却很难，主要有两个问题：一是数据分布广、数据模型和标准不统一。需要进行数据层的打通、权限的控制、格式的转换、以及数据的清洗和转换等一系列复杂的工作；二是缺少“数据科学家”。也就是说人件，项目只有强大的软件和硬件支持是远远不够的。更重要的是要有能基于对业务的理解提出对大数据平台需求的专家。此类专家需要懂数据采集、懂数学算法、懂分析、懂预测、懂市场应用…这样的专家对任何企业来说都是难寻的，就算你的公司财大气粗，可以把某某公司的专家挖过来，但他来到另外一个行业，另外一个公司，遇见另外一个全新的系统，由于对你公司的业务和技术熟悉程度较低，还是很难短时间带来效益。而共享服务体系能很好的帮助企业培育出懂业务的专家，这些人员在自身拥有不错的技术功底的前提下，加上对业务熟悉度的不断提升，使之才有希望成为能发挥大数据平台价值的“数据科学专家”。

结合当前我部门主营的客服系统，我觉得我们完全是可以借鉴这种中台战略思想来规划和建设我们的新一代系统的。

首先把当前系统中各个业务的前端应用与后端服务解耦。将各个功能中的服务能力进行梳理、并沉淀。例如我们从外呼业务中梳理出工单管理和问卷管理的能力；从知识库中梳理出知识搜索的能力；从85电商平台中梳理出商品销售和库存管理的能力等等。

然后将重复、类似的服务进行整合，同时在单个服务的完善和增强的过程中注意服务的通用性，避免其他相似“双胞胎”服务的出现。

最后说一点，由于服务能力的集中管控，很大程度会促进我们一体化运维的能力，但在“大中台、小前台”的模式下，每一个服务都负责对N多个前端业务应用提供支持，这就要求运维在信息安全、备份、监控等方面要有更强的能力。