共享服务中心建设原则 -《企业 IT 架构转型之道 - 阿里巴巴中台战略思想与架构实战》

一、前言



今天重看了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》的第4章-共享服务体系搭建。 书中所描述的共享服务中心，提到的实际上包含两个层次。

• 其一，底层的PaaS能力，它用于解决企业中整体系统群的架构在分布式、可用性、高可用性、实时监控等方面上的需求；

• 其二，通用的业务能力，我的理解实际上就是建设SaaS，目的在于将企业核心能力下沉共享，加速企业创新速度。



这里也想针对第二个：通用的业务能力的建设聊一下对它的一个理解。

二、共享服务中心建设历程



淘宝的共享服务中心最初只有四个：用户中心、商品中心、交易中心、店铺中心；每个中心的选择、定位都能给到我们一些启发。

用户中心：为什么会选择用户中心？主要还是考虑到1）业务复杂程度比商品/交易中心等要低，改造风险相对较低；2）用户相关信息调用最为频繁，服务化后的成本下降等结果检验较为容易（因为不涉及业务逻辑也不掺杂新的业务功能）；

商品中心：淘宝作为平台型电商，商品管理作为淘宝最核心的能力之一，最应该进行下沉共享；

交易中心：交易中心一开始包含购物车、交易流程、订单管理、结算及营销等功能；但后面随着业务的不断发展，库存和营销都分别独立成库存中心与营销中心。这样一个过程反映的是服务中心都是这样动态进化的过程。

店铺中心：店铺本来是承担卖家店铺管理等业务功能，后面随着店铺体系的完善和业务范围的扩展，发展成了淘宝最具活力的第三方店铺装修市场，这个又是一个平台化的最好实践。

从上面，我们可以隐约总结出一些事情出来：

1、这些中心是一个个充满生命力的个体；随着企业业务的发展，某个原有功能模块会壮大并独立成新的服务中心，中心本身又有可能衍生出新的功能；我称之为演进式服务中心；

 

2、企业在做业务中台前，必须得先梳理清楚自己最核心的能力是什么；

 

3、在中台化建设过程中，尽量采用复杂度相对较低、效果较为明显的核心能力进行功能剥离，整合成共享服务中心；

 

4、中心向渠道提供的能力不能拘泥于形式，我的理解是可以以API形式，也可以提供WEB界面形式，当然也可以提供数据能力或者某些通用工具，慢慢的这些中心就可以往平台化方向进化。

 

三、服务中心划分原则

共享服务中心的划分不单单只是考虑技术维度，也需要考虑业务运营维度。别忘了我们做这个事情的初衷是什么？一切一切为的就是以快速响应业务、促进业务创新为目的。我尝试通过我拙劣的语言去描述我所理解的书中所讲的那4个原则。

1、高内聚低耦合原则

这个应该说不单单是服务划分，就连我们平时的系统设计都要遵循的一个基本原则了。在服务中心这个上下文，指的就是说服务间的业务隔离性要比较大的，你做订单的就尽量只放订单类功能（如简单增删查改等），别放用户信息类功能进去；但是某些有一定业务关联度的功能就要具体问题具体分析。举那个具体例子来说吧，笔者所负责的团队中，其中某个团队负责电子商城的建设，为了适应业务的发展，电子商城系统功能从原来的订单、交易、用户等常规功能慢慢扩展到结算、客户权益等，本来一切也相安无事。但是业务的规划也想进一步在客户权益下面下功夫，继续在原有电子商城上做了几个权益相关需求后发现存在很多问题（如资源协同、系统边界等），最后经过评审还是决定把权益体系使用微服务框架进行独立发展。

从整个过程看，或许有人会说为什么一开始不设计一个权益体系或权益中心。但我还是那句话，在这个客户需求瞬时万变的VUCA时代，产品都没法说清楚未来3个月要具体做什么的情况下，我们1）无法衡量是否需要独立建设一个权益体系、2）在现阶段是否存在过渡设计，毕竟我们有ROI的考量啊，如果业务过了两个月后方向调整不就白白浪费了开发资源了吗？但是，那是不是就没什么事情可以提前做的呢？那当然不是。根据过往经验，在工程层面起码我们可以做到以下几点：

1. 针对一期功能需求范围，如果它基本不太需要使用到现有的某些业务数据表的话，且功能范围根据经验评估除了传统的增删查改外还有一些聚合层功能的话，一般会考虑新建一个独立服务（以jar形式）；

2. 否则，在现有业务功能关联度最大的那个微服务上进行开发，但是在包维度上尽量独立，这样在后期如果需要独立发展的话可以快速直接连同工具类一并抽出来变成一个微服务；

