共计 2066 个字符，预计需要花费 6 分钟才能阅读完成。
翻译 | 李守超
原文 | https://www.getambassador.io/…
导读
企业 API 网关是一个很成熟的工具，市场上的相关成熟产品也很多。但是，在对轻量级、快速响应要求很高的微服务架构下，传统企业级 API 网关作为企业的公共基础设施，又显得有些重了。在本文中，我们将讨论业务目标（生产率与管理）的不同是如何要求我们实现一种完全不同的 API 网关。
在过去十年中，企业组织一直致力于通过定义良好的 API 公开内部的业务系统。如何将数百或数千个 API 安全地暴露给最终用户（内部和外部），巨大的挑战促使了 API 网关的出现。在对外发布服务时，传统企业级 API 网关作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作。除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做。随着时间的推移，API 网关逐渐成为核心且重要的基础架构之一。
随着对云原生和微服务的概念的不断推广和使用，我们开始遇到一些新的问题。区别于传统企业级 API 网关，业界提出了旨在加速独立服务团队的开发工作流程的微服务 API 网关。微服务 API 网关为团队提供了独立发布，监控和更新微服务的所有功能，关注于加速开发测试部署的工作流程。
微服务组织
在微服务组织中，小型开发团队彼此独立工作，以快速向客户提供功能。为了使每个服务团队独立工作，通过高效的工作流程，服务团队需要能够：
发布服务，以便其他人可以使用该服务
监控服务，观察它的运行情况
测试并更新服务，以便可以继续改进服务
团队需要做到所有这些而不需要其他操作或平台团队的帮助，因为只要服务团队需要另一个团队，他们就不是所谓的独立工作，进而导致瓶颈的出现。
对于服务发布，微服务 API 网关为消费者提供静态地址，并动态地将请求路由到适当的服务地址，这里的服务地址一般指由服务团队开发和维护的一个或多个服务的多个实例。此外，为安全性提供身份验证和 TLS 终止是向其他使用者公开服务的典型考虑因素。
了解服务的最终用户体验对于改进服务至关重要。例如，软件更新可能会无意中影响某些请求的延迟。微服务 API 网关可以很好地收集最终用户流量的关键可观察性的指标，因为它可以将流量路由到终端服务。
微服务 API 网关还支持将用户请求动态路由到不同的服务版本以进行金丝雀测试。通过将一小部分最终用户请求路由到新版本的服务，服务团队可以安全地测试本次更新对一小部分用户产生的影响。
微服务 API 网关与企业 API 网关
乍一看，上述用例可以通过以企业为中心的 API 网关来实现。虽然可以实现，但企业 API 网关和微服务 API 网关的实际重点有些不同：
自服务发布
团队需要能够向客户发布新服务，而无需运营或 API 管理团队。这种部署和发布自助服务的能力使团队能够保持较高的发布速度和频率。虽然传统的企业 API 网关可以提供用于发布新服务的简单机制（例如，REST API），但实际上只限于负责网关运维的团队使用。限制单个团队发布 API，主要原因是为了安全考虑：错误的 API 调用可能会对生产环境造成灾难性影响。微服务 API 网关允许服务团队轻松和安全地发布新的服务，是因为在微服务场景下，我们默认服务团队对微服务有清楚的了解并承担全部的责任。一旦有问题出现可以快速解决。而且微服务网关可以提供可配置的监控以方便发现问题，并提供调试钩子，例如检查流量或流量转移 / 复制。
监控和速率限制
API 的常见商业模式是计量，其中根据 API 使用情况向消费者收取不同的费用。传统的企业 API 网关在这一点上一般做的比较好：它们提供了监控每个客户端 API 使用的功能，并且具备当客户端超出配额时限制其使用的能力。
微服务网关也需要监控和速率限制，但原因有所不同。监控用户可见的指标（如吞吐量，延迟和可用性）非常重要，它可以确保微服务的更新不会影响到最终用户。稳定可靠的监控指标对于实现快速增量更新至关重要。速率限制则用于提高服务的整体弹性。当服务未按预期响应时，API 网关可以限制传入请求以允许服务恢复并防止级联故障，也即微服务设计中经常使用的熔断、降级等模式。
测试和更新
微服务应用程序具有多个服务，每个服务都是独立更新的。上生产环境之前的自动化测试是必要的，但对于微服务来说还是不够。金丝雀部署将一小部分生产流量路由到新服务版本，是帮助测试更新的重要工具。通过将新服务版本限制为一小部分用户，即便出现问题，服务故障的影响是有限的。当测试稳定以后逐步替换旧版本，最终实现所有服务实例的版本更新。
在传统的企业 API 网关中，路由用于隔离或组合 / 聚合变化的 API 版本。上生产环境前的自动化测试，上生产环境后的手动验证和检查，二者都是必须的。
总结
传统的企业 API 网关旨在解决 API 管理的挑战。虽然它们似乎可以解决微服务架构下的一些挑战，但实际情况是微服务工作流提出了一组不同的需求。将微服务 API 网关集成到微服务的开发工作流程中，使服务团队能够快速，安全地自行发布，监控和更新其服务。这将使我们能够以更快的速度发布软件，并且具有前所未有的可靠性。
本文由博云研究院翻译发表，转载请注明出处。
