微服务五种开源API网关实现组件对比_Kubernetes中文社区

微服务架构是当下比较流行的一种架构风格，它是一种以业务功能组织的服务集合，可以持续交付、快速部署、更好的可扩展性和容错能力，而且还使组织更容易去尝试新技术栈。微服务具有几个关键特征：

• 高度可维护和可测试性
• 与其他服务松散耦合
• 且可独立部署
• 能够由一个小团队开发

现在很多公司企业想将自己的单体应用架构迁移到微服务架构，在这个问题上，Martin Fowler提出了3个前提，而Phil Calcado对其进行了扩展如下：

• 快速配置计算资源
• 基本监控
• 快速部署
• 易于配置存储
• 易于访问网关
• 认证、授权
• 标准化的 RPC

今天我们主要讲讲易于访问的网关，也就是 API 网关。

 

为什么需要 API 网关假设我们要使用微服务架构构建一个电商平台，以下可能是一些潜在的服务：

• 购物车服务
• 订单服务
• 商品服务
• 评论服务
• 库存服务

等等，客户端应该怎么访问这些服务呢？原来单体应用的情况我们都知道，都在一个服务器上部署，直接访问IP+端口+服务前缀即可，现在微服务架构下，每个服务都可以独立部署，并且是由不同的开发团队开发的，难道我们要这样访问吗？

理论上每个服务都有端点可以访问，但是客户端就需要记录所有服务的端点，发起5次请求，现在还是5个服务，如果之后扩展多了呢？对客户端来说就是一个灾难，随之带来的就是安全性问题、扩展性问题等，所以这种客户端直接与每个服务交互是不可取的，通常，更好的方式是使用 API 网关。

API 网关是客户端访问服务的统一入口，API 网关封装了后端服务，还提供了一些更高级的功能，例如：身份验证、监控、负载均衡、缓存、多协议支持、限流、熔断等等，API 网关还可以针对不同的客户端定制不同粒度的 API，上面例子中修改架构后如下：

API 网关的优缺点API 网关的好处是显而易见的，封装了应用程序的内部结构，为不同客户端提供不同粒度的 API，同时网关自身也提供了一些高级功能，也减少了客户端与应用程序之间的往返次数，使客户端代码更优雅。同时使用网关也存在一些缺点，增加了一个新的组件，增加了整个应用架构的复杂度，一个通俗的道理，你做的越多你犯错的风险也越高，网关不可用很可能导致整个应用架构崩溃，当然现在有各种各样的方案，能防止网关崩溃，它也可能存在瓶颈风险。使用网关有利有弊，我个人而言，利肯定是大于弊的，我们尽可能的将弊端降到最低。

 

API 网关一些实现使用一个组件时，尤其是这种比较流行的架构，组件肯定存在开源的，我们不必自己去从零开始去实现一个网关，自己开发一个网关的工作量是相当可观的，现在比较流行的开源 API 网关如下所示：KongKong是一个在 Nginx 中运行的Lua应用程序，并且可以通过lua-nginx模块实现，Kong不是用这个模块编译Nginx，而是与 OpenResty 一起发布，OpenResty已经包含了 lua-nginx-module， OpenResty 不是 Nginx 的分支，而是一组扩展其功能的模块。

它的核心是实现数据库抽象，路由和插件管理，插件可以存在于单独的代码库中，并且可以在几行代码中注入到请求生命周期的任何位置。

Traefik

Traefik 是一个现代 HTTP 反向代理和负载均衡器，可以轻松部署微服务，Traeffik 可以与您现有的组件（Docker、Swarm，Kubernetes，Marathon，Consul，Etcd，…）集成，并自动动态配置。

Ambassador

Ambassador 是一个开源的微服务 API 网关，建立在 Envoy 代理之上，为用户的多个团队快速发布，监控和更新提供支持，支持处理 Kubernetes ingress controller 和负载均衡等功能，可以与 Istio 无缝集成。

Tyk

