对于SOA和微服务架构的区别，在知乎一个回答里面我已经进行了详细的说明，即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化 ，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。
每个小应用从前端web ui，到控制层，逻辑层，数据库访问，数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适，每个小应用除了完成自身本身的业务功能外，重点就是还需要消费外部其它应用暴露的服务，同时自身也将自身的能力朝外部发布为服务。
如果一句话来谈SOA和微服务的区别，即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时SOA的思想进入到单个业务系统内部实现真正的组件化。对于微服务架构本身强调的两个能力又是首先微服务模块完全独立自治，其次微服务模块间通过轻量 Http API接口进行交互和协同。
对于微服务模块，更多还是应该是包含了前端UI的，即微服务模块本身就是一个完全独立的小系统。如果不考虑多终端支持的话，微服务模块只暴露需要跨模块访问的的API接口服务能力即可。而对于互联网很多应用由于需要多终端支持，可以看到微服务模块本身UI层和服务能力层是彻底解耦开的，对于一个微服务模块的所有服务能力都需要朝外暴露。而要把这些服务都管理起来整个服务治理和管控难度会成倍增加。
即举例来说对于用户管理模块，如果用户新增加只有在该微服务模块完成，那么用户新增加是不需要暴露为独立的API接口服务能力的。因为微服务模块内部可以通过传统的JAVA API接口进行调用。当然你也可以将Java API发布为RPC接口调用以提升性能。即在微服务架构里面，我们需要更多关注跨微服务模块间调用的接口服务，而不是微服务模块内部的横向接口服务能力。
在整个微服务架构中，有可能会出现独立的实现领域服务逻辑的微服务模块，这类微服务模块实现服务组合和编排逻辑。领域服务本身又分为两类， 一类是数据类领域服务，一类是业务规则和逻辑类领域服务，但是这类领域服务的特点就是都需要调用多个底层微服务模块提供的原子服务能力进行组合后才能实现。
对于跨多个微服务模块实现的业务流程，对于传统SOA架构里面可以看到可以在BPM里面来实现，包括流程编排，数据建模和界面设计等，最后再讲完成的UI做为Portal挂接到门户层。在微服务架构里面这类事情仍然可以独立一个微服务模块来做，这个微服务模块就是做流程编排和组合的事情，只是通过代码来实现而已。在这种模模式下可以看到这类微服务模块可能只有服务组装层和UI界面层，而没有实际的对应数据库。
