1. 概述
API网关作为统一的请求入口，对请求进行路由、负载均衡、协议转换（http-->rpc）、安全防护、限流熔断等，把与业务无关的逻辑提炼出来，与业务逻辑完全分离。
常见的API网关主要提供以下的功能：
- 反向代理和路由：大多数项目采用网关的解决方案的最主要的原因。给出了访问后端 API 的所有客户端的单一入口，并隐藏内部服务部署的细节。
- 负载均衡：网关可以将单个传入的请求路由到多个后端目的地。
- 身份验证和授权：网关应该能够成功进行身份验证并仅允许可信客户端访问 API，并且还能够使用类似 RBAC 等方式来授权。
- IP 列表白名单/黑名单：允许或阻止某些 IP 地址通过。
- 性能分析：提供一种记录与 API 调用相关的使用和其他有用度量的方法。
- 限速和流控：控制 API 调用的能力。
- 请求变形：在进一步转发之前，能够在转发之前转换请求和响应（包括 Header 和 Body）。
- 版本控制：同时使用不同版本的 API 选项或可能以金丝雀发布或蓝/绿部署的形式提供慢速推出 API。
- 断路器：微服务架构模式有用，以避免使用中断。
- 多协议支持：WebSocket/GRPC。
- 缓存：减少网络带宽和往返时间消耗，如果可以缓存频繁要求的数据，则可以提高性能和响应时间
- API 文档：如果计划将 API 暴露给组织以外的开发人员，那么必须考虑使用 API 文档，例如 Swagger 或 OpenAPI。
2. 开源API网关对比
2.1. ingress(目前)
功能：
- 作用于 OSI 模型的第七层（应用层），主要管理基于域名或路径的路由
- 主要负责流量的入口管理，对于出口和服务间通信不提供直接支持
- 适合基本的HTTP路由需求，它集成了负载均衡和SSL终端
- 部署简单，易于设置和维护，适合小型或中等规模的应用。
缺点：
- 不支持复杂的业务场景，无法定制。
- 没有管理的 UI 和管理 API，大部分的工作都需要手工配置 config 文件的方式来进行
2.2. istio
功能：
- 提供了一种方式来控制、管理和监视在多个微服务之间的网络通信。服务网格是在应用程序之上，但在网络层之下的一个基础设施层。
- 提供了负载均衡、服务到服务的认证、流量转移规则、故障注入、金丝雀发布、分布式踪等功能，无需更改服务代码
- 流量控制：Envoy通过HTTP，gRPC，WebSocket和TCP流量的丰富路由规则启用细粒度的流量控制应用;支持请求路由和流量转移，支持弹性功能，包括熔断、超时、重试。
- 网络弹性：Envoy包括对自动重试，断路和故障注入的开箱即用支持;
- 安全性：Envoy还可以实施安全策略，并对基础服务之间的通信应用访问控制和速率限制;
缺点：
- 提供更为复杂和全面的功能集合，对于大型分布式应用是非常有用的，学习成本高。
- 接管所有服务到服务的通信，增加额外的通信开销。
- 部署比较复杂
2.3. apisix
功能：
- 主要是第七层（应用层），但可以支持四层的 TCP/UDP 流量管理。
- 管理和优化路由，实现请求的负载均衡和故障转移。
- 支持限流限速(可以基于速率、请求数、并发等维度限制)、熔断、重试机制等，保护后端服务不被过载。
- 支持多种认证机制，例如 Key Auth、JWT、OAuth等，保障API的安全性。
- 提供高度可观测性，集成如 Prometheus 和 Grafana 等工具来监控和分析API使用情况
- 可扩展性强，拥有灵活的插件机制
- 内置控制台
缺点：
- 额外维护一套高可用的 etcd 集群
- 开源后有非常多的功能，但是缺少落地案例，没有相关的文档指引大家如何使用。
2.4. kong
功能：
- Kong通过在 openresty 各个阶段加入了lua代码来实现插件的注入和执行
- Authentication 身份认证插件：Kong 提供了 Basic Authentication、Key authentication、OAuth2.0 authentication、HMAC authentication、JWT、LDAP authentication 等等实现。
- Security 安全控制插件：ACL（访问控制）、CORS（跨域资源共享）、动态SSL、IP 限制、爬虫检测等等实现。
- Traffic Control 流量控制插件：请求限流（基于请求计数限流）、上游响应限流（根据 upstream 响应计数限流）、请求大小限制等等实现。限流支持本地、Redis 和集群三种限流模式。
- Analytics & Monitoring 分析监控插件：对接 Datadog、Prometheus、Zipkin 等等监控系统的实现。
- Transformations 协议转换插件：请求转换（在转发到 upstream 之前修改请求）、响应转换（在 upstream 响应返回给客户端之前修改响应）。
- Logging 日志应用插件：支持 TCP、UDP、HTTP、File、Syslog、StatsD、Loggly 等等方式传输日志。
缺点：
- 免费版不提供官方控制台，但是有开源社区版本Konga控制台
- 性能不如apisix，路由使用的是遍历查找，当网关内有超过上千个路由时，它的性能就会出现比较急剧的下降。
- 需要依赖于PostgreSQL或Cassandra数据库，这使Kong的整个架构非常臃肿，会带来高可用的问题。如果数据库故障了，那么整个API网关都会出现故障。
3. 总结
Nginx：Nginx 基于 C 开发的高性能 API 网关，拥有众多的插件，如果API 管理的需求比较简单，接受手工配置路由，Nginx 是个不错的选择。Kong：Kong 是基于 Nginx 的 API 网关，使用 OpenResty 和 Lua 扩展，后台使用 PostgreSQL，功能众多，社区的热度很高，但是性能上看比起 Nginx 有相当的损失。如果功能和扩展性有要求，可以考虑 Kong。APISIX：APISIX 和 Kong 的架构类似，但是采用了云原生的设计，使用 ETCD 作为后台，性能上比起 Kong 有相当的优势，适合对性能要求高的云原生部署的场景。- 从性能，可维护性和高可用各方面综合考虑，建议采用Apisix方案。
