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

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

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

在新的业务场景下，催生了API 网关更多、更高级的功能：

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

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

闭源痛点

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

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

对比选型的依据

部署和维护成本

• 是可以在单机就能完整部署，还是需要多个节点配合才能使用？
• 是否有外部的数据库依赖？比如 MySQL、Postgres？
• 是否有 web 控制台可以操作整个集群？

开源还是闭源

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

能否私有化部署

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

功能

• 是否支持动态上游、动态 SSL 证书、主动/被动健康检查这些基本的功能
• 能否对接 Prometheus、Zipkin、Skywalking 等统计、监控组件
• 是否可以通过 HTTP REST API 和 yaml 配置文件这两种方式，来控制网关配置

社区

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

商业支持和价格

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

API 网关对比

下面是各个 API 网关多个角度的对比结果：

APISIX 和 Kong 的选型对比

Apache APISIX 和 Kong 都是开源的微服务 API 网关，那么在这两者之间，如何去做比较和选择呢？

这两个项目都有完善的文档和测试来覆盖，也有不少的生产用户在使用，所以不用去担心稳定性和它们的可持续发展，本文会从功能和性能这两个最直接和可验证的角度去做下对比。

从 API 网关核心功能点来看，两者均已覆盖：

测试

测试方法：分别开启指定 worker 数量（单核、多核），然后用 wrk 加大压力测试。这里要把 API 网关资源打满（主要是 CPU）。而压测客户端、上游服务都正常服务，不是瓶颈。

开启 prometheus 和 limit-count 两个插件。

通过性能测试可以看到，在不开启插件的情况下，Apache APISIX 的性能（QPS 和延迟）是 Kong 的2倍，但开启了两个常用插件后，性能就是 Kong 的十倍了。