一、是什么
SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。以粗粒度的业务服务作为基础来对公司业务进行建模;以业务服务为基础来实现的IT系统更灵活、更易于重用、也更快地应对企业业务需求的变化。
SOA将应用程序的不同功能单元通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。
二、有什么用
SOA的好处
1. 松耦合：由于服务自治，有一定封装边界，服务调用交互是通过发布接口。这意味着应用程序不感兴趣的服务如何被实现。
2.位置透明：服务的消费者不必关系服务位于什么地方。
3.可在异构平台间复用。可以将遗留系统包装成服务。
4.便于测试，能并行开发，较高可靠性和良好可伸缩性。
三、怎么用
四、深入研究方向
1、SOA和MSA的区别和联系
|
SOA
|
微服务架构
|
|
应用程序服务的可重用性的最大化
|
专注于解耦
|
|
系统性的改变需要修改整体
|
系统性的改变是创建一个新的服务
|
|
DevOps和持续交付正在变得流行，但还不是主流
|
强烈关注DevOps和持续交付
|
|
专注于业务功能重用
|
更重视“上下文边界”的概念
|
|
通信使用企业服务总线ESB
|
对于通信而言，使用较少精细和简单的消息系统
|
|
支持多种消息协议
|
使用轻量级协议，例如HTTP，REST或Thrift API
|
|
对部署到它的所有服务使用通用平台
|
应用程序服务器不是真的被使用，通常使用云平台
|
|
容器（如Docker）的使用不太受欢迎
|
容器在微服务方面效果很好
|
|
SOA服务共享数据存储
|
每个微服务可以有一个独立的数据存储
|
|
共同的治理和标准
|
轻松的治理，更加关注团队协作和选择自由
|
开发方面 - 两种架构都可以使用不同的编程语言和工具开发服务。但是在SOA中，每个团队都需要了解常见的通信机制。另一方面，使用微服务，服务可以独立于其他服务运行和部署。因此，频繁部署新版本的微服务或独立扩展服务会更容易。
上下文边界 - SOA鼓励组件的共享，而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求，构建在SOA上的系统可能比微服务要慢。
通信 - 在SOA中，ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信，如果其中一个服务变慢，可能会阻塞ESB并请求该服务。另一方面，微服务在容错方面要好得多。例如，如果一个微服务存在内存错误，那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。
互操作性 - SOA通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。因此，如果您想要在异构环境中使用不同协议来集成多个系统，则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问，那么微服务对您来说是一个更好的选择。
体量大小 - SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度，意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的，他们做得很好。另一方面，在SOA服务中通常包含更多的业务功能，并且通常将它们实现为完整的子系统。
2、服务治理
五、面试点
1、什么是合同，地址和绑定？
三个SOA的标准术语。每个服务都必须公开一个或多个端点，以便让该服务提供给客户端调用。
合同是两方或多方之间的协议。它定义了一种客户端如何与服务通信的协议。从技术上讲，它有描述参数和返回值的方法。
地址表明在哪儿能找到这种服务。地址是一个URL，它指向服务的位置。
绑定是决定这个端点如何可以访问。它决定了如何完成通信。例如，你暴露你的服务，可以使用SOAP over HTTP或通过TCP的BINARY进行访问。因此，对于这些通信介质将被创建两个绑定。