如何选择适合你的微服务 API 网关：对比 Kong、APISIX、Trk、Apigee 和其余网关

微服务 API 网关有什么做用？

让咱们先来看下微服务 API 网关的做用，下图是一个简要的说明：

API 网关并不是一个新兴的概念，在十几年前就已经存在了，它的做用主要是做为流量的入口，统一的处理和业务相关的请求，让请求更加安全、快速和准确的获得处理。它有如下传统的功能：

1. 反向代理和负载均衡，这和 Nginx 的定位和功能是一致的；
2. 动态上游、动态 SSL 证书和动态限流限速等运行时的动态功能，这是开源版本 Nginx 并不具有的功能；
3. 上游的主动和被动健康检查，以及服务熔断；
4. 在 API 网关的基础之上进行扩展，成为全生命周期的 API 管理平台。

在最近几年，业务相关的流量，再也不仅仅是由 PC 客户端和浏览器发起，更多的来自手机、IoT 设备等，将来随着 5G 的普及，这些流量会愈来愈多，同时，随着微服务架构的结构变迁，服务之间的流量也开始爆发性的增加。在这种新的业务场景下，催生了API 网关更多、更高级的功能：

1. 云原生友好，架构要变得轻巧，便于容器化；
2. 对接 Prometheus、Zipkin、Skywalking 等统计、监控组件；
3. 支持 gRPC 代理，以及 http 到 gRPC 之间的协议转换，把用户的 http 请求转为内部服务的 gPRC 请求；
4. 承担 OpenID Relying Party 的角色，对接 Auth0、okta 等身份认证提供商的服务，把流量的安全做为头等大事来对待；
5. 经过运行时动态执行用户函数的方式来实现 serverless，让网关的边缘节点更加灵活；
6. 不锁定用户，支持混合云的部署架构；
7. 最后就是网关节点要状态无关，能够随意的扩容和缩容。

一个微服务 API 网关具有了上述十几项功能，就可让用户的服务只关心业务自己，而和业务实现无关的功能，好比服务发现、服务熔断、身份认证、限流限速、统计、性能分析等，就能够在独立的网关层面来解决。从这个角度来看，API 网关既能够替代 Nginx 的全部功能，来处理南北向的流量，也能够完成 Istio 控制面和 Envoy 数据面的角色，来处理东西向的流量。

备选的 API 网关有哪些？

正由于微服务 API 网关的地位如此重要，因此它一直处于兵家必争之地，传统的 IT 巨头在这个领域很早就都有布局，好比谷歌、CA、IBM、红帽、salesforce、以及 AWS、阿里云等公有云厂商。

这些闭源的商业产品，它们的功能都很完善，覆盖了 API 的设计、多语言 SDK、文档、测试和发布等全生命周期管理，而且提供 SaaS 服务，有些还与公有云作了集成，使用起来很是方便，但同时也带来两个痛点：

1. 平台锁定。API 网关是业务流量的入口，它不像图片、视频等 CDN 加速的这种非业务流量能够随意迁移，API 网关上会绑定很多业务相关的逻辑，一旦使用了闭源的方案，就很难平滑和低成本的迁移到其余平台。
2. 没法二次开发。通常的大中型企业都会有本身独特的需求，须要定制开发，这时候你就只能依靠厂商，而不能本身动手去作二次开发。

因此咱们更偏重于开源的 API 网关方案，好比 Kong、APISIX 和 Trk 等。这些 API 网关是从云原生软件基金会（CNCF）的全景图中摘选的：

对比选型的依据

部署和维护成本

• 是能够在单机就能完整部署，仍是须要多个节点配合才能使用？
• 是否有外部的数据库依赖？好比 MySQL、Postgres？
• 是否有 web 控制台能够操做整个集群？

开源仍是闭源

• 你是否能够编写本身的插件来扩展 API 网关的功能？
• 当你使用了某个 API 网关后，是否能够平滑并且低成本的迁移到其余 API 网关？
• 是否会被锁定在特定的平台上？

可否私有化部署

• 是否支持部署在用户本身的内部服务器中？
• 是否支持多云、混合云的部署模式？

功能

• 是否支持动态上游、动态 SSL 证书、主动/被动健康检查这些基本的功能
• 可否与 k8s 生态的系统联动
• 是否能够经过 HTTP REST API 和 yaml 配置文件这两种方式，来控制网关配置

社区

• 使用者可否经过 Github、QQ 群、Stack Overflow 等方式联系到社区的开发者？
• 开源许可证是否友好？
• 是否能够方便的提交本身的修改到主线版本？
• 背后是否有商业公司支持？

商业支持和价格

• 开源版本和商业版本差别是否很大？
• 商业版本是按照 API 调用次数仍是订阅方式收费？

API 网关对比

从中咱们能够看出，Kong 和 APISIX 都是很不错的选择。