3. 在数据库层面，一般优先考虑同一个库使用单独的表支撑新的业务功能；为什么不用单独库或者单独schema？主要考虑到多数据源管理，在工程里面的数据库管理模块就变复杂了，因为不希望因为不确定的业务给数据源管理模块引入不必要的复杂性，特别是涉及到跨库事务，这种就更为复杂。能简单尽量简单，爱恩斯坦不是说过“简单是科学追求的伟大目标”吗？

从上面的例子整个过程看来，大家细品一下，实际上也是一直在遵循的就是“高内聚、低耦合”的基本原则。

• 首先，在初期权益体系功能非常简单的情况下跟商城系统比较紧密，所以是满足高内聚的；但是在代码工程层面，尽量在包维度独立，保证一定的扩展性，所以也是满足高内聚的；

• 接着，随着权益体系功能越来越庞大，显然它不能再继续放在商城主体工程下，但是业务规划也不是特别明确，所以进行功能剥离，变成微服务独立发展，但是数据层还是先保留在商城系统下面；



所以，如果要保证系统架构（服务划分）的先进性，或者说我们怎么做架构守护，保证系统或组织熵增的情况下保证系统不腐化，关键一项就是为系统增添“演进能力”。而“演进能力”要遵循的其中一项基本原则就是“高内聚、低耦合”。

2、渐进性建设原则

这个原则更多是从实施层面出发的。 还是在VUCA时代这个上下文，客户需求和运营需求都是随时变化的。整体的顶层设计肯定是要有的，因为它更多是出于指导性质，在宏观层面划清楚圈圈，这是毋容置疑的。但是在进行具体的服务中心建设的时候，我们更需要具备的是快速调整的策略与能力，因此更多是建议通过小步快跑的方式（特别是对于那些非推倒重来的系统或项目），切忌毕其功于一役。

另外，刚才也说过，系统架构是有生命力的，首先随着业务发展而外源性生长的，同步也因为技术的不断升级而内源性自生长的。 我一直认为，服务化架构就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、工期、性能等各方面进行权衡斟酌，以便得出一个最能符合当时条件的更优解决方案。基于这样的前提，我们的方案肯定是不完美的，我们只能做的是无限靠近完美，潜台词就是每个共享服务中心实际上是需要渐进式建设，就算建设1.0版本后也需要不断迭代优化。（因为人本身就是不完美的，我们所设计的东西肯定也是不完美的，但这个是哲学范畴这里不作讨论，哈哈。）

3、数据完整性原则

这一个基本原则应该是跟上面的第一项原则遥相呼应的，或者可以理解成“高内聚低耦合”在数据模型设计层面的体现。但是这里要强调的是，所谓的数据完整性是广义的。这里可以借用领域建模中的聚合和聚合根解释一下。

什么是聚合？聚合实际上就是一组具有一定关联性的对象的组合，它有具体的聚合根、实体及聚合上下文边界。其中，边界定义了在某个聚合里面应该具备的实体或子实体。

什么是聚合根？在DDD中，聚合根扮演着聚合内部实体与外部其他聚合沟通（跨聚合引用）的一个唯一桥梁。

什么是实体？实体就是每个具体的对象。

从下图看，在整个客户聚合中，客户作为唯一的聚合根（你可以理解成数据库表的一个主键），外部的其他聚合可以通过它访问客户聚合中的所有其他实体（你可以理解成数据库中的不同表，但是具有同一个主键）。整个聚合体现了数据的完整性原则，因为

一、当我要对某个客户的数据进行数据清理的时候，聚合已经告诉我该清理什么客户数据；

二、当我要对某个客户进行画像分析的时候，具体的模型已经呼之欲出了；

数据的完整性意味着使用统一的数据模型，只有这样，我们才能使用统一的数据模型和对应的算法对所产生的整体数据进行相应的统计分析，这样才能最高效的得出对应的结果及为了后期的针对性运营策略提供较为有价值的参考。

4、业务可运营性原则

这里我的理解是，如果我们在建设共享服务中心的时候也应该把业务运营考虑进去，即带有一定的业务逻辑。因为只有这样的服务中心，业务才能在使用这个服务中心的过程中1）不断的沉淀业务数据、2）在使用过程中因为不同的业务需求而自然而然的孕育出创新想法，就好像书中提到的在商品中心的使用中因为海量的商品SKU、SPU而催生出商品巡检技术出来。从这里可以看出来，只有有用户使用，中心才能不断进化不断演进，同时又因新的运营困难催生新的技术或业务，这是一个正向循环。

我们在共享服务的建设过程中也应该最大程度的遵循这样的原则，因为常用的钥匙总是亮的。