本文将阐述SOA、微服务的基本概念，探讨它们之间的区别以及各自适用的场景。
对于it从业者来说，你可能很清楚SOA和微服务。毕竟，现在每个人都在谈论微服务和敏捷应用。
乍一看，这两种架构设计非常相似。比如，它们都不同于传统的单应用的架构，它们的服务都是职责单一、可伸缩、且具有敏捷性。但是，细致来看，这两者之间有着重大的差异。
什么是SOA（service-oriented architecture）
SOA（Service-oriented architecture)是一种企业级的软件设计方法，它可以利用现有的可复用的应用组件或者服务。它的每个服务执行特定的业务功能，由依赖的数据、程序集合而成，比如：检查客户的信用、登录网站或者处理抵押贷款的应用。
服务的接口采用松耦合设计，这样使用方在调用的时候，不需要去了解其内部的实现细节。另外，由于这种松耦合、服务的发布方式，开发人员可以通过复用服务化的组件，来提交研发效能。
SOA诞生于20世纪90年代末，代表应用开发和集成演进过程中的一个重要阶段。在SOA诞生之前，一个应用访问另外一个应用的数据或者功能，需要为每个项目重复进行复杂的点对点的集成开发。那么通过SOA的能力，可以减少重复的集成开发工作。
什么是微服务
和SOA一样，微服务的体系架构由松耦合、可复用、职责单一的组件组成。但是，微服务不只适用于企业级的应用，也适用于构建单体应用，使其更加敏捷、伸缩和弹性。
微服务是真正的云原生架构方法。通过它，团队可以更容易的变更/发布代码，可以针对不同的组件采用不同技术栈，可以单独伸缩不同的组件，从而减少整个应用因为某一个功能需要面临过多的负荷，导致成本的浪费。
SOA与微服务的主要区别：范围
这两种方法的主要区别在于范围。简单地来说，SOA架构作用于企业范围，而微服务作用于应用范围。如果忽略了这种差异，每种方法的许多核心原则就会变得不兼容。如果你接受了范围上的差异，你可能很快就会意识到这两者可以相互补充，而不是竞争。
这里有几个例子可以说明这种区别:
复用
在SOA架构中，复用是服务集成的首要目标，在企业级系统，争取不同程度的复用是必不可少的。 而，在微服务体系结构中，在整个应用中复用的微服务组件会导致降低敏捷性和弹性的依赖关系。微服务组件通常喜欢通过复制重用代码，并接受数据复制来帮助改善解耦。
同步调用
SOA中的可复用的服务，主要使用同步协议(如RESTful api)在整个企业范围内调用。 然而，在微服务的应用中，同步调用会带来应用或服务之间的强弱依赖，从而导致弹性的损失。它还可能影响性能，导致延迟。在微服务的应用中，首选基于异步通信的交互模式，如领域事件，使用发布/订阅模型，可以保证微服务的组件能够在另一个组件的数据发生更改时，进行相应的更新。
重复数据
在SOA中服务的一个明确目标是让所有应用程序直接同步地获取和更改其主数据源上的数据，这样减少了维护复杂的数据同步的成本。在微服务中，理想情况下，每个微服务都能访问本地所需的所有数据，以确保其独立于其他微服务，甚至独立于其他应用，即使这样会意味着不同系统中的一些数据重复。另外，数据的重复增加了系统的复杂性，因此需要在敏捷性和性能方面进行平衡，这是微服务的设计所需要面对的。
SOA和微服务的其他差异
- 通信:在微服务体系结构中，每个服务都是独立开发的，具有自己的通信协议。对于SOA，每个服务必须共享称为企业服务总线(enterprise service bus, ESB)的公共通信机制。ESB可能成为整个企业的单点故障，如果单个服务变慢，可能会影响整个系统。
- 互操作性:为了保持简单，微服务使用轻量级消息传递协议，如HTTP/REST。soa对异构消息传递协议更开放。
- 服务粒度:微服务体系结构由高度职责单一的服务组成，每个服务都被设计为很好地完成一件事情。另一方面，组成soa的服务范围从小型的单一场景的服务到企业范围的复合服务。
- 速度:通过利用共享公共体系结构的优势，soa简化了开发和故障排除。然而，这也会使soa比微服务体系结构运行得更慢，从而使共享最小化，有利于工程应用的复制。
SOA vs. microservices: 那一个更适合你？
两种方法有各自的优点，那么如何确定哪种方法最适合您的需求呢?通常，这取决于应用环境的大小和多样性。更大、更多样化的环境更适合于面向服务的体系结构(SOA)，它支持通过企业服务总线(ESB)在异构应用程序和消息传递协议之间进行集成。较小的环境，包括web和移动应用程序，不需要如此健壮的通信层，而且更容易使用微服务体系结构进行开发。
