系统架构设计高级技能 · 面向服务架构设计理论与实践
系列文章目录
系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA（一）【系统架构设计师】
系统架构设计高级技能 · 系统质量属性与架构评估（二）【系统架构设计师】
系统架构设计高级技能 · 软件可靠性分析与设计（三）【系统架构设计师】
系统架构设计高级技能 · 面向服务架构设计理论与实践
- 系列文章目录
- 一、SOA的相关概念
-
- 1.1SOA的定义
- 1.2 业务流程与业务流程执行语言
- 二、SOA的发展史
- 三、SOA与微服务的区别
- 三、SOA的参考架构
- 四、SOA的主要协议规范
- 五、SOA的设计标准要求
- 六、SOA的作用与设计原则
- 七、SOA的设计模式
-
- 7.1 服务注册表模式
- 7.2 企业服务总线模式（EBS）
- 7.3 微服务模式
- 7.4 微服务架构模式方案
- 7.5 微服务架构面临的问题与挑战
- 八、构建SOA架构时应该注意的问题
- 九、SOA实施的过程
一、SOA的相关概念
1.1SOA的定义
从软件的基本原理定义，可以认为SOA是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的 需接口和契约 联系起来。接口是采用中立的方式进行定义的，它应该独立与实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
1.2 业务流程与业务流程执行语言
业务流程与业务流程执行语言（Business Process Execution Language，BPEL） 。业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。使用BPEL，用户可以通过组合、编排和协调Web服务自上而下地实现面向服务的体系结构。BPEL目前用于整合现有的Web Services，将现有的Web Service按照要求的业务流程整理成为一个新的Web Service，在这个基础上，形成一个从外界看来和单个Service一样的Service。
二、SOA的发展史
（1） 萌芽阶段 ：这种广泛使用XML，允许组织定义文档的元数据，实现企业内部和企业之间的电子数据交换，规定了服务之间以及服务内部数据交换的格式和结构。
（2） 标准化阶段 ：国际标准和规范 - 简单对象访问协议（Simple Objec Access Protocol，SOAP）、Web服务描述语言（Web Service Description，UDDI）。
（3） 成熟阶段 ：3个重量级规范 - SCA、SDO、WS-Policy。SCA和SDO构成了SOA编程模型的基础，而WS-Policy建立了SOA组件之间安全交互的规范。
三、SOA与微服务的区别
（1） 微服务相比于SOA更加精细，微服务更多地以独立的进程的方式存在，相互之间并无影响。
（2） 微服务提供的接口方式更加通用化，例如HTTP RESTful方式，各种终端都可以调用，无关语言、平台限制。
（3） 微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。
如下，SOA架构与微服务架构的对比图：
三、SOA的参考架构
IBM的Websphere业务集成参考架构是典型的以服务为中心的企业集成架构，它可划分为6大类：
（1） 业务逻辑服务（Business Logic Service）。
（2） 控制服务（Control Service）。
（3） 连接服务（Connectivity Service）。
（4） 业务创新和优化服务（Business Innovation and Optimization Service）。
（5） 开发服务（Development Service）。
（6） IT服务管理（IT Service Management）。
四、SOA的主要协议规范
如下，基于Web服务协议：
（1） UDDI协议 ：统一描述、发现和集成协议。包含了服务描述与发现的标准规范，它使得商业实体能够彼此发现；定义它们怎样在Internet上相互作用，并在一个全球的注册体系架构中共享信息。
（2） Web服务描述语言（Web Service Description Language, WSDL） :WSDL是一个用来描述Web服务和说明如何与Web服务通信的XML语言。描述了Web服务的3个基本属性：
- 服务做些什么 - 服务所提供的操作（方法）。
- 如何访问服务 - 和服务交互的数据格式以及必要协议。
- 服务位于何处 - 协议相关的地址，如URL。
如下，是文档基本结构框架：
（3） SOAP协议 ：SOAP是在分散或分布式的环境中交换信息的简单协议，是一个基于XML的协议。
（4） REST规范 ：为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。微服务对外就是以REST API的形式暴露给调用者。RESTful即REST形式的，是对遵循REST设计思想同时满足设计约束的一类架构设计或应用程序的统称，这一类都可称为RESTful，可以理解为资源表述性状态转移：
- 资源 ：将在互联网中一切暴露给客户端的事务都可以看做是一种资源。
- 表述 ：REST中用表述描述资源在Web中某一个时间的状态。
- 状态转移 ：分为两种，
应用状态 - 对某个时间内用户请求会话相关信息的快照，保存在客户端。
资源状态 - 在服务端保存，是对某个时间资源请求表述的快照。 - 超链接 ： 通过在页面中嵌入链接和其他资源建立联系。
五、SOA的设计标准要求
（1） 文档标准化。
SOA服务具有平台独立的自我描述XML文档。Web服务描述语言是用于描述服务的标准语言。
（2） 通信协议标准。
SOA服务用消息进行通信，该消息通常使用XML Schema来定义（也称作XML schema Definition，XSD）。
（3） 应用程序统一登记与集成。
在一个企业内部，SOA服务通过一个扮演目录列表（Director Listing）角色的登记（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述、定义和集成是服务登记的标准。
（4） 服务质量（Qos）。主要包括：
- 可靠性：服务消费者和服务提供者之间传输文档时的传输特性（且仅仅传送一次、最多传送一次、重复消息过滤、保证消息传送）
- 安全性：Web服务安全规范用来保证消息的安全性。
- 策略：服务提供者有时候会要求服务消费者与某种策略通信。例如，服务提供商可能会要求消费者提供Kerberos安全标示才能取得某项服务。
- 控制：在SOA中，进程是使用一组离散的服务创建的。BPEL4WS或者WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。
- 管理：针对运行在多种环境下的所有服务，必须有一个统一管理系统，以便系统管理员能够有效管理。任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-companyliant）的管理方案来管理。
六、SOA的作用与设计原则
（1） SOA的主要作用：打破信息孤岛，把应用和资源转换成服务。以及把这些服务变成标准的服务，形成资源的共享。
（2） SOA的设计原则 主要有：
- 无状态 。
以避免服务请求者依赖于服务提供者的状态。 - 单一实例 。
以高内聚的实现方法，来避免功能冗余。 - 明确定义的接口 。
服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界限。 - 自包含和模块化 。
服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。 - 粗粒度 。
服务数量不应该太大，依靠消息交互而不是远程过程调用（Remote Procedure Call，RPC），通常消息量较大，但是服务之间的交互频度较低。 - 服务之间的松耦合性 。
服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。 - 互操作性、兼容和策略声明 。
为了确保服务规约的全面和明确，利用策略来定义可配置的互操作语义，来描述特定服务的期望、控制其行为。利用策略声明确保服务期望和语义兼容性方面的完整和明确。
七、SOA的设计模式
7.1 服务注册表模式
服务注册表支持驱动SOA治理的服务合同、策略和元数据的开发、发布和管理。
（1） 服务注册 ：应用开发者，也叫服务提供者，向注册表公布它们的功能。
（2） 服务位置 ：也就是服务应用的开发者，帮助他们查询注册服务，寻找符合自身要求的服务。
（3） 服务绑定 ：服务的消费者利用检索到的服务合同来开发代码，开发的代码与注册的服务绑定、调用注册的服务以及它们实现互动。
7.2 企业服务总线模式（EBS）
企业服务总线模式提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入”到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互。其核心功能如下：
（1）提供位置透明性的消息路由和寻址服务。程序组件之间无须关注对方的路由和寻址。
（2）提供服务注册和命名的管理功能。
（3）支持多种消息传递规范（如请求 / 响应、发布订阅）。
（4）支持多种可以广泛使用的传输协议。
（5）支持多种数据格式及其相互转换。
（6）提供日志和监控功能。
如下，EBS示意图 ：
7.3 微服务模式
微服务架构 将 一个大型的单个应用或服务拆分成多个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的。 微服务模式的特点如下：
（1） 复杂应用解耦 ：微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。
（2） 独立 ：微服务在系统软件生命周期中是独立开发、测试及部署的。
（3） 技术选型灵活 ：微服务架构下系统应用的技术选型是去中心化的，每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术。
（4） 容错 ：各个微服务相互独立，故障会被隔离在单个服务中，并且系统其他微服务可以通过重试、平稳退化等机制实现应用层的容错，从而提高系统应用的容错性。
（5） 松耦合，易扩展 ：微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现微服务架构的灵活性。单体应用架构与微服务架构的，示意图如下：
7.4 微服务架构模式方案
微服务架构模式 方案主要包括：
（1） 聚合器微服务 ：聚合器充当流程指挥者，调用多个微服务实现系统应用程序所需功能。
（2） 链式微服务 ：客户端或服务器在收到请求后，会发生多个服务间的嵌套递归调用，返回经过处理的响应。
（3） 数据共享微服务 ：该模式适用于在单体架构应用到微服务架构的过渡阶段，服务之间允许存在强耦合关系，例如存在多个微服务共享缓存与数据库存储的现象。
（4） 异步消息传递微服务 ：对于一些不必要以同步方式运行的业务逻辑，可以使用消息队列代替REST实现请求、响应，加快服务调用的响应速度。
如下，单体架构与微服务架构：
7.5 微服务架构面临的问题与挑战
（1） 服务发现与服务调用链跟踪变得困难。
（2） 很难实现传统数据库的强一致性，转而追求最终一致性。
八、构建SOA架构时应该注意的问题
（1） 原有系统架构中的集成需求 包括：应用程序集成的需求、终端用户界面集成的需求、流程集成的需求以及已有系统信息集成的需求。
（2） 服务粒度的控制以及无状态服务的设计 的表述如下：
- 服务粒度的控制 ：对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。
- 无状态服务的设计 ：SOA系统架构中的具体服务应该都是独自的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。
九、SOA实施的过程
（1） 选择SOA解决方案 主要从以下3个方面进行：
- 尽量选择能进行全局规划的方案。
- 选择时充分考虑企业自身的需求。
- 从平台、实施等技术方面进行考察。
（2） 业务流程分析 主要关注：
- 建立服务模型：
自顶向下分解法、业务目标分析法、自底向上分析法。 - 建立业务流程：
建立业务对象（实体、过程、事件等业务对象）、建立服务接口、建立服务流程。