SOA
面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。
SOA是支持面向服务的架构方式。面向服务是一种从服务、基于服务的开发、和服务成果等方面进行思考的方式。服务应有以下四个特性：
- 是具有指定结果的、可重复的业务活动的逻辑表示；
- 具有完备的特性（self-contained）；
- 可能由其他服务组成；
- 对服务的消费者来说，是一个黑盒子（不需要了解内部运作过程）。
解释
Refer: https://www.zhihu.com/question/42061683/answer/251131634
SOA粗暴理解：把系统按照实际业务，拆分成刚刚好大小的、合适的、独立部署的模块，每个模块之间相互独立。
比如现我有一个数据库，一个JavaWeb（或者PHP等）的网站客户端，一个安卓app客户端，一个IOS客户端。
现在我要从这个数据库中获取注册用户列表，如果不用SOA的设计思想，那么就会这样：JavaWeb里面写一个查询方法从数据库里面查数据然后在网页显示，安卓app里面写一个查询方法查询后在app上显示，IOS同样如此。这里就会出现查询方法重叠了，这样的坏处很明显了，三个地方都有相同的业务代码，要改三个地方都要改，而且要改的一模一样。当然问题不止这一个。
于是乎出现了这样的设计思想，比如用Java（或者是其他语言皆可）单独创建一个工程部署在一台服务器上，并且写一个方法（或称函数）执行上述查询操作，然后使其他人可以通过某种途径（可以是http链接，或者是基于socket的RPC调用）访问这个方法得到返回数据，返回的数据类型是通用的json或者xml数据，就是说把这个操作封装到一个工程中去，然后暴露访问的方式，形成“服务”。比如这里就是注册用户服务，而关于注册用户的所有相关增删改查操作这个服务都会提供方法。
这样一来，JavaWeb这边可以访问这个服务然后得到数据使用，安卓和IOS这里也可以通过这个服务得到数据。而且最重要的是，要修改关于注册用户的业务方法只要改这个服务就好了，很好的解耦。同理，其他业务比如商品、广告等业务都可以单独形成服务部署在单独服务器上。
还有就是一旦哪天突然有一堆人要注册，假设这堆人仅仅只是注册而不做其他事情，其他业务比如商品、广告服务等都不忙，唯独注册这个功能压力很大，而原有的一台部署了注册服务的服务器已经承受不了这么高的并发，这时候就可以单独集群部署这个注册服务，提供多几台服务器提供注册服务，而其他服务还不忙，那就维持原样。
当然，还有很多其他好处。
以上我所描述的都还不能完全称为SOA，还不够完整，因为它少了服务治理这一环节。
什么是服务治理，就是当服务越来越多，调用方也越来越多的时候，它们之间的关系就变得非常混乱，需要对这些关系进行管理。举例，还是上面的例子，假如我有一个用户服务，一开始有调用方1和调用方2来使用这个服务，后来越来越多，将近上百个调用方，这个时候作为服务方，它只知道提供服务，却不知道具体为谁提供了服务。而对于开发者来说，知道这N多调用方和N多服务方之间的关系是非常重要的。
所以这个时候就需要能进行服务治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服务治理功能，我们就能清晰地看到服务被谁谁谁调用，谁谁谁调用了哪些服务，哪些服务是热点服务需要配置服务器集群，而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。
这个时候就是更加完善一点的SOA了。
当然，还可以更进一步，加上服务监控跟踪等等等等之类的。
实际上SOA只是一种架构设计模式，而SOAP、REST、RPC就是根据这种设计模式构建出来的规范，其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基于socket的形式。上文提到的CXF就是典型的SOAP/REST框架，dubbo就是典型的RPC框架，而SpringCloud就是遵守REST规范的生态系统。
SOA和微服务microservice的区别
我们应该将SOA视为微服务的超集。
| SOA架构 | 微服务架构 |
|---|---|
| 最大化应用服务的可重用性 | 关注于解耦 |
| 系统的变化需要修改整体结构 | 系统的变化是创造一种新的服务 |
| DevOps和持续交付正在变得流行，但不是主流 | 专注于DevOps和持续交付 |
| 专注于业务功能的可重用性 | 更加重视“边界上下文”的概念 |
| 对于通信，它使用企业服务总线（ESB） | 对于通信使用不那么复杂和简单的消息系统 |
| 支持多种消息协议 | 使用轻量级协议，如HTTP，REST或Thrift API |
| 为部署到它的所有服务使用通用平台 | 应用服务器并未真正使用，通常使用云平台 |
| 使用容器（如Docker）不太受欢迎 | 容器与微服务一起工作得很好 |
| SOA服务共享数据存储 | 每个微服务可以具有独立的数据存储 |
| 共同治理和标准 | 轻松治理，更加注重团队协作和选择自由度 |
我将在上表中显示的某些方面进一步详细说明，并进一步解释其中的差异：
开发 - 在这两种体系结构中，可以使用不同的编程语言和工具开发服务，从而为开发团队带来技术多样性。可以在多个团队中组织开发，但是，在SOA中，每个团队都需要了解常见的通信机制。另一方面，通过微服务，服务可以独立于其他服务运行和部署。因此，更容易经常部署新版本的微服务或独立扩展服务。您可以在此处进一步了解微服务的这些优点。
“绑定上下文” - SOA鼓励共享组件，而微服务试图通过“绑定上下文”最小化共享。绑定上下文指的是将组件及其数据作为单个单元耦合，具有最小的依赖性。由于SOA依赖于多种服务来满足业务请求，因此基于SOA构建的系统可能比微服务慢。
通信 - 在SOA中，ESB可能成为影响整个系统的单点故障。由于每个服务都通过ESB进行通信，如果其中一个服务速度变慢，它可能会阻塞ESB请求该服务。另一方面，微服务在容错方面要好得多。例如，如果一个微服务有内存故障，那么只有那个微服务会受到影响。所有其他微服务将继续定期处理请求。
互操作性 - SOA通过其消息传递中间件组件促进多个异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此，如果要在异构环境中使用不同协议集成多个系统，则需要考虑SOA。如果可以通过相同的远程访问协议访问所有服务，那么微服务对您来说是更好的选择。
大小 - 最后但并非最不重要的是，SOA和微服务之间的主要区别在于大小和范围。微服务中的前缀“微”指的是内部组件的粒度，这意味着它们必须比SOA趋向于小得多。微服务中的服务组件通常只有一个目的，他们做得很好。另一方面，在SOA中，服务通常包含更多的业务功能，并且它们通常作为完整的子系统实现。
人们不能简单地说一个架构比另一个架构好。它主要取决于您正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。 话虽这么说，较小的应用程序不适合SOA，因为它们不需要消息传递中间件组件。 另一方面，微服务更适合于较小且分区良好的基于Web的系统。此外，如果您正在开发移动或Web应用程序，那么微服务可以让您作为开发人员获得更大的控制权。 最后，我们可以得出结论，因为它们用于不同的目的 - 微服务和SOA确实是不同类型的架构。
SOA范围大，着眼于整个企业，而微服务范围小，着眼于应用。
SOA是与企业服务的公开性密切相关的，关注的范围更大，是应用与应用之间的通信、服务公开。
微服务是与应用架构紧密相关的，关注的范围小，只关注应用本身的范围。