聊聊 SOA 和微服务的关系

前言

关于 SOA 和微服务架构，网上有一篇文章谈到微服务和 SOA 之间只差了一个 ESB，可以把微服务当做去除了 ESB 的 SOA。ESB 是 SOA 架构中的服务总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。对于以上观点笔者不是很认同，首先要看到 SOA 和微服务架构是一个层面的东西，而对于 ESB 和微服务网关又是一个层面的东西；一个谈到是架构风格和方法，一个谈的是实现工具或组件。因此把两个层面的内容放到一起谈不太对，下面通过对这两个层面的对比分析来谈一下 SOA 和微服务架构的关系和区别。

SOA 与微服务架构风格对比

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

• 微服务架构定义：微服务是一种架构风格，一个大型复杂软件应用由一个或多个松耦合微服务组成。微服务完全独立自治，可以独立部署，并通过轻量的 HTTP 型 API 进行交互。

从定义上看，对于 SOA 强调了两个重点，一个是找到离散、自治、粗粒度和可重用的服务能力，其次是服务本身可以灵活的组合和编排适应业务变化。而微服务架构更多的是各个微服务模块能够独立自治并在独立的进程中运行，同时微服务之间能够通过轻量的服务接口进行交互和协同。再展开来看如下：

• 对于服务本身的自治、离散、无状态特征两种架构模式都需要。
• SOA 强调粗粒度，而微服务架构不会过分强调，由于模块划分细了，本身想粗粒度更加难。
• SOA 强调可复用，而微服务架构不太强调，要考虑到在分层架构模型中，UI 到服务层也需要全部走服务接口。

对于 SOA 找到服务只是第一步，强调服务复用性和粗粒度的原因也是后续这些服务要用到服务组合和编排里面去，而对于微服务架构没有过分强调这点，服务是否涉及到能够完全灵活编排并不是微服务架构考虑的重点，只要考虑这个问题往往会使这个微服务架构变重。

再回来看，微服务架构强调单体应用要打散为多个独立自治、可以在独立进程中运行和管理的微服务模块，这个内容本身是属于 SOA 思想在系统内的彻底内化以及组件化架构思想的推进，而传统 SOA 更多的关注的是系统间的协同和服务重用 ，因此并没有过分强调这点。

由于在微服务架构中没有了服务组合编排这层的太多考虑，但是本身这个事情是要做的，因此很多是单独定义了上层的业务协同或应用类的微服务模块来完成。即在代码中完成了服务组合的编排的事情，但是仍然可以看到要更好的完成这个工作，在底层微服务模块基础上最好能够有提供领域服务能力的模块来实现服务的组合和组装。正式由于这个原因，个人认为领域服务设计思想在微服务架构中有重要的地位。

基于以上思考，从 SOA 和微服务架构的对比可以理解为：微服务架构 = 80% 的 SOA 服务架构思想 + 100% 的组件化架构思想 + 80% 的领域建模思想

正是由于这个原因，绝对不能简单的将微服务架构理解为简单的做到组件化和数据库拆分，使用了 HTTP RESTful 接口，或者说使用了类似 Spring Cloud 等微服务框架就是微服务架构。

另外，SOA 还有一个核心思想就是强调了纵向的竖井式建设模式变化为了分层构建模式，而分层的构建重点就是下面的组件层，再到服务层，再到上面的应用层。这也是在谈 SOA 的时候讲的平台 + 应用构建模式，和在谈微服务架构的时候讲的中台 + 前台是一个道理，都在强调分层构建思路。

ESB 和微服务网关对比

• ESB 服务总线定义：ESB 总线从 SOA 架构风格发展而来，是传统中间件技术与 XML、Web 服务等技术结合的产物。它是一种总线方式的连接中枢，以管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务级别上动态的互连互通，是一种在松散耦合的服务和应用之间标准的集成方式。

• 微服务网关定义：微服务网关或 API 网关本身是将微服务域中所有微服务需要对外暴露的 API 接口统一起来并对外开放，在外部进行接口访问的时候实现路由转发（服务代理），过滤（日志、安全认证、流控）等核心能力。

ESB 服务总线可以理解为将传统的单点集成转化为总线式集成的核心部件，它是企业内部业务系统间业务协同和数据集成的高速公路，通过将所有的服务注册和接入，来实现对所有服务运行的管理和监控，在这个过程中提供了服务注册、适配器、协议转换、消息格式转换、消息集成、数据映射、简单服务编排、安全认证、日志、流控等多种能力。

而在微服务架构下，仍然需要对微服务架构进行统一管理，只是在微服务架构下都是标准的 Http RESTful 接口和 AMQP 消息接口，对于传统的服务适配和协议转换等功能都没有了，同时对于服务的编排这种重的能力也不再需要。那么更多的将体现在对服务的管理能力上。这种管理能力包括了服务的统一注册与发现、服务安全、服务集群和路由、服务限流、日志等能力上。

在谈微服务架构的核心组件的时候，有文章会把服务注册与发现、微服务网关，限流和容错能力并列，而实际上完全可以将上述能力全部做为微服务网关应该具备的能力。这些能力有些是在引擎层面的，有些是在管控层面的，都必须要具备。

基于以上分析，可以这样理解 ESB 和微服务网关的关系：微服务网关 = 传统 ESB + 去掉了复杂服务适配和协议转换 + 去掉了服务编排 + 提升了限流与容错能力

关于微服务架构是否就一定是去中心化的？一个重要的判断依据就是看是否使用了微服务网关。从微服务网关的定义上可以看到微服务网关本身也是一种中心化，总线式的集成方式，这点和 ESB 是完全相同。

如果微服务间的接口仅仅局限在微服务域内部，那么完全可以只采用注册中心即可，而不需要用到微服务网关，此时可以说这个微服务架构是去中心化的。但是，如果微服务域需要对外提供接口服务能力，此时就可能需要使用到 API 网关，这里又有两种不同的情况：

• (1) 如果微服务网关只提供了类似服务注册与发现能力，实际访问仍然是点对点的服务调用，这种模式下还是可以理解为整个微服务架构是去中心化的。

• (2) 如果微服务网关提供了完全的对被调用系统的安全隔离，包括提供了对每次请求调用的日志追溯能力，那么这个微服务网关就是一个不可绕过的中心节点，此时整个微服务架构也就不再是去中心化的架构了。

可以看到，在传统架构里面只有 ESB 服务总线，而在微服务架构里面除了中心化的微服务网关，还有去中心化的服务注册中心，这个本身也是和传统架构的一个重要区别。即：对于 ESB 总线的能力，在微服务架构里面可以选择微服务网关和微服务注册中心两种替代方式。

最后总结

SOA 和微服务架构的关系：微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，同时 SOA 的思想进入到单个业务系统内部实现真正的组件化。