微服务架构和SOA区别
最准确的说法：微服务是SOA的一种实现
最符合实际的说法：微服务是去ESB的SOA
背后实际上是两种思想的分歧：分布还是集中
当然这里说的不是服务的分布和集中。服务肯定是分布的，这是大前提，是SOA的本质理念之一。分歧在于对服务的治理，是分布还是集中。
开发——在这两种架构中，都可以使用不同的编程语言和工具开发服务，将技术的多样性引入到开发团队，在多个团队中组织开发。但是，在SOA中，每个团队需要了解公共通信机制。通过微服务，服务可以独立于其他服务操作和部署。因此，更容易频繁地部署新版本的微服务，或独立扩展服务。
“边界上下文”——SOA鼓励共享组件，而微服务则试图通过“边界上下文”最小化共享。“边界上下文”指组件和数据作为一个最小依赖项的单个单元的耦合。由于SOA依赖于多个服务来实现业务请求，因此构建在SOA上的系统比微服务慢。
通信——在SOA中，ESB可能成为影响整个系统的单一故障点。由于每个服务都是通过ESB进行通信，如果其中一个慢下来，就可以通过对该服务的请求阻塞ESB。而微服务的容错能力要好得多。例如，如果一个微服务有内存故障，那么只会影响这一个服务，其他微服务将继续定期处理请求。
互操作性——SOA通过其消息传递中间件组件，使用多个异构协议。微服务试图通过减少集成的选择数量来简化体系结构模式。因此，如果希望在异构环境中使用不同的协议集成多个系统，则需要考虑SOA。如果所有服务都可以通过相同的远程协议访问，微服务是更好的选择。
范围——SOA和微服务的主要区别在于大小和范围。微服务的前缀“Micro”指的是内部组件的颗粒度，它比SOA要小得多。微服务中的服务组件通常只有一个目的。而SOA服务包括更多的业务功能，可以视为完整的子系统。
3结论
不能简单地说一个架构比另一个更好，这主要取决于企业构建的应用程序的目的。SOA更适合于需要与其他应用程序集成的更大、更复杂的环境。也就是说，较小的应用程序并不适合SOA，因为它们不需要消息传递中间件组件。另一方面，微服务更适合于较小的、分区良好的基于web的系统。如果正在开发移动或web应用程序，那么微服务将给开发人员更大的控制权。总之，微服务和SOA服务于不同的目的，是完全不同类型的架构。
服务拆分粒度：SOA首先要解决的是异构应用的服务化；微服务强调的是服务拆分尽可能小，最好是独立的原子服务。
服务依赖：传统的SOA服务，由于需要重用已有的资产，存在大量的服务间依赖；微服务的设计理念是服务自治，功能单一独立，避免依赖其他服务产生的耦合，耦合会带来更高的复杂度。
服务规模：传统的SOA服务粒度比较大，多数会采用将多个服务合成打成war包的方案，因此服务实例比较有限；微服务强调尽可能拆分，同时很多服务会独立部署，这将导致服务规模急剧膨胀，对服务治理和运维带来新的挑战。
架构差异：微服务化后，服务数量的激增会引起框架质量性的变化，例如企业集成总线ESB（实总线）逐渐被P2P的虚拟总线替代；为了保证高性能低时延，需要高性能的分布式服务框架保证微服务架构的实例。
服务治理：传统基于SOA Governance的静态治理转型为服务运行态微治理实时生效。
敏捷交付：服务由小团队负责微服务设计 开发 测试 部署线上治理，灰度发布和下线，运维珍哥生命周期支撑，实现真正的DevOps。
总结：量变引起质变，这就是微服务框架和SOA服务化框架的最大差异。
