最近在和第三方对接时发现一个词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文档主要使用以下几个部分组成:
- <portType> Web Service执行的操作
- <message> Web Service使用的消息
- <types> Web Service使用的数据类型
- <binding> 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会专门说明。
对于框架,我觉得没有好坏之分,合适才是最重要的。
优缺点
优点如下:
- 降低用户成本,用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们,只要通过统一标准找数据总线就可以了。
- 程序之间关系服务简单。
- 识别哪些程序有问题。
缺点:提升了系统的复杂程度,性能有相应影响