使用API网关的经验之谈

前段时间，我在研究一个项目，为我们产品的云服务实施API网关。该项目背后的主要动机是为所有的外部流量提供一个统一的入口，并保护后端服务，当然也有其他原因。我假设你在浏览本文时已经对API网关有一定的了解，如果没有的话你应该在阅读本文之前，先在这两个链接里了解一下 1、 2。

找到一个符合自己需求的API网关有太多的选择，如果你亲力亲为，最终可能会出现心理崩溃。就像目前业界盛行的许多其他软件栈一样，即使是API网关，也有各种各样的选择和风格。说实话，如果不深入研究每一种可选项，并根据你的具体要求进行匹配，做出这样的决定是相当困难的。本文是我的一个小小的尝试，旨在使这个任务变得简单一些，并在最后提供一个流程图，希望你能够做出决定。

当我们开始搜索时，我们开始根据我们的研究评估了一些选项。为此，我们主要依靠网上已存在的各种比较，然后我们根据它们目前的受欢迎程度以及它们所提供的功能集，将其中的几个入围。

免责声明：本文不提供任何形式的API网关性能比较，尽管这也是我们选择的一个标准。我并不声称这里所讨论的实现是唯一的选择，但这些实现是在撰写本文时根据我们的产品需求而做出的最受欢迎的选择。

需求列表

首先，我们快速列出我们对API网关解决方案的最低要求。请注意，这并不是一个详尽的清单，也不是一些可能与你正在寻找的解决方案相匹配的东西，但它应该涵盖API网关适用的大部分场景。

• 
  反向代理：这是大多数项目采用网关类解决方案的最重要原因。任何一个成熟的项目，都会出于安全的考虑，避免暴露其后端URL，并将后端服务的复杂性抽象到客户端应用中。这也为所有访问后端API的客户提供了一个单一的入口。
• 
  负载均衡：网关可以将一个传入的URL路由到多个后端目的地。在微服务架构中，当你想扩展你的应用程序以实现高可用性时，或者如果你运行某种集群服务器设置时，这通常都很有用。
• 
  认证和授权：网关应该能够成功地进行认证并只允许受信任的客户访问API，同时能够使用类似RBAC的东西提供某种授权层。
• 
  IP列表：允许或阻止某些IP地址通过。为你的生态系统提供额外的安全层，当你发现一组恶意地址试图通过使用DDoS类攻击使你的应用程序瘫痪时非常有用。
• 
  分析：提供一种方法来记录与API调用相关的使用情况和其他有用的指标。应该能够分解每个客户的API使用量，以实现尽可能盈利。
• 
  速率限制：能够对API调用进行流控，例如，你只想允许所有使用者每分钟调用10000次，或者允许让某一特定使用者每月调用1000次。
• 
  转换：在进一步转发之前，能够转换请求和响应（包括头部和主体）。
• 
  版本化：可同时提供使用不同版本的API，或以金丝雀版本或蓝/绿部署的形式缓慢推出API。
• 
  断路器：适用于微服务架构模式，以避免服务中断。
• 
  支持WebSocket：许多动态和实时功能可以通过使用WebSocket来解决，为终端客户提供WebSocket接口可以真正减少频繁数据传输的多个HTTP调用的开销。
• 
  支持gRPC：谷歌的gRPC承诺通过利用HTTP/2进一步降低负载，可以有效地用于服务之间的相互通信。我建议这是你一定要添加到你的需求列表中的东西，以使你的解决方案具有未来性。
• 
  缓存：如果能缓存频繁请求的数据，将进一步减少网络带宽和往返时间的消耗，提高性能。
• 
  文档：如果你计划将你的API暴露给组织以外的开发人员，那么你必须考虑使用API文档，如Swagger或OpenAPI。

API网关和服务网格

在进行具体实现上的比较之前，我还必须谈谈你在寻找网关时可能会遇到的另一种模式，即服务网格。一开始你可能会搞不清API网关和服务网格的区别，以及它们各自的目的，所以在我们继续之前，我将详细介绍一下它们。

API网关应用于OSI模型的第7层，也可以说是管理来自外部网络的流量（有时也称为南/北流量），而服务网格则应用于OSI模型的第4层，或管理服务间的通信（有时也称为东/西流量）。API网关的功能有反向代理、负载均衡、认证和授权、IP列表、速率限制等。

