SOA面向服务的框架
最近在和第三方对接时发现一个词SOA，以前一直认为SOA就是认证中心其中的一个服务，发现理解错误了，严重打脸。所以上网查询资料进行学习下。
概念
SOA 是Service-Oriented Architecture的简称，在《微服务设计》第1.3节中，SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进行内调用的方法进行通讯。不同的组织机构或个人从不同的层面上对SOA进行了描述和定义，我觉得较为准确的定义分为三类：
- W3C的定义：SOA是一种应用程序架构，在这种架构中，所以功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务形成业务流程。
- Service-architecture.com的定义：服务是精确定义、封装晚上、地理与其他读物所处环境和状态的函数。SOA本质上是服务的集合、服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
- Gartner的定义：SOA是一种C/S架构的软件设计方法，应用有服务和服务事业这租车，SOA与大多数通用的C/S架构模型不同之处在于它着重强调构建的松散耦合，并事业独立的标准接口。
我对SOA的认知是，将整个系统按照实际业务，拆分成合适的、能够独立部署的模块，每个模块之间相互独立，但是组合起来又是一个产品。比如在Springcloud中注册中心、网关、配置中心、监控中心等。至于如何拆分，可以使用DDD模式进行设计。
特点
SOA的实施具有鲜明的基本特征，实施SOA的关键目标是提高资源的利用率。如下为SOA的特征：
1. 外部或第三方可能访问
2. 随时可用，保证高可用性
3. 粗粒度的服务接口分级
4. 松散耦合
5. 可重用的服务
6. 服务接口设计管理
7. 标准化的服务接口
8. 支持各种消息模式
9. 精确定义的服务契约
关键技术
SOAP
Simple Object Access Protocol，即简单对象访问协议，简称SOAP。SOAP是基于xml在分散或分布式的环境中交换信息的简单协议，用于访问网络服务。可使应用程序在HTTP之上进行信息交换。当SOAP消息真正需要在网络上实际传输的时候，SOAP消息能够与不同的底层传输协议进行绑定，同时SOAP消息可以在很多种消息传输模式中使用。包括文本传输写哟（HTTP）、简单邮件传输协议（SMTP）、多用途互联网邮件协议（MIME）。SOAP主要包括如下四个部分：
- 封装：定义了一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的还是必需的。
- 编码规则：定义了一种序列号的机制，用于交换系统所定义的数据类型的实例。
- RPC表示：定义了一个用来表示远程过程调用和应答的协议。
- 绑定：定义了一个实验底层传输协议来完成在节点之间交换SOAP封装的约定。
SOAP消息基本上是从发送端到接收端的担心传输，但他们常常结合起来执行类似于请求/应答的模式。所有的消息都使用XML进行编码，消息包含三个部分：
- 封装（信封）：封装的元素名是Envelope，在表示消息的XML文档中，封装是顶层元素，在SOAP消息中必须出现。
- SOAP头：SOAP头的元素名是Header，提供了想SOAP消息中添加关于这条SOAP消息的某些要素的机制。SOAP定义了少量的属性用来表名这项要素是否可选以及由谁来处理。SOAP头在SOAP消息中可能出现，也可能不出现，如果出现的话，必须是SOAP封装元素的第一个直接子元素。
- SOAP体：SOAP体的元素名是Body，是包含消息的最终接受者想要的信息的容器。SOAP体在SOAP消息中必须出现且必须是SOAP封装元素的直接子元素。如果有头元素，则SOAP体必须直接跟在SOAP元素的第一个直接子元素。
WSDL
Web Service Description Language，即网络服务描述语言，检查WSDL。它是一门基于xml的预研，用于描述Web Service以及如何对它们进行访问。WSDL文档主要使用以下几个部分组成：
Web Service执行的操作 Web Service使用的消息 Web Service使用的数据类型 Web Service使用的通讯协议
它包含了服务实现定义和服务接口定义，如下图所示：
采用抽象接口定义对于提高系统的可扩展性很有帮助。服务接口定义就是一种抽象的、可重用的定义，行业标准组织可以使用这种重新的定义来规定一些标准的服务类型，服务实现制可以根据这些标准来实现具体的服务。
服务实现定义描述了给定服务提供者如何实现特定的服务接口。服务实现定义中包含服务和端口描述。一个服务常常会包含多个服务访问接口，而每个访问入口都会使用一个端口元素来描述，端口描述的是一个服务访问入口的部署细节。
UDDI
Universal Description，Discovery and Integration，可译为通用描述、发现与集成服务，简称UDDI。
UDDI是一个独立于平台的框架，通过使用Internet来描述服务，发现企业，并对企业服务进行集成。提供了一种服务发布、查询和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。UDDI规范描述了服务的概念，同事也定义了一种编程接口。通过UDDI提供的标准接口，企业可以发布自己的服务提供给其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。在UDDI技术规范中，主要包含以下三个部分的内容：
- 数据模型：用于描述业务组织和服务的XML Schema。
- API：是一组用于查询或发布UDDI数据的方法，基于SOAP。
- 注册服务：是SOA的一种基础设施，对应着服务注册中心的角色。
REST
Representational State Transfer，表述性状态转移，简称REST。
REST是一种使用HTTP和xml进行基于Web通信的技术，可降低开发的复杂性、提高系统的可伸缩性。它的简单性和缺少严格配置文件的特性，使它与SOAP很好的隔离开来，REST从根本上来说只支持几个操作（POST、GET、PUT和DELETE），建议只使用POST和GET，原因后面进行说明。这些搓澡适用于所有的小四。REST提出了如下的设计概念和准则：
- 网络上的所有事物都被抽象为资源
- 每个资源对应一个唯一的资源标识
- 通过通用的连接件接口对资源进行操作
- 对资源的各种操作不会改变资源标识
- 所有的操作都是无状态的
技术实现
SOA是一种概念和理想，需要借助于具体的技术和方法来实现它。本质上来看，SOA是用本地计算模型来实现一个分布式的计算应用，也称作“本地化设计，分布式工作”模型。CORBA、DCOM和EJB等都属于这种解决方式，也就是锁SOA最终可以基于这些标准来实现。
web service
web service是一个平台独立的、低耦合的、自包含的、基于可编程的web应用程序，可使用开放的xml标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。
web service有三个部分（服务提供者、服务请求者、服务注册中心）组成，分别解答三个问题：
- 服务之间如何传输数据？
- 数据的格式是怎样的？
- 如何发布和查找服务？
- 服务提供者。服务提供者是服务的所有者，该角色负责定义并实现服务，使用WSDL对服务进行详细、准确、规范的描述，并将该描述发布到服务注册中心，供服务请求者查找并绑定使用。
- 服务请求者。服务请求者是服务的使用者，虽然服务面向的是程序，但程序的最终使用者仍然是用户。从架构的角度上来看，服务请求者是查找、绑定并调用服务，或者与服务进行交互的应用程序。服务请求者可以有浏览器担当，由程序来控制。
- 服务注册中心。服务注册中心是连接服务提供者和服务请求者的纽带，服务提供者在此发布他们的服务描述，而服务请求者在服务注册中心查找需要的服务。不过，在某些情况下，服务注册中心是整个模型中的可选角色。例如使用静态绑定的服务，服务提供者可以吧描述直接发送给服务请求者。
在使用Web Service作为SOA的实现技术时，应用系统大致分为六个层次，如下图：
服务注册表
服务注册表（Service Registry）提供策略执行点，在这个点上，服务可以在SOA上进行注册，而已可以被发现和使用。从理论上来说，任何帮助服务注册、发现和查询服务合约、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。
- 服务注册。指服务提供者想服务注册表发布服务的功能，包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。使用服务注册表实现SOA时，要限制哪些新服务可以想注册表发布、由谁发布以及谁批准发布和根据什么条件批准等，以便使服务能够有序的注册。
- 服务位置。指服务使用者帮助它们查询已注册的服务，寻找符合自身要求的服务。这种查找主要是通过检索服务合约来实现的，在适应服务注册表实现SOA时，需要规定哪些用户可以访问服务注册表，以及哪些服务属性可以通过服务注册表进行暴露等，以便服务能得到有效的、经过授权的使用。
- 服务绑定。服务使用者利用查找到的服务合约来开发代码，开发的代码将与注册的服务进行绑定，调用注册的服务，以及与他们实现互动。可以利用集成的开发环境自动将新开发的服务与不同的新协议、方案和程序建通信所需的其他接口绑定在一起。
企业服务总线
Enterprise Service Bus简称ESB，是一种为进行连接服务提供的标准化的通信基础结构，基于开发的标准，为应用提供了一个可靠的、可度量的和高度安全的环境，并可以帮助企业对业务流程进行设计和模拟，对每个业务流程实施控制和跟踪、分析并改进流程和性能。
ESB提供了一种基础设施，消除了服务请求者和服务提供者之间的直接连接，是的服务请求者和服务提供者之间进一步解耦。需要具备以下功能：
- 支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。
- 通过使用 ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
- 充当缓冲器的 ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，不用在系统或数据发生变化时，改动服务代码。
- 在更高的层次，ESB 还提供诸如服务代理和协议转换等功能。允许在多种形式下通过像HTTP、SOAP 和 JMS 总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施。
- 提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。
- 提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性
微服务
微服务顾名思义，就是很小的服务，所以它属于面向服务架构的一种。通俗一点来说，微服务类似于古代著名的发明，活字印刷术，每个服务都是一个组件，通过编排组合的方式来使用，从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、缩短交付周期的效果。
常见的微服务使用的是Springboot。后面针对Springboot会专门说明。
对于框架，我觉得没有好坏之分，合适才是最重要的。
优缺点
优点如下：
- 降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。
- 程序之间关系服务简单。
- 识别哪些程序有问题。
缺点：提升了系统的复杂程度，性能有相应影响
借鉴资料：https://blog.csdn.net/hu19930613/article/details/82749534