一、前言

笔记目录大纲请查阅：【软考速通笔记】系统架构设计师——导读

二、基础知识

2.1 介绍

面向服务的体系结构（Service-Oriented Architecture，SOA）。

从软件的基本原理定义，可以认为SOA是一个组件模型，它将引用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义，它应该独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种各样的系统中的服务可以一种统一和通用的方式进行交互。

2.2 作用

SOA的主要作用：打破信息孤岛，把应用和资源转换成服务。以及把这些服务变成标准的服务，形成资源的共享。

三、参考架构

企业集成架构可以划分为6大类

• 业务逻辑服务（Business Logic Sevice）：负责处理企业的核心业务逻辑，是SOA架构中的核心部分。
• 控制服务（Control Service）：包括实现人、流程、信息集成的服务，以及执行这些集成逻辑的能力。
• 连接服务（Connectivity Service）：通过提供企业服务总线，实现分布在各个架构元素中的服务间的连接性。。
• 业务创新和优化服务（Business Innovation and Optimization Service）：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的事情。
• 开发服务（Development Service）：贯彻这个软件开发生命周期的开发平台，从需求分析到建模、设计、开发、测试和维护等全方面的工具支持。
• IT服务管理（IT Service Management）：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。

四、主要协议

• UDDI协议（Universal Description, Discovery, and Integration）：用于描述、发现和集成Web服务的目录协议。提供了一个平台，企业可以发布和发现服务信息，包括服务的技术细节、接口和绑定信息。
• Web服务描述语言（WSDL - Web Services Description Language）：WSDL是一种XML格式的标准语言，用于描述Web服务。3个基本属性：
  • 服务做些什么——服务所提供的操作（方法）？
  • 如何访问服务——服务交互的数据格式和必要协议？
  • 服务位于何处——协议相关的地址，如URL？
• SOAP协议（Simple Object Access Protocol）：在分散式或分布式环境中交换信息的简单协议，基于XML的协议。
• REST规范（Representational State Transfer）：即RESTful，使用HTTP请求来获取、修改和传输数据。它通常使用JSON或XML格式的数据交换，并且具有无状态、可缓存和统一接口的特点。

五、设计原则

• 无状态：服务应该是无状态的，即不依赖于其他服务的上下文和状态。
• 单一实例：服务应该具有单一实例，避免多个实例之间的冲突和不一致。
• 明确定义的接口：服务接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。
• 自包含和模块化：独立进行部署、版本控制、自我管理和恢复。
• 粗粒度：过细的服务粒度会增加系统的复杂性和管理成本；而过粗的服务粒度则会影响系统的灵活性和可重用性。因此，需要根据实际需求合理控制服务粒度
• 服务之间松耦合：服务之间应该保持松耦合的关系，降低服务之间的依赖性和相互影响。
• 重用能力：服务应该具有重用能力，通过服务注册和发现机制实现服务的共享和复用。
• 互操作性、兼容和策略声明：服务应该通过策略声明来确保服务的安全性和可靠性

六、设计模式

6.1 服务注册模式

通过服务注册中心来管理和维护服务的信息，包括服务的名称、地址、接口等。服务消费者可以通过服务注册中心来查找和调用所需的服务。

6.2 企业服务总线模式

ESB是一种用于在不同服务之间传输和转换消息的软件架构模式。它提供了一组标准化的服务和接口，用于在不同服务之间进行通信和协作。

6.3 微服务模式

微服务是一种将应用程序构建为一组小型、自治的服务的方法。每个服务都运行在独立的进程中，并使用轻量级通信机制（如HTTP或REST API）进行通信。微服务架构具有高度的灵活性和可扩展性，能够快速地响应市场变化。
微服务模式特点：

• 复杂应用解耦：将大应用拆成小服务，每个服务专注一个功能。
• 独立：独立开发、测试和部署。
• 技术选型灵活：各服务可根据需要选择技术，不受整体架构限制。
• 容错：服务间独立通信，单个服务故障不影响整体。
• 松耦合，易扩展：服务间松耦合，添加或修改服务容易，适应性强。

6.4 微服务架构模式方案

在微服务架构中，可以采用多种模式方案来实现服务的构建和部署。

• 聚合器微服务设计模式：可以将多个服务组合成一个业务流程；
• 链式微服务设计模式：可以将多个服务按照顺序连接起来形成一个服务链；
• 数据共享微服务设计模式：可以在多个服务之间共享数据，共用一个数据库；
• 异步消息传递微服务设计模式：可以通过消息队列实现服务的异步通信和协作。

七、注意事项

• 服务粒度：服务粒度的选择对于SOA架构的成功至关重要。过细的服务粒度会增加系统的复杂性和管理成本；而过粗的服务粒度则会影响系统的灵活性和可重用性。因此，需要根据实际需求合理控制服务粒度。
• 无状态服务的设计：服务都是独立的、自包含的请求，在实现这些服务时不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态。
• 服务性能和可靠性：SOA架构需要通过网络进行服务调用，可能会带来额外的延迟和失败风险。因此，需要关注服务的性能和可靠性问题，确保服务的稳定性和可用性。
• 服务版本控制和演化：随着系统的演化和变化，服务的接口和实现可能会发生变化。因此，需要建立有效的版本控制和管理机制来管理服务的版本和演化过程。
• 安全和隐私：在SOA架构中，服务之间的通信和数据交换需要保证安全和隐私。因此，需要采用适当的安全措施来保护服务的安全性和隐私性。
• 标准化和规范化：为了确保不同服务之间的互操作性和兼容性，需要制定统一的标准和规范来指导服务的设计、开发和部署过程。

---

若觉得文章对你有帮助，随手『点赞』、『收藏』、『关注』，也是对我的支持。