另一方面，服务网格的工作方式类似于代理或侧车模式，它解除了对服务的通信责任的耦合，并处理诸如断路器、超时、重试、服务发现等其他问题。在本文发表时，Istio是一个非常知名的服务网格的实现方式。

你一定注意到了，我在需求列表中也包含了服务网格所提供的一些功能。今天有不少API网关的实现可以同时工作在第4层和第7层，并且也能处理服务网格的需求。如果我们能得到一个实现，它也能处理一些服务网格的需求，即使它不是必须的，那就更好了。这篇 文章详细列举了两者之间的差异。

比较

我将对以下API网关进行对比

• NGINX
• Kong
• Tyk
• Ambassador
• AWS API gateway

Nginx

Nginx已经成为七层代理、负载均衡和为后端应用创建单一入口的最佳选择之一。它已经在许多不同的生产环境中被使用和测试，以很低的内存占用率和大量降低企业成本的优势取代了许多现有的硬件负载平衡器。很多CDN使用Nginx作为他们在边缘位置缓存数据的引擎。

使用Nginx作为网关的最大优势是它能够提供从简单到复杂的功能，允许你在发展过程中只挑选所需的功能。例如，如果你一开始只需要负载均衡和反向代理，Nginx可以很容易地做到这一点，而且开销很小，随着产品的成熟，你可以最终升级到其他功能。你也可以使用他们的商业产品NGINX Plus来开始一个完整的API网关，即使在它的开源产品上使用其广泛的插件也能实现这一点。

Nginx以其占用内存小、能够满足高性能低延迟而著称。你同时也可得到很多第三方定制的Nginx插件，它可以覆盖广泛的定制场景，当然，如果你被卡在某个地方，你可以随时从庞大的开发者社区中寻求帮助。在使用Nginx的过程中，你可能会遇到的唯一的缺点是配置可能会有点困难，除非你已经动手操作了，否则你将不得不翻阅几页他们的文档，直到你能掌握它。

Kong

Kong是一个基于Nginx和OpenResty的API网关，再加上服务网格，它满足了我们上述的大部分需求。按照提供的docker安装说明安装起来相当简单。

Kong的架构非常简单易懂，由以下几个组件组成：

• 
  Kong基础模块，封装了OpenResty和Nginx，是实际工作的引擎。
• 
  数据库层可选择Cassandra或Postgres来存储所有配置，以便在发生故障时可以轻松检索。
• 
  仪表板用于提供API管理和查看分析的用户界面（这仅是企业产品的一部分，但是Kong有提供REST API用于管理服务、上游API及其消费者）。

Kong有开源版和企业版两种实现模式，因为它本身是由nginx驱动，所以在亚毫秒级的延迟下都能很好地工作。想象一下，使用Nginx来进行网关操作，同时又有REST API和数据库层来轻松管理配置。

Kong提供了多种插件，可以满足从访问控制、安全、缓存到文档等横切关注点的大部分需求。它还可以让你使用Lua语言编写和使用自定义插件。Kong开源版本是一个很好的开始，可以让你熟悉他们的技术栈。虽然它没有配备Web-UI仪表板，但有一些开源的仪表板可以帮助你管理它的配置，如果你对REST相当熟悉，你也可以直接使用他们的管理API。

Kong也可以部署为Kubernetes Ingress，支持gRPC和Websockets代理。Kong的优势在于它的底层引擎是由轻量级而又强大的Nginx+OpenResty引擎组成，它本身就可以作为一个成熟的API网关来构建。你可以把Kong看成是Nginx的自动换挡版本。它的一个可能的缺点是并不是所有的功能都是开箱即用的，而是需要通过手动配置来激活各自的插件，这可能需要初始设置时间和资源，但这对于很多成熟的工程团队来说可能并不是一个很大的障碍。

Tyk

Tyk是另一个开源网关，它承诺有着出色的性能，是用Go编程语言创建的。Tyk提供了多种功能，这些功能是我们需求列表中的一部分乃至更多。Tyk的网页仪表板是同类产品中最好的一个，可以让你控制API配置的几乎所有方面，提供出色的API使用分析。

