微服务五种开源API网关实现组件对比
微服务架构是当下比较流行的一种架构风格，它是一种以业务功能组织的服务集合，可以持续交付、快速部署、更好的可扩展性和容错能力，而且还使组织更容易去尝试新技术栈。微服务具有几个关键特征：
-
高度可维护和可测试性
-
与其他服务松散耦合
-
且可独立部署
-
能够由一个小团队开发
现在很多公司企业想将自己的单体应用架构迁移到微服务架构，在这个问题上，Martin Fowler提出了3个前提，而Phil Calcado对其进行了扩展如下：
-
快速配置计算资源
-
基本监控
-
快速部署
-
易于配置存储
-
易于访问网关
-
认证、授权
-
标准化的 RPC
今天我们主要讲讲易于访问的网关，也就是 API 网关。
为什么需要 API 网关
假设我们要使用微服务架构构建一个电商平台，以下可能是一些潜在的服务：
-
购物车服务
-
订单服务
-
商品服务
-
评论服务
-
库存服务
等等，客户端应该怎么访问这些服务呢？原来单体应用的情况我们都知道，都在一个服务器上部署，直接访问IP+端口+服务前缀即可，现在微服务架构下，每个服务都可以独立部署，并且是由不同的开发团队开发的，难道我们要这样访问吗？
理论上每个服务都有端点可以访问，但是客户端就需要记录所有服务的端点，发起5次请求，现在还是5个服务，如果之后扩展多了呢？对客户端来说就是一个灾难，随之带来的就是安全性问题、扩展性问题等，所以这种客户端直接与每个服务交互是不可取的，通常，更好的方式是使用 API 网关。
API 网关是客户端访问服务的统一入口，API 网关封装了后端服务，还提供了一些更高级的功能，例如：身份验证、监控、负载均衡、缓存、多协议支持、限流、熔断等等，API 网关还可以针对不同的客户端定制不同粒度的 API，上面例子中修改架构后如下：
API 网关的优缺点
API 网关的好处是显而易见的，封装了应用程序的内部结构，为不同客户端提供不同粒度的 API，同时网关自身也提供了一些高级功能，也减少了客户端与应用程序之间的往返次数，使客户端代码更优雅。
同时使用网关也存在一些缺点，增加了一个新的组件，增加了整个应用架构的复杂度，一个通俗的道理，你做的越多你犯错的风险也越高，网关不可用很可能导致整个应用架构崩溃，当然现在有各种各样的方案，能防止网关崩溃，它也可能存在瓶颈风险。
使用网关有利有弊，我个人而言，利肯定是大于弊的，我们尽可能的将弊端降到最低。
API 网关一些实现
使用一个组件时，尤其是这种比较流行的架构，组件肯定存在开源的，我们不必自己去从零开始去实现一个网关，自己开发一个网关的工作量是相当可观的，现在比较流行的开源 API 网关如下所示：
Kong
Kong是一个在 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
