服务与API管理：从传统到现代的演进

# 服务与 API 管理：从传统到现代的演进 ## 1. 服务编排与类型 ### 1.1 服务编排 服务编排是一种将不同形式的编排进行组合使用的方式。其中，服务编排模式模糊了服务提供者和消费者的角色，它将流程交互和业务逻辑在独立的参与方之间进行全局分布，以实现特定的业务目标。在服务编排中，决策逻辑是分布式的，每个服务自主观察环境并行动，没有像业务流程管理（BPM）那样的集中编排器，各方对其他方的流程没有完全控制权，各自负责整体流程中的一部分。请求在不同的服务提供者和消费者之间以类似乒乓球的方式来回传递，控制服务间交互的逻辑位于中央平台之外，服务自行决定下一步调用谁以及调用顺序。 ### 1.2 服务类型 服务可分为公共服务和私有服务： - **公共服务**：有时也称为业务服务，提供特定的业务功能，有助于解决特定的业务问题。它们通常将数据或逻辑进行分组，以对业务有意义的方式呈现。业务服务往往较为抽象，是特定业务功能的权威，并且可以跨应用边界运行。 - **私有服务**：也叫技术服务，不一定代表业务功能，用于内部逻辑，提供技术数据或基础设施功能，例如直接暴露数据库表。私有服务可以作为公共服务的输入，通常会被包装到另一个最终提供业务功能的服务中。 此外，还有基础设施服务或平台服务，它们将基础设施问题从各个领域中抽象出来，通常在组织内标准化，涉及适用于所有领域的功能，如身份验证、授权、监控、日志记录、调试或审计等。 ## 2. 服务模型与规范数据模型 ### 2.1 服务模型 服务模型用于描述服务接口的样子，以及数据及其实体、关系和属性的建模方式。根据其详细程度，还可能包括定义、与其他服务的依赖关系、版本号、语法、协议以及应用所有者、生产状态等信息。其目标是提供便于使用和集成服务的信息，通常与平台无关，不试图描述系统。服务模型在不同范围使用，存在不同格式，有些仅存在于文档中描述最常用的上下文，有些以代码形式存在于工具中，描述数据及其所有属性和协议。 ### 2.2 规范数据模型 规范数据模型旨在以标准和统一的方式定义服务和语言。与服务模型更贴近应用不同，规范模型用于对齐和标准化各种服务模型。有些人希望使用全局模式对所有服务进行统一，这使得规范模型往往庞大而复杂。 ## 3. 与企业数据仓库架构的相似性 传统面向服务架构（SOA）的实现由于企业服务总线（ESB）、聚合、服务分层和中央规范数据模型的组合，变得比必要的更复杂，面临着与企业数据仓库架构相似的挑战： | 相似点 | 描述 | | --- | --- | | 规范模型规模 | 许多组织试图使用单一的企业规范模型来描述所有服务，这需要不同团队和参与方之间的跨协调。服务最终往往有大量可选属性，导致接口模型过于通用，无法明确服务的具体功能，这与企业数据仓库面临的问题类似。 | | ESB 作为遗留中间件的包装器 | 大型遗留中间件平台和 ESB 中常见服务的分层和聚合。一些企业用更现代的技术封装这些遗留中间件系统，虽然抽象了复杂性，但增加了新的层次，可能导致小的更改引发连锁反应，并且难以确定数据来源和服务调用的责任。 | | ESB 管理应用状态 | ESB 成为多个应用的状态（数据）存储，用于编排长时间运行的业务流程或持久化应用的状态，这存在紧密耦合的风险。如果 ESB 出现故障，状态丢失，所有流程可能失去实际状态；应用更改时，也需要仔细的跨协调。 | ## 4. 现代 API 管理视角 ### 4.1 联邦责任模型 由于 ESB 集成平台使 SOA 过于复杂，企业实施的整体式架构阻碍了创新和团队敏捷性。随着微服务的兴起，应用和设计的模块化发生了变化，现代数据库和应用支持 RESTful API，因此需要新的 API 架构。基于这些趋势，应采用联邦责任模型，将构建和暴露服务的责任交还给底层领域。在这个模型中，业务逻辑、执行流程、数据持久化和上下文验证的责任也回归到各个领域，应避免使用 ESB 作为集中集成平台，聚合和编排应仅在领域边界内进行。API 设计应遵循与数据产品创建相同的用户友好原则，使用领域语言进行开发。 API 管理的额外原则如下： 1. 使用 REST 资源模型暴露业务功能或数据，而不是复杂系统，这需要深入理解业务概念及其属性，正确命名关系，设计相应的模式，确保身份和唯一性等。 2. 尽可能靠近数据进行优化，避免在 API 层进行大量编排。例如，如果应用和 API 部署在本地，可以使用自托管的 API 网关实例。 3. 将领域逻辑保留在领域内。 4. 为消费者构建具有适当粒度的服务。 5. 简化并使用现代社区标准。 6. 仅在领域边界（有界上下文）内允许服务编排（将多个 API 端点组合为一个）。 7. 一致使用领域标识符，以便领域能够识别资源之间的互连。 ### 4.2 面向资源的架构 在软件工程中，有一种称为面向资源的架构（ROA）的模式，它是 RESTful 架构的一组特定指南。数据被建模为同类主题区域或资源的集合，逻辑上相关的内容被分组到一个集合或资源中，每个资源可以使用统一资源标识符（URI）进行标识。例如，“客户”资源用于返回与客户相关的所有信息，包括姓名、地址和联系信息等。这种模式下的数据资源以名词为导向，应具有自发现和自解释性，而 SOA 通常以动词为导向。遵循这些指南有助于