转载

从SOA到微服务架构（2.20）

对于SOA和微服务架构，网上有一篇文章谈到微服务和SOA之间只差了一个ESB，可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。

这句话本身是有问题的，所以有必要再次谈下SOA和微服务架构。

首先要看到SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。因此把两个层面的内容放到一起谈本身就不对。

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

对于服务本身的自治，离散，无状态特征两种架构模式都需要。

SOA强调粗粒度，而微服务架构不会过分强调，由于模块划分细了，本身想粗粒度更加难。

SOA强调可复用，而服务架构不太强调，要考虑到在分层架构模型中UI到服务层也需要全部走服务接口

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

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

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

基于以上思考，从SOA和微服务架构的对比可以理解为：

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

接着我们再来谈下ESB和微服务网关。

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

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

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

基于以上分析，我们可以这样理解ESB和微服务网关

微服务网关 = 传统ESB + 去掉了复杂服务适配和协议转换 +去掉了服务编排 + 提升了限流容错能力

最后谈下微服务架构是否就一定是去中心化的，如果一个微服务架构没有使用微服务网关那它一定是去中心化的，如果使用了微服务网关就需要进行判断。

微服务网关是否只提供了类似Dubbo服务注册和发现能力，实际访问仍然是点对点的服务调用，如果是这种模式也可以理解为整个微服务架构是去中心化的。如果一个微服务网关提供了完全的对被调用系统的安全隔离，包括提供了对每次消息调用的日志追溯能力，那么微服务网关就是一个不可绕过的中心节点，整个微服务架构也不再是去中心化的架构。

原文 http://blog.sina.com.cn/s/blog_493a84550102wq50.html

正文到此结束