架构设计内容分享(一百五十三)：从SOA架构思想到中台和微服务，基础概念澄清

本文链接：https://blog.csdn.net/qq_45038038/article/details/135739537

本文对SOA、中台和微服务等基础概念进行统一说明。先介绍SOA架构思想及与ESB总线的关系，指出ESB是实现SOA的关键平台。接着阐述中台思想核心是支撑业务和整合复用资源，微服务是单体大拆小。还说明中台是SOA思想与微服务的融合，以及业务中台、数据中台等的区别。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

从传统架构ESB到中台架构里面的API网关

业务中台，数据中台，技术中台

业务中台是不是就是原来的业务逻辑层？

今天这篇文章作为对SOA，中台和微服务等大量基础概念的一次统一说明。我始终认为，当你在学习一个新的知识和技术点的时候，一定不要马上陷入细节，而是需要用你自己最容易理解的方式形成对该事物的核心概念模型理解。

包括我们现在说的很多的中台和微服务。如果你原来就接触过SOA，接触过组件化开发思想，那么你理解这两个概念相当就很清楚。类似的还有数据中台，你如果原来接触过BI系统，大数据平台，那么你理解数据中台就更加容易，你只需要去比较差异即可。

因此这篇文章我准备从SOA架构思想入手，逐步讲解下对中台，微服务等关键概念的理解。

SOA架构思想

我们可以来看下SOA本身的定义，即：

SOA是一种架构方法，将传统的单片式应用打破，分解为离散的、自治的业务服务，利用标准提升他们的互操作性，从而可以更好地共享、重用和组装，快速构建复合的应用从而满足业务需求的变化。

在面对企业遗留IT系统架构的时候，SOA本身实际也是做两个重要的事情，其一是找到各个遗留系统共性的可复用的业务能力；其次就是在构建上层业务流程的时候通过服务组装和编排来完成。这个思想和中台思想完全一致。

我们来举个例子详细说明SOA架构思想：

我们以注册一家新公司来举例，可以看到如果我们要注册一家新的公司，我们需要和银行，政府部门中的工商，税务，质量监督等多个业务部门到交道，最终完成新公司注册的完整过程。

其一：找到可复用服务

而对于各个业务部门就是我们说的业务组件，我们首先就是要看业务组件本身对外提供了什么标准的服务能力出来，即先把各个组件可共享，能够复用的能力识别出来。这些业务组件本身提供很多业务服务能力，在这里我们只列举一些和公司注册相关的能力，如下：

其二：组合和编排服务完成业务

在进行一个新企业的注册流程中，涉及到核名，办理验资报告，领取组织机构代码证等诸多的业务活动，这些业务活动都需要和上面说的业务部门（业务组件）打交道才能够完成。

而要完成整个业务流程，就是将上面业务部门暴露的服务能力基于业务活动的流转进行组装起来，这样就完成了一个完整的业务，如下：

可以看到完成整个企业注册业务流程，本身就是底层的接口服务能力的组合和组装。

如果注册流程中增加了一个验证企业信用要求，那么我们也很容易在原来的业务流程中增加一个活动节点，该活动节点调用银行的信用验证服务能力接口即可。即通过接口服务的灵活组合，组装，能够很容易的响应业务流程的变化。

SOA和ESB总线的关系

简单来说，SOA是一种架构思想，这种架构思想核心是找到服务，组装编排服务。对于找到的服务我们希望统一进行管理，那么ESB就是实现服务管理和治理的一个技术平台。

也就是ESB企业服务总线是实现SOA架构思想的一个关键平台。

如上图，找到和管理服务你可以借助ESB服务总线能力来完成，而组装和编排服务你可以借助BPM管理软件来完成。而ESB+BPM也是我们常说的实现SOA架构思想的关键平台。

没有使用ESB能否叫实现SOA架构？

当然可以，只是遗留系统暴露的接口服务没有进行统一的管控和治理，也就是说对于接口服务的治理水平会比较弱，但是只要你暴露的接口服务是粗粒度和可复用的。同样可以共享给上层业务系统或应用使用。正如没有使用BPM，同样也可以实践SOA编排思想，只是你需要通过自己写代码去编排服务，而不是通过BPM软件去可视化编排服务。

反之同样的道理，不用简单理解使用了ESB就是SOA架构。

比如你使用了ESB，接入了一堆没有经过标准化，不符合粗粒度特点的接口，这些接口本身混乱也没有任何服务价值。上层新业务开发也不能使用这些接口服务，那么这个时候你的ESB就仅仅是一个接口平台，也没有实现任何的SOA架构思想。

类似的道理还有我们做微服务也一样，不要简单的认为使用了SpringCloud框架就是微服务了，必须要考虑微服务类似轻量交互，松耦合等关键思想是否实现。

ESB总线需要同时考虑解决集成和解耦两类问题

由于当前ESB总线产品很多是由原有的EAI和消息中间件产品发展而来，因此更多的强调的是服务或消息集成，而弱化了SOA更加重要的一个能力即服务共享。

而实际上SOA需要解决服务+集成两方面的问题。

集成：解决的是业务和流程上的协同问题，服务不一定就能复用
复用：解决的是底层共有组件模块提取后能力开放问题，重点是可复用

从上面图可以看到，对于横向交互协同的接口，更多的是解决跨系统的集成问题，而对于系统中纵向使用的共享能力接口，在共享能力平台化后，则接口服务可重用，更多的解决就是服务层面的问题。

举例来说，一个采购系统导采购订单给ERP系统，这个接口往往并不能复用，但是解决了跨系统集成问题；另外对于MDM主数据提供的供应商查询接口服务，这个接口服务本身就是数据能力平台化后提供出的共享数据服务能力，这个服务可以被外围的SCM，ERP，CMS多个业务系统使用，既解决了系统间集成，更重要的解决了服务重用问题。

你也可以理解，对于服务重用问题的解决，更多都是伴随着共性能力下沉产生的。然而当前大部分企业将SOA简单