软考系统分析师软件架构风格(下)

面向服务的架构风格

面向服务的架构风格（SOA）是通过标准化服务的松耦合组合来构建分布式系统的设计范式。

（1）核心特征

• 将应用程序拆分成一系列独立的服务，每个服务都通过标准化接口与其他服务通信。

• 服务之间相互协作，实现业务功能。

• 每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作（通常是HTTP/JSON）。

（2）优点

• 松耦合：服务之间依赖关系弱，可独立开发和部署。

• 可伸缩性：可根据需求对特定服务进行水平扩展。

• 灵活性：服务可被多种应用复用，降低了重复开发成本。

• 技术异构性：不同服务可采用不同的技术栈实现。

（3）典型应用场景

• 企业应用集成：解决异构系统之间的集成问题。

• 跨部门业务流程：如订单管理、客户关系管理等需要多系统协作的业务。

• 微服务架构：SOA的进一步细化和演进。

协同工作

在传统的SOAP/Web Service模式下，这四个组件的协作流程清晰地展示了“定义-发布-发现-调用”的完整生命周期：

1. 定义 (WSDL)：首先，服务提供者使用WSDL文档来“定义”服务的接口规范。

2. 发布 (UDDI)：接着，将这个WSDL文档“发布”到UDDI注册中心，相当于在黄页上登记。

3. 发现 (UDDI)：服务请求者需要某个功能时，会查询UDDI注册中心来“发现”所需的服务，并获取其WSDL描述。

4. 调用 (SOAP)：最后，请求者根据WSDL的描述，构建一个符合SOAP协议的消息，来调用远程服务。

REST与SOA的关系

SOA是一种宏观架构思想，而REST是实现这种思想的流行技术路线，尤其在Web服务领域。RESTful架构风格正好契合了SOA对于服务松耦合、可重用的要求，并以其简洁性成为现代Web服务（特别是面向移动端和前端应用的API）的首选。

SOA三大实现方法

1. Web Service：SOA的主流技术实现

Web Service是基于XML和HTTP等标准协议，通过网络为其他应用提供功能的具体实现技术。它的体系结构围绕三个角色和三个核心操作展开：

• 三大角色：

• 服务提供者 (Service Provider)：服务的拥有者，负责将服务发布到注册中心。

• 服务请求者 (Service Requester)：服务的调用者，通过在注册中心查找服务来调用它。

• 服务注册中心 (Service Registry)：服务发布和查找的“黄页”，通常基于UDDI协议。

  

• 核心操作：

• 发布 (Publish)：服务提供者将服务描述信息注册到注册中心。

• 查找 (Find)：服务请求者在注册中心检索所需的服务。

• 绑定 (Bind)：服务请求者根据查找到的信息，直接调用服务提供者。

• 关键技术：

• WSDL：Web Service 描述语言，提供服务接口、位置等信息的规范，是“服务说明书”。

• UDDI：统一描述、发现和集成协议，提供Web Service信息的注册和发现规范。

• SOAP：简单对象访问协议，定义服务间交换信息的XML消息格式。

• REST：表述性状态转移，基于HTTP协议的轻量级架构风格。

• 优点：基于开放标准，实现了跨平台、跨语言的互操作性，松散耦合，易集成。

• 缺点：SOAP协议传输XML消息，效率较低；在复杂业务场景下，服务治理和管理可能较为复杂。

2. 服务注册表：SOA的服务治理中心

服务注册表是SOA架构中用于服务治理的核心组件，是一个集中存储服务元数据的数据库或目录。

• 核心功能：

• 服务注册与发布：服务提供者在此登记服务信息，包括接口、位置等。

• 服务查找与定位：服务请求者可以按需查找服务，获取调用所需的信息。

• 服务绑定：请求者获取信息后，与服务提供者建立动态连接，实现调用。

• SOA治理：注册中心是实施SOA治理的关键，用于管理服务版本、策略、元数据，确保服务符合企业标准。

• 优点：实现服务消费者和提供者的解耦，便于服务的管理、治理和复用。

• 缺点：可能成为系统的单点故障和性能瓶颈；需要额外的治理和维护成本。

3. 企业服务总线 (ESB)：SOA的通信骨架

ESB是SOA架构的基础通信平台，是一种中间件，作为“总线”连接所有服务，负责消息的路由、转换和传递。

• 核心功能：

• 消息路由：根据规则将消息从发送方路由至接收方，支持多种消息模式。

• 协议转换：在不同协议（如HTTP、JMS）之间转换，实现异构系统的互操作。

• 消息转换：转换不同格式的消息，确保各服务能“听懂”彼此。

• 服务编排：组合多个服务，形成新的业务流程。

• 服务质量保障：提供安全、负载均衡、可靠消息传递等能力。

