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

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

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

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

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

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

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

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

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

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