1、为什么需要SOA架构

1.1 系统集成问题

1. 异构系统整合

• 例如，一个企业可能同时拥有用 Java 开发的企业资源规划（ERP）系统、用 C# 开发的客户关系管理（CRM）系统以及用 Python 开发的数据分析系统。通过 SOA，可以将这些系统的特定功能以服务的形式暴露出来，然后根据业务需求进行组合和调用，实现数据的共享和业务流程的协同。

2. 可扩展性

• 比如，企业要增加一个新的市场推广活动管理功能，可以开发一个独立的服务来实现这个功能，并将其集成到现有的 SOA 架构中。这样，既可以满足新的业务需求，又不会干扰到其他正在运行的业务模块。

1.2 业务灵活性问题

1. 快速响应业务变化

• 例如，当市场需求发生变化，企业需要调整产品销售策略时，可以通过重新组合现有的服务来实现新的销售流程，而无需对整个系统进行大规模的开发和修改

2. 服务复用

• 比如，一个用于用户身份验证的服务可以在企业的多个系统中复用，无论是内部员工管理系统还是面向客户的电子商务平台，都可以调用这个服务进行用户身份验证。

1.3 技术独立性问题

1. 技术升级与替换

• 例如，企业决定将数据库从一种类型转换为另一种类型，只需要对相应的数据服务进行调整，而不会影响到其他业务服务和整个系统的运行

2. 降低技术风险

• 如果企业只依赖于一种特定的技术，一旦该技术出现问题或不再被支持，可能会对整个系统造成严重影响。而在 SOA 架构下，企业可以根据实际情况选择最适合的技术来实现各个服务，从而降低技术风险。

2. SOA架构及需要解决的问题

从应用的角度定义，可以认为 SOA是一种应用框架，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务

从软件的基本原理定义，可以认为SOA是一个组件模型，它将应用程序的不同功能单元 (称为服务)通过这些服务之间定义良好的接口和契约联系起来。

简单理解，SOA即将业务功能封装为服务（应用框架），通过接口使不同服务进行通信（组件模型）

所以需要解决的问题

1. 我有一个服务，我如何给别人使用？我又怎么使用别人的服务？
2. 不同服务应该如何通信

为了解决这些问题，所以就开始制定协议

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 根据请求消息中的服务名或者接口名进行目的组件查找，将消息转发至目的组件，并最终将处理结果逆向返回给服务请求者。

到这里，我们有两种方案

1. ESB
2. UDDI+SOAP+WSDL
   

按教材的分发，ESB是企业服务总线模式，而UDDI就是服务注册表模式，至于通信及通信格式这些问题，可以采用SOPA+WSDL的方案，这些都不是必须的，都可以根据实际情况调整

3.2.4 REST（表述性转移）

（表述性状态转移，这个名字挺好的TOT）

做开发最熟的RESTful api，就是这种理念的实现，不多赘述

4. SOA设计模式

如上，我们已经讲了服务注册表模式和企业服务总线模式
现在我们讲微服务模式

看图说故事，右边的微服务架构，第一眼就看到少了ESB，SOA把系统分为服务，微服务把系统分为微服务，所以微服务=SOA？

当然不是

另一个问题，微服务是SOA的一种？SOA包含了微服务？

微服务可以被认为是 SOA 的一种演进形式，但两者并不是严格的包含关系。微服务是在 SOA 的基础上发展而来的一种架构风格，它在服务粒度、技术实现和部署方式等方面与 SOA 存在差异。虽然两者有一定的相似之处，但不能简单地认为微服务是 SOA 的一种，也不是严格的包含关系。

SOA与微服务的区别

1. 粒度：

SOA：服务通常较大，可能包含多个功能，因此 API 可能更加复杂，往往需要更大的数据载荷。
微服务：服务较小且专注，API 通常更简洁，针对单一功能或资源。

2. 通信协议：

SOA：可能使用多种协议（如 SOAP、REST、JMS），并常常依赖企业服务总线（ESB）来管理和协调服务间的通信。
微服务：通常更倾向于轻量级协议（如 REST、gRPC），直接服务间通信，避免中间层。

3. 耦合度：

SOA：服务间可能存在较强的耦合，依赖于共享的模式或数据模型。
微服务：服务间的耦合较松散，每个微服务可以独立变化，使用各自的数据模型。

4. 治理：

SOA：通常需要更多的治理和规范，特别是在大型企业环境中。
微服务：更强调去中心化的治理，团队可以自主决定服务的实现和技术栈。
总体来说，微服务更注重灵活性和独立性，而 SOA 更注重集成和治理。