Tyk拥有丰富的功能集和漂亮的Web-UI仪表板，使其成为具有复杂API管理方案的项目的一个不错的选择。Tyk脱颖而出的是，如果你只打算使用它用于非商业目的，它可以免费使用包括API仪表板，分析，安全，版本，开发者门户，速率限制和其他网关功能，全部都是开箱即用。然而，对于商业用途，你将需要购买他们的商业许可证，其中包括技术支持。

Tyk非常适合那些从第一天就开始寻找这些特性并准备投入使用的项目（即你打算将其用于商业目的），而不是去探索Nginx和Kong等选项，因为这些选项可能需要你的开发人员花费一点时间来获得所有需要的功能。与前两种实现方式相比，Tyk的不足之处在于安装的方便性和成本。Tyk有太多的组件，这使得它不容易在本地安装和管理。它还有云端和混合安装选项，可以减少安装和管理开销，但随之而来的是它的定价，这些将增加了你的项目成本。

Ambassador

Ambassador是一个开源的、建立在Envoy之上的Kubernetes原生微服务网关，它可以作为Kubernetes Ingress和负载均衡器使用，并被构建在Kubernetes环境之上轻松快速地发布和测试微服务。

Ambassador非常轻量级，它所有的状态都存储在Kubernetes中，所以不需要数据库。Ambassador的构建是以开发者为中心的，所以它的所有操作和概念都更以开发者为中心，比如，在Ambassador上添加路由，最推荐的技术是通过在Kubernetes service yamls上添加注释。它的免费版本带有版本管理、gRPC和WebSockets支持、身份验证、速率限制和与Istio集成作为服务网格工作，而OAuth、单点登录、JWT身份验证、访问控制策略和过滤等功能则是其名为Ambassador Pro的付费版本的一部分。

它的优点是能够在Kubernetes环境中以较低的内存占用率和最小的设置配置为大流量提供服务，而它的不足之处是与之前讨论的网关相比，其功能并不丰富，因为它缺少开箱即用的仪表板和与分析的集成，这将需要一些设置。

亚马逊API网关

亚马逊API网关是 AWS 提供的托管 API 管理云产品，让你只需点击几下就能创建、发布和管理 API。你目前可以暴露REST或WebSocket端点，使用Swagger或Open API导入新的API，将URL路由到各种后端，包括AWS EC2、AWS lambda甚至你的本地端点。通过网关来路由百万API的成本是非常低的，而且是可以预测的，因为给定的请求数量有固定的定价模式（尽管你应该小心由于外部数据传输而产生的成本）。

AWS API网关不需要任何设置，因为它是全部托管的，你可以在几个点击中快速创建或路由API，使用SSL确保它们的安全，提供认证和授权，为你的API的外部客户端创建API密钥，管理你的API的版本，甚至如果你想还可以为你生成客户端SDK。AWS API网关在其提供的服务中发挥了巨大的作用，使得在几分钟内设置一个API网关变得非常容易。所以，如果你已经在AWS上，或者打算上AWS，那么你必须认真考虑将这个网关作为你的首选，除非你有一些强制性的功能要求，而它目前还不能满足。明显的缺点是，你可能会被锁定在AWS服务上，这种依赖性可能会让你在以后的时间点上很难完成迁移到其他框架的任务。

矩阵判断

下面以表格的形式对以上五个API网关的功能对比进行总结。
绿色勾选表示功能是其开源版本的一部分，黄色勾选表示其是其付费版本的一部分，红色叉表示暂未实现（可访问各自的门户网站了解当前支持的功能集）

1. 基本功能包括反向代理，负载平衡。
2. Tyk在非商业用途中附带开发者许可，其中包括所有功能，对于生产用途，你需要购买他们的商业许可，它可以作为Saas或混合方式安装。
3. Kong开源版没有附带仪表盘，但有 第三方开源仪表板可让你通过Web-UI管理API和插件。
4. Ambassador可以和Istio一起安装，以覆盖服务网格的角色。

抉择时刻

最后，这里是一个流程图，我特意把它简化了。你应该使用下面的图表和上面的功能对比矩阵一起来缩小你的选择范围。

值得一提的其他实现有

• Apigee
• WSO2
• Zuul

【原文链接】： My experiences with API gateways… 翻译：冯旭松