再谈SOA和微服务(4.2)

对于SOA和微服务的区别，在前面很多文章都已经谈到过，当时在回答知乎一个问题的时候总结如下：

如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。

为了进一步说清楚，还是重新来Review下两者的定义：

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

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

即我前面强调的微服务本身是SOA业务系统内化这个概念是没有问题的，传统的单体应用不在存在，而是被打破或拆分为多个微服务，而这些微服务本身也是可以重用和组装，快速构建上层应用，这点和SOA架构思想是一致的，只是微服务更加强调轻量API接口方式。

在原来谈SOA架构风格的时候，我进一步总结了两个方式来说。一个是找到服务，并重用和组装服务。另外一个说法就是业务能力组件化，组件能力服务化。

今天重新回顾SOA的定义， 发现另外一个重点就是强调了纵向的竖井式建设模式变化为了分层构建模式，而分层的构建重点就是下面的组件层，再到服务层，再到上面的应用层。而这本身也是SOA的一个核心思想。 传统的遗留系统首先得形成上层的服务组件并开放服务，以屏蔽下层的复杂性，而上层则必须通过服务的组合和组装来构建应用。这也是在谈SOA的时候讲的平台+应用构建模式，再谈微服务架构的时候讲的中台+前台是一个道理，都在强调分层构建思路。

而整个分层构建模式的里面有服务层，有服务层就一定存在要对接口服务进行统一管理，其中包括了服务接入，注册，安全，日志，流控等基础能力。在传统的SOA接入中还包括了复杂的遗留系统适配，协议转换，数据映射等工作。而在新的微服务架构中往往则强调服务注册接入的轻量化和去中心化。

在传统的SOA架构里面，对于服务的统一接入和管理需要用到ESB服务总线，而在微服务架构中对于服务接入和对外开放则涉及到微服务网关或API网关，因此还是先看下区别：

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

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

从这两点上可以看到微服务网关本身也是一种中心化，总线式的集成方式，这点和ESB是完全相同，因此微服务网关完全可以看做是轻量的ESB总线产品，只是去掉了复杂的协议转换，适配，数据映射，服务组合编排等复杂的事情。

使用 API 网关的最大优点是，它封装了应用程序的内部结构。客户端只需要同网关交互，而不必调用特定的服务。API 网关也有一些不足。它增加了一个我们必须开发、部署和维护的高可用组件。还有一个风险是，API 网关变成了开发瓶颈。

简单来说，在我们期望的去中心化和全分布式架构中，网关又成了一个中心点或瓶颈点，正是由于这个原因我们在网关设计的时候必须考虑即使API Gateway宕机也不要影响到服务的调用和运行。传统架构里面只有ESB服务总线，而在微服务架构里面除了中心化的微服务网关，还有去中心化的服务注册中心，这个本身也是和传统架构的一个重要区别。

即传统单体应用拆分为多个微服务后，微服务间通过API接口交互，这些接口也要通过管理。如果这些接口的使用仅仅局限在微服务域内部，那么完全可以采用注册中心即可，而不需要用网关，如果整个应用域需要对外发布接口服务能力，才需要使用微服务或API网关。即：

对于ESB总线的能力，在新的微服务架构里面可以选择微服务网关和微服务注册中心两种替代方式。