软件架构设计-面向服务的架构设计

大家好，欢迎来到IT知识分享网。

一、面向服务的架构SOA

SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。 SOA 并不是一个新鲜事物，而只是面向对象模型的一种替代。虽然基于 SOA 的系统并不排除使用 OOD 来构建单个服务，但是其整体设计却是面向服务的。由于 SOA 考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。

SOA 系统原型的一个典型例子是 CORBA，它已经出现很长时间，其定义的概念与 SOA 相似。SOA 建立在 XML 等新技术的基础上，通过使用基于 XML 的语言来描述接口，服务已经转到更动态且更灵活的接口系统中，CORBA 中的 IDL 无法与之相比。

在 SOA 模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。

SOA三大特点：松散耦合、粗粒度、标准化接口

SOA有6个服务类型：

1. 连接服务
   连接服务又称连通服务，是面向服务架构的骨干，在完成服务的接入，服务间的通信和交互基础上，还提供安全性、可靠性、高性能的服务能力保障。连接服务的一个典型实现就是企业服务总线(Enterprise Service Bus，ESB)。
2. 协作服务
   协作服务通常由通信代理和Web服务代理两部分组成。通信代理与连通服务中的通信代理实现内部有效的数据通信，Web服务代理与外部的公共注册中心交互，注册本平台对外开放的Web服务以及查找所需要访问的外部Web服务。协作服务既可以实现组织之间(如供应链的合作伙伴之间)的交互通信，也可以实现组织内部(如跨地域的分支机构之间，并有防火墙进行保护的情况)之间的交互通信。
3. 业务服务
   业务服务指为新建服务提供的特定运行支持环境。新建服务包括单个服务以及合成服务，不包括流程化的服务。合成服务一般由应用编码实现，它可以调用其他的服务(包括：单个服务、合成服务和流程化的服务)。业务服务与连通服务相联接，其中的新建服务与其他服务的通信和交互通过连通服务来实现。业务服务的运行信息由运行管理服务保存，业务服务也接受并执行运行管理服务的管理和控制命令。
4. 业务流程服务
   流程服务是业务流程的运行环境，提供流程驱动、服务调用、事务管理等功能。流程服务是为业务流程的运行提供的一组标准服务。业务流程是一组服务的集合，可以按照特定的顺序并使用一组特定的规则进行调用。业务流程可以由不同粒度的服务组成，其本身也可视为服务。
5. 交互服务
   交互服务实现人与服务之间的交互功能。人可以是服务的消费者，也可以是服务的提供者。人不能直接消费服务，也不能直接提供服务，需要通过相应的程序实现代理操作(即人通过操作程序实现与服务的交互)。交互服务就是需要提供一组完整的功能，以实现人与服务的交互，并能够方便地进行交互。人员需要请求服务时，向连通服务发送消息请求，由连通服务查找服务，并将请求消息传递给服务提供者。
6. 信息服务
   信息服务特指为上层应用系统、同层的其他服务等提供数据访问及资源访问服务。其目标是使应用系统能够统一、透明、高效地访问和操纵位于网络环境中的各种分布、异构的数据资源，为实现全局数据访问、加快应用开发、增强网络应用和方便系统管理提供支持。

二、Web Service

由服务请求者、服务提供者、服务注册中心三个角色构成, 支持服务发布、查找和绑定。

动态绑定（调用地址从注册中心获取）与静态绑定（调用地址写死）。
关键技术: UDDI / WSDL / SOAP / REST /XML。

UDDI(universal description,discovery,intergration)统一描述、发现和集成：用于 Web 服务注册和服务查找；

WSDL(web service description language)web服务描述语言：用于描述 Web 服务的接口和操作功能；

SOAP(simple object access protocol)简单对象访问协议：为建立 Web 服务和服务请求之间的通信提供支持；

BPEL(business process execution language) 企业过程执行语言：用来将分散的、功能单一的web服务组织成一个复杂的有机应用.

REST(representational state transfer)表述性状态转移：REST是一种使用HTTP、XML技术进行基于web通信的技术，它将网络中所有的事物抽象为资源，每个资源对应唯一的统一资源标识符URI。客户端通过URI获取资源的表述，并通过获得资源的表述使得其状态发生改变。REST将资源/资源的表述/获取资源的动作三者进行分离。

三、企业服务总线 ESB

ESB 是由中间件技术实现并支持 SOA的一组基础架构，是传统中间件技术与 XML、 Web Service 等技术结合的产物，是在整个企业集成架构下的面向服务的企业应用集成机制。

