1、为什么需要SOA架构
1.1 系统集成问题
- 异构系统整合
- 例如，一个企业可能同时拥有用 Java 开发的企业资源规划（ERP）系统、用 C# 开发的客户关系管理（CRM）系统以及用 Python 开发的数据分析系统。通过 SOA，可以将这些系统的特定功能以服务的形式暴露出来，然后根据业务需求进行组合和调用，实现数据的共享和业务流程的协同。
- 可扩展性
- 比如，企业要增加一个新的市场推广活动管理功能，可以开发一个独立的服务来实现这个功能，并将其集成到现有的 SOA 架构中。这样，既可以满足新的业务需求，又不会干扰到其他正在运行的业务模块。
1.2 业务灵活性问题
- 快速响应业务变化
- 例如，当市场需求发生变化，企业需要调整产品销售策略时，可以通过重新组合现有的服务来实现新的销售流程，而无需对整个系统进行大规模的开发和修改
- 服务复用
- 比如，一个用于用户身份验证的服务可以在企业的多个系统中复用，无论是内部员工管理系统还是面向客户的电子商务平台，都可以调用这个服务进行用户身份验证。
1.3 技术独立性问题
- 技术升级与替换
- 例如，企业决定将数据库从一种类型转换为另一种类型，只需要对相应的数据服务进行调整，而不会影响到其他业务服务和整个系统的运行
- 降低技术风险
- 如果企业只依赖于一种特定的技术，一旦该技术出现问题或不再被支持，可能会对整个系统造成严重影响。而在 SOA 架构下，企业可以根据实际情况选择最适合的技术来实现各个服务，从而降低技术风险。
2. SOA架构及需要解决的问题
从应用的角度定义，可以认为 SOA是一种应用框架，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务
从软件的基本原理定义，可以认为SOA是一个组件模型，它将应用程序的不同功能单元 (称为服务)通过这些服务之间定义良好的接口和契约联系起来。
简单理解，SOA即将业务功能封装为服务（应用框架），通过接口使不同服务进行通信（组件模型）
所以需要解决的问题
- 我有一个服务，我如何给别人使用？我又怎么使用别人的服务？
- 不同服务应该如何通信
为了解决这些问题，所以就开始制定协议
3. SOA协议
3.1 SOA的发展史
3.1.1 萌芽:xml
通过XML，开发人员摆脱了HTML语言的限制，可以将任何文档转换成XML格式，然后跨越因特网协议传输
3.1.2 标准化阶段: SOAP、WSDL、UDDI
三个著名的 Web服务标准和规范：
- 简单对象访问协议 (Simple Object Access Protocal,SOAP)
- Web服务描述语言 (Web Services Description Language,WSDL)
- 通用服务发现和集成协议 (Universal Discovery Description and Integration,UDDI)
3.1.3 成熟应用阶段: SCA/SDO/WS-Policy
SCA 和 SDO构成了SOA 编程模型的基础，而WS-Policy建立了SOA组件之间安全交互的规范。
3.2 SOA主要协议
3.2.1 UDDI（通用服务发现和集成协议）
对应需要解决的服务发现使用问题，UDDI就是一个注册中心，可以去注册中心注册，然后其他人可以发现注册的服务。
微软和IBM的公共UDDI注册中心早在2006年就已经关闭了，所以更像是一个历史产物，现在使用的模式是在公司内部搭建自己的注册中心
3.2.2 WSDL（web服务描述语言）
WSDL(Web Services Description Language,Web服务描述语言)，是一个用来描述Web服务和说明如何与Web服务通信的XML语言。通过WSDL, 可描述Web服务的三个基本属性。 (1)服务做些什么——服务所提供的操作(方法)。 (2)如何访问服务——和服务交互的数据格式以及必要协议。 (3)服务位于何处——协议相关的地址，如 URL。
顾名思义，它首先是一门语言，这个语言就是用来描述web服务和通信，其实就是很常见的get/post等等方法，http或者https，端口号是多少
简单理解，它就是SOA通信传递的数据格式
3.2.3 SOAP（简单对象访问协议）
SOAP是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议。它包括4个部分：1. SOAP封装 (Envelop), 定义了一个描述消息中的内容是什么，是谁发送的，谁应当接收并处理它以及如何处理它们的框架；2. SOAP编码规则 (Encoding Rules), 用于表示应用程序需要使用的 数据类型 的实例；3. SOAP RPC表示 (RPC Representation) 是远程过程调用和应答的协定；4.SOAP绑定 (Binding) 是使用底层协议交换信息。
WSDL已经确定需要传递的数据长什么样，现在就是需要解决服务之间通信传递的问题，所以需要SOAP。
但是不要忘记我们上面还有一个图
如图，服务间的通信首先可以通过这个叫ESB的家伙进行通信，它同时兼顾了数据通信的协议和传递的数据格式问题
一个典型的在 ESB环境中组件之间的交互过程是：首先由服务请求者触发一次交互过程，产生一个服务请求消息，并将该消息按照ESB 的要求标准化，然后标准化的消息被发送给服务总线。 ESB 根据请求消息中的服务名或者接口名进行目的组件查找，将消息转发至目的组件，并最终将处理结果逆向返回给服务请求者。
到这里，我们有两种方案
- ESB
- UDDI+SOAP+WSDL
按教材的分发，ESB是企业服务总线模式，而UDDI就是服务注册表模式，至于通信及通信格式这些问题，可以采用SOPA+WSDL的方案，这些都不是必须的，都可以根据实际情况调整
3.2.4 REST（表述性转移）
（表述性状态转移，这个名字挺好的TOT）
做开发最熟的RESTful api，就是这种理念的实现，不多赘述
4. SOA设计模式
如上，我们已经讲了服务注册表模式和企业服务总线模式
现在我们讲微服务模式
看图说故事，右边的微服务架构，第一眼就看到少了ESB，SOA把系统分为服务，微服务把系统分为微服务，所以微服务=SOA？
当然不是
SOA 与微服务的区别在于如下几个方面：1. 微服务相比于 SOA更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响；2. 微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用， 无关语言、平台限制；3. 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。
另一个问题，微服务是SOA的一种？SOA包含了微服务？
微服务可以被认为是 SOA 的一种演进形式，但两者并不是严格的包含关系。微服务是在 SOA 的基础上发展而来的一种架构风格，它在服务粒度、技术实现和部署方式等方面与 SOA 存在差异。虽然两者有一定的相似之处，但不能简单地认为微服务是 SOA 的一种，也不是严格的包含关系。