Tyk是一个开源的、轻量级的、快速可伸缩的 API 网关，支持配额和速度限制，支持认证和数据分析，支持多用户多组织，提供全 RESTful API。基于 go 编写。

Zuul

Zuul 是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器。

 

API 网关实现对比

	Kong	Traefik	Ambassador	Tyk	Zuul
基本
主要用途	企业级API管理	微服务网关	微服务网关	微服务网关	微服务网关
学习曲线	适中	simple	simple	适中	simple
成本	开源/企业版	开源	开源/pro	开源/企业版	开源
社区star	20742	21194	1719	4299	7186
配置
配置语言	Admin Rest api, Text file(nginx.conf 等)	TOML	YAML(kubernetes annotation)	Tyk REST API	REST API，YAML静态配置
配置端点类型	命令式	声明式	声明式	命令式	命令式
拖拽配置	yes	no	no	no	no
管理模式	configurable	decentralised, self-service	decentralised, self-service	decentralised, self-service	decentralised, self-service
部署
kubernetes	适中(k8s yaml,helm chart)	easy	easy	适中(k8s yaml,helm chart)	适中(k8s yaml,helm chart)
Cloud IAAS	high	easy	N/A	easy	easy
Private Data Center	high	easy	N/A	easy	easy
部署模式	金丝雀(企业版)	金丝雀	金丝雀，shadow	金丝雀	金丝雀
state	postgres,cassandra	kubernetes	kubernetes	redis	内存文件
可扩展性
扩展功能	插件	自己实现	插件	插件	自己实现
扩展方法	水平	水平	水平	水平	水平
功能
服务发现	动态	动态	动态	动态	动态
协议	http,https,websocket	http,https,grpc,websocket	http,https,grpc,websocket	http,https,grpc,websocket	http,https
基于	kong+nginx	traefik	envoy	tyk	zuul
ssl 终止	yes	yes	yes	yes	no
websocket	yes	yes	yes	yes	no
routing	host,path,method	host,path	host,path,header	host,path
限流	yes	no	yes	yes	需要开发
熔断	yes	yes	no	yes	需要其他组件
重试	yes	yes	no	yes	yes
健康检查	yes	no	no	yes	yes
负载均衡算法	轮询，哈希	轮询，加权轮询	加权轮询	轮询	轮询，随机，加权轮询，自定义
权限	Basic Auth, HMAC, JWT, Key, LDAP, OAuth 2.0, PASETO, plus paid Kong Enterprise options like OpenID Connect	basic	yes	HMAC，JWT，Mutual TLS，OpenID Connect，基本身份验证，LDAP，社交OAuth（例如GPlus，Twitter，Github）和传统基本身份验证提供程序	开发实现
tracing	yes	yes	yes	yes	需要其他组件
istio集成	no	no	yes	no	no
dashboard	yes	yes	grafana,Prometheus	yes	no

总结由上述对比表格中可以看出：从开源社区活跃度来看，无疑是Kong和Traefik较好；从成熟度来看，较好的是Kong、Tyk、Traefik；从性能角度来看，Kong要比其他几个领先一些；从架构优势的扩展性来看，Kong、Tyk有丰富的插件，Ambassador也有插件但不多，而Zuul是完全需要自研，但Zuul由于与Spring Cloud深度集成，使用度也很高，近年来Istio服务网格的流行，Ambassador因为能够和Istio无缝集成也是相当大的优势。具体使用选择还是需要依据具体的业务场景，我们在参考链接中收集了一些性能对比，大家可以做下参考。参考链接

• https://www.bbva.com/en/api-gateways-kong-vs-tyk/ kong vs tyk
• https://stackshare.io/stackups/kong-vs-traefik kong vs traefik
• https://blog.getambassador.io/envoy-vs-nginx-vs-haproxy-why-the-open-source-ambassador-api-gateway-chose-envoy-23826aed79ef envoy vs nginx
• https://engineering.opsgenie.com/comparing-api-gateway-performances-nginx-vs-zuul-vs-spring-cloud-gateway-vs-linkerd-b2cc59c65369 nginx vs zuul