主要支持异构系统集成。ESB基于内容的路由和过滤，具备复杂数据的传输能力，并可以提供一系列标准接口。

1. 监控与管理 （服务注册和命名）
2. 消息路由
3. 消息增强 (支持多种消息传递规范)
4. 消息格式转换
5. 传输协议转换
6. 服务位置透明性
7. 安全性

四、微服务

微服务顾名思义，就是很小的服务，所以它属于面向服务架构的一种。通俗一点来说，微服务类似于古代著名的发明，活字印刷术，每个服务都是一个组件，通过编排组合的方式来使用，从而真正做到了独立、解耦、组件化、易维护、可复用、可替换、高可用、最终达到提高交付质量、缩短交付周期的效果。

从专业的角度来看，微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务的核心特点为：小, 且专注于做⼀件事情、轻量级的通信机制、松耦合、独立部署。

微服务的优势：

1. 技术异构性

   在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术来实现。可以混合使用多种编程语言、开发框架以及数据存储技术.

2. 弹性

   弹性主要讲的是系统中一部分出现故障会引起多大问题。在单块系统中，一个部分出现问题，可能导致整体系统的问题。而微服务架构中，每个服务可以内置可用性的解决方案与功能降级方案，所以比单块系统强。

3. 扩展

   单块系统中，我们要做扩展，往往是整体进行扩展。而在微服务架构中，可以针对单个服务进行扩展。

4. 简化部署

   简单的服务更容易部署, 每个服务的部署都是独立的, 单个服务出问题不会导致整个系统的故障。

   在大型单块系统中，即使修改一行代码，也需要重新部署整个应用系统。这种部署的影响很大、风险很高，因此不敢轻易地重新部署。而微服务架构中，每个服务的部署都是 独立的，这样就可以更快地对特定部分的代码进行部署。

5. 与组织结构相匹配

   为服务强调模块化的结构, 可以将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。

6. 可组合性

   在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗粒度的接口供外部使用。

7. 对可替代性的优化

   在单块系统中如果删除系统中的上百行代码，也许不知道会发生什么，引起什么样的问题，因为单块系统中关联性很强。但在微服务架构中，我们可以在需要时轻易地重写服务，或者删除不再使用的服务。

五、MDA 模型驱动架构

使用模型完成软件的分析、设计、构建、部署、维护等各开发活动。MDA起源于分离系统规约和平台实线的思想。

MDA的主要目标：Portability（可移植性）、Interoperability（互通性）、Reusability（可重用性）。

MDA的3中核心模型：

1. 平台独立模型（PIM）：具有高抽象层次、独立于任何实现技术的模型。
2. 平台相关模型（PSM）：为某种特定实线技术量身定做，让你用这种技术中可用的实线。
3. 代码Code：用源代码对系统的描述（规约）。每个PSM对象被变成代码。

六、ADL架构描述语言

ADL是这样一种形式化语言，他在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于地城语义的工具体系结构的表示、分析、演化、设计过程等提供支持。

ADL的三个基本元素：

1. 构建：计算或数据存储单元。
2. 连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的原则。
3. 架构配置：描述体系结构的构件于连接件的连接图。

ADL主要的架构描述语言：
Aesop、MetaH、C2、Rapide、SADL、Unicon、Wright。

七、DSSA特定领域架构

以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成。

1.活动阶段

（1）领域分析：主要目标是获得领域模型。即通过分析领域中系统的需求（领域需求），确定哪些需求是被领域中的系统广泛共享的，从而建立领域模型。

（2）领域设计：这个阶段的目标是获得 DSSA，它是一个能够适应领域多个系统的需求的一个高层次的设计。由于领域模型中的领域需求具有一定的变化性，DSSA 也要相应地具有变化性，它可以通过表示多选一的、可选的解决方案等来做到这一点。

（3）领域实现：主要目标是依据领域模型和 DSSA 开发与组织可复用信息。这些复用信息可以是从现有系统中提取得到的，也可能通过新的开发得到。这个阶段可以看作复用基础设施的实现阶段。

2. 参与人员

领域专家: 主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品。

领域分析人员: 主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型。

领域设计人员: 主要任务包括控制整个软件设计过程，根据领域模型和现有的系统开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。

领域实现人员: 主要任务包括根据领域模型和DSSA，或者从头开发可重用构件或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立 DSSA 与可重用构件间的联系。

3. DSSA系统模型