2.1 回归SOA的本质——服务重用
首先，我个人是SOA的坚定拥护者，SOA是目前业界被验证的真正赋予企业业务快速响应和创新的科学架构，包括如今比较火的微服务概念在我看来也只是SOA方法经过演变后的另一种呈现方式而已。
正如上一章描述的，当SOA在企业客户中落地时，几乎无一例外的是通过搭建企业的ESB（企业服务总线），使各个系统以服务封装或服务调用的方式实现了不同系统间的业务交互。总体来说，我们发现在过去10年，企业实施的SOA项目，本质上仅仅是采用服务的形态，以技术的视角选择了一个科学的架构实现了系统的互联，这只是利用了企业服务总线构建了一个企业内部的服务路由枢纽和渠道，受到项目制建设模式的影响，对于企业中业务服务的持续发展和沉淀没有任何帮助，根本没有真正发挥出SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。这本身就是一种本末倒置，SOA理念的提出原本是真正为企业的IT系统建设指出了一条光明大道，真正体现SOA核心价值的正是这些服务，只有这些服务在业务发展的过程中得到持续的演进、功能逐步完善和增强，最终变为企业在该领域最为专业的IT资产时，才能真正达到SOA中所描述的业务的快速响应，更好地支持业务创新。而这些观念其实在SOA项目的初期都是被企业客户欣然接受的，但一旦进入到项目实施层面，SOA的项目就沦为了实现多个系统间的集成。
今天的阿里巴巴已经将集团20多个核心业务中公共的、通用的业务以服务的方式沉淀到了共享业务事业部，共享业务事业部在中台战略中扮演着至关重要的作用，整个集团的核心业务能力均建立在这样一套共享服务体系之上，使得我们在今天的业务支持中，真正发挥出了SOA架构的核心价值——服务重用。
图2-1展示了共享服务是如何支持前端业务的（并不准确表达各业务的交易流程），以1688（B2B电商平台）、淘宝（C2C电商平台）、聚划算（团购平台）、闲鱼（二手商品交易平台）为例，每个平台都有各自的订单创建流程，各流程所包含的服务数量和流程因为业务场景的不同而有所不同，但不管是哪种模式下的订单创建无一不会牵涉会员信息的验证、商品库存的修改、订单的创建、支付记录的生成，如图2-1示意，这些相关的服务均是由各自的服务中心提供的，也就意味着不管前端业务形态如何多样，共享服务中心提供的服务都能很好地提供所包含的核心服务，让前端业务的交易信息和数据回流到对应的服务中心。
设想一下，如果企业的业务架构也是基于共享服务体系构建的，相关业务领域的业务功能和数据模型原生就在业务层汇聚到了一起，此时回顾“烟囱式”系统建设具有的三大弊端，我们会发现，基于共享服务中心建设的IT架构能最大程度地避免第一个弊端“重复功能建设和维护带来的成本浪费”。
反观企业需要通过ESB组件打通不同系统间的交互，实则是因为相关业务领域的业务和数据被以“烟囱式”方式建设的系统分割到了不同的系统中。以之前所举的零售行业案例最为典型，比如在企业内部的SAP系统中存在生产库存信息，在天猫旗舰店上也有天猫电商渠道的库存信息；在企业自建的电商平台上，库存信息同样存在。当业务发展需要对企业的整体（线上线下）库存进行统一管控，更好地优化库存，减少因不合理库存带来的物流和资金积压时，则不可避免的就需要打通以上几个系统，而这也正是大多数集成需求产生的主要原因。
图2-1 共享服务支持前端业务的示意图
基于共享服务体系建设的服务中心，原生就将相关业务领域的业务功能和数据做了很好的统一，你会发现前端构建的业务实际上也就没有实现系统业务互通的诉求，比如淘宝和1688之间、1688与闲鱼之间均不会产生前端业务交互的需求。今天阿里巴巴整个集团有超过2000多个应用，因为各个应用在核心业务层已经通过共享服务体系实现了统一和畅通，所以今天阿里巴巴集团内部没有类似ESB的组件。也就是说，对于“烟囱式”系统建设模式带来的第二个弊端，需要打通不同系统间实现业务交互带来的集成和协作成本可以最大程度避免了。
