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

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

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

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

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

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

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

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

备选的 API 网关有哪些？

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

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

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

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