• 优点：降低服务间的耦合度，支持异构系统集成，提供了高扩展性和灵活性。

• 缺点：ESB自身可能成为性能瓶颈；增加了架构的复杂度，需额外的设计、部署和维护成本。

SOA服务设计原则

1. 标准化服务合约 (Standardized Service Contract)

• 定义：服务通过一个正式、标准化的“服务合约”来描述其目的、功能、约束和使用方式，这个合约通常就是WSDL文档。

• 目的：为服务的“消费者”提供一个清晰、标准的技术蓝图，实现技术与平台的解耦。

• 实践要点：服务消费者完全依赖契约，不关心内部实现细节。服务间的交互只能以合约为基础。

• 反例：接口参数命名不规范、缺乏正式文档、合约频繁变更，导致依赖方频繁修改代码。

2. 服务松散耦合 (Service Loose Coupling)

• 定义：服务与其消费者，以及服务与服务之间，仅保持最少的依赖关系。

• 目的：使服务可以独立演进和部署，某一服务的变更不会“牵一发而动全身”。

• 实践要点：服务间通过标准契约交互，不直接共享数据结构或实现逻辑。

• 反例：服务A的代码中直接硬编码服务B的地址，或者服务A直接读取服务B的私有数据库。

3. 服务抽象 (Service Abstraction)

• 定义：服务只通过其合约向外界暴露必要的信息，其内部的实现逻辑、技术平台等细节是完全隐藏的。

• 目的：遵循“信息隐藏”原则，降低服务的复杂度，保护其内部不受外部变更影响。

• 实践要点：外部调用者无需关心服务是用Java还是C#写的，只需知道它能做什么。

4. 服务可复用性 (Service Reusability)

• 定义：服务应被设计为通用的业务逻辑单元，具备在多种不同场景下被重用的潜力，无论当前是否有明确的复用需求。

• 目的：最大化软件资产的价值，避免重复开发，是SOA提升效率的核心。

• 实践要点：设计时应避免将服务与某个特定的业务流程或用户界面绑定。

• 反例：一个支付服务被设计成只能处理“订单支付”流程，无法被独立用于“充值”或“退款”等其他场景。

5. 服务自治 (Service Autonomy)

• 定义：每个服务都是一个独立的实体，拥有对自身运行环境、资源和逻辑的完全控制权。

• 目的：保证服务的可靠性和独立性，一个服务的故障不会直接导致其他服务不可用。

• 实践要点：服务能够独立进行开发、测试、部署、版本管理和运行监控，不依赖于其他服务的存在。

• 反例：多个服务共享同一个核心数据库，导致数据库表结构变更会影响所有服务。

6. 服务无状态性 (Service Statelessness)

• 定义：服务在设计上应尽可能“健忘”，即它在处理完一个请求后，不会保留该请求的会话状态。

• 目的：保障服务的可伸缩性（任意实例都能处理任何请求）和高可用性（实例故障可由其他实例无缝接管）。

• 实践要点：将需要保持的状态（如用户登录信息）交由服务消费者维护，并随每次请求一起传递（如使用JWT令牌）。

• 反例：服务将用户信息缓存在自身内存中，这导致同一用户的请求必须由同一服务实例处理，无法灵活扩展。

7. 服务可发现性 (Service Discoverability)

• 定义：服务应能被潜在的消费者轻松地发现和理解，通常通过服务注册中心（如UDDI）来实现。

• 目的：实现服务的动态查找与绑定，避免地址硬编码，构建更灵活、动态的系统。

• 实践要点：服务的元数据（描述、位置、契约）被发布到中心化的目录中，便于检索。

• 反例：服务的访问地址被硬编码在调用方的配置文件里，当服务变更时，所有调用方都需要同步修改。

8. 服务可组合性 (Service Composability)

• 定义：服务可以被编排和组合，形成更粗粒度、更复杂的业务服务或流程，以实现更大的业务目标。

• 目的：实现业务的敏捷性，通过对已有服务的灵活组合，快速响应新的业务需求。

• 实践要点：在设计服务时，就应考虑其作为更大流程中一个“组件”的潜力。

补充以下原则：第二版教程中内容

• 粗粒度 (Coarse-Grained)：服务接口应设计为粗粒度，一次调用能完成一个完整的业务功能，避免多次远程调用的开销。

• 明确定义的接口 (Well-Defined Interface)：强调服务接口的清晰性和稳定性，与“标准化服务合约”一脉相承。

• 互操作性 (Interoperability)：强调SOA的跨平台、跨语言特性，是服务价值的基础。

• 自包含和模块化 (Self-Contained & Modular)：服务应是一个独立、完整的逻辑单元，边界清晰。