API 在微服务架构中的作用

API 在微服务架构中的作用

本文译自：The Role of APIs in a Microservices Architecture

了解 API 如何帮助将秩序感带入微服务架构的混乱本质。

本文在新的 DZone API 管理指南：真实世界设计的比较视图中进行了介绍。获取您的免费副本，以获取更多有见地的文章、行业统计数据等！

为了满足不断增长的业务创新需求，组织正在稳步转向在其企业软件中采用微服务架构。虽然微服务架构为您提供了大规模开发、维护和增强软件所需的敏捷性，但它并非免费提供。在应用这些架构模式和实践时，有许多挑战和障碍需要克服。其中一个挑战是了解 API 和 API 管理在微服务体系结构中的重要性。为了更好地理解这个问题，让我们看一下零售应用程序的微服务体系结构。

图 1 — 零售应用程序的微服务体系结构。

在这里，我们有单独的微服务用于浏览产品目录、下订单、更新库存和将物品运送给客户等操作。乍一看，您会意识到在操作中的组件数量以及这些组件之间的集成以促进业务需求方面存在很多混乱。此体系结构中的一些关键问题是：

1. 客户端应用程序要处理的微服务太多。这些微服务接口之间的不一致性、它们的原始性和不同的身份验证方案将使这些微服务的使用变得不平凡。

2. 由于不存在实施点，对速率限制和访问控制等因素的策略实施成为一项挑战。

3. 业务价值报告变得更加困难，因为

4. 由于微服务的持续部署性质，微服务间点对点通信成为一项挑战。

微服务对使用者应用程序的托管公开

统一曝光，全面性

图 1 中的每个微服务都可以由独立的工程团队开发。他们可以自由选择使用自己的编程语言，使用自己的标准，并在方便的时候发布。在这种情况下，每个微服务很可能具有不同的接口标准和模式。这种缺乏统一性使其消费者更难有效地使用这些服务，从而降低了开发人员的效率。通过托管基础结构（如 API 管理解决方案）公开它们为组织提供了确保为使用者应用程序公开的 API 标准化、文档齐全且可在开发人员门户上发现的方法。

API 立面

在许多情况下，微服务的原始性不应向其使用者公开。例如，对产品目录执行读取的操作和执行更新的操作可以开发为单独的微服务，以满足不同的可伸缩性需求。但是，这些操作的使用者希望在单个 API 中看到它们，因为它们对单个实体（产品）执行操作。这使得必须有一个由两个资源（函数）组成的单个 API，以公开两个微服务。

安全

上述每个微服务可能需要不同级别的身份验证和授权，例如 OAuth2.0、证书、mTLS（相互传输级别安全性）等。这些可能适用于消费者应用程序和微服务之间的通信通道，也可能适用于微服务间通信通道。这使得应用程序更难使用您的微服务，也使微服务间通信编程变得更加困难。这个问题可以通过使用API网关来解决，该网关能够向其消费者公开统一的安全机制，并将其转换为任何必要的内部安全协议。例如，在使用 mTLS 与内部微服务通信时，为使用者应用程序公开基于 OAuth 2.0 的安全性。

微网关模式

如上一节所述，在 API 管理解决方案中使用 API 网关有助于我们解决与向使用者应用程序公开微服务相关的大多数问题。这里要记住的一个关键因素是，组织采用微服务的主要原因是它们在开发、测试、部署和扩展应用程序方面提供的敏捷性。随着企业不断创新，他们最终将拥有更多的微服务和它们之间的更多集成。这只会导致我们看到更多的 API，这引发了对我们的 API 网关架构的一个问题。就像微服务一样，这种情况要求我们的 API 网关在开发、测试、部署和可扩展性方面具有敏捷性。这种情况不是将所有 API 的运行时托管在单个整体网关上，而是要求能够在单个微网关上部署每个单独的 API 或较小的 API 子集。

图 2 — 受微网关影响的微服务架构。

为了满足这些标准，微网关的一些关键特征如下所述。

专为扩展而设计

轻松扩展以满足不断增长的需求的能力是微网关的一个至关重要的因素。因此，重要的是，微网关在运行时不会连接到任何其他系统，以便它可以毫无阻力地扩展。

CI/CD 就绪情况

微网关的创建、部署和降速应尽可能简单。这些过程应该完全自动化，这意味着它们应该包含类似 CLI 的工具或管理 API，以便这些过程可以在构建或部署阶段由自动化工具（如 Jenkins）执行。

容器就绪

当今许多遵循微服务标准的软件都部署在容器和容器编排系统上，以实现它们提供的各种优势。因此，成为此软件提供的服务入口点的网关应具有使其易于在容器上部署的特征。其中一些是

• 小分发大小 （100 MB）

• 低资源消耗和快速启动（256 MB，1 秒启动）

• 可通过环境变量进行配置

• 构建生成容器映像和部署项目的流程，以及自动执行它们的能力

不变性

微服务架构需要可扩展性和自动恢复。这使得软件的可预测性非常重要，因此我们保证部署和扩展我们测试过的确切工件。给定的微网关运行时需要使用其 API 和策略构建一次，以便我们保证其副本相同。

结论

随着组织稳步采用微服务以及企业不断创新，我们正在展望一个未来，即组织内部使用和外部公开的 API 数量将迅速增加。在这种情况下，拥有可扩展的机制来开发、部署和管理这些 API 非常重要。这些 API 的管理将远远超过对 API 代理的管理。能够组合集成/复合微服务，将它们公开为微网关，并通过API管理系统有效地管理它们，将对组织的敏捷性和竞争力发挥关键作用。为这种增长做好准备绝对应该在您的计划中！

本文在新的 DZone API 管理指南：真实世界设计的比较视图中进行了介绍。获取您的免费副本，以获取更多有见地的文章、行业统计数据等！