API Gateway

网关，就是指一个流量的集中式出入口。而 API Gateway，顾名思义，就是在 Gateway 上再添加了一些 API 相关的功能后得到的东西。
具体而言，API Gateway 就是比普通的网关多干了一些以前我们在应用内部实现的事：身份认证，权限控制，流量控制，日志服务等。好处有：

1. API Gateway 把这些功能都从微服务层抽离到了网关层，降低了应用层的复杂度。
2. API Gateway 可以将后端微服务的 API 进一步封装成粗粒度 API，降低客户端的请求次数。
3. API Gateway 可以将后端 API 封装成更通用的格式，保证后端 API 变动不会影响客户端。

以 Kong 为例，在 Kubernetes 中，官方的 Ingress 定义只能进行简单的七层转发配置，功能很弱，以致于很多社区的 Ingerss 实现都得另辟蹊径来添加额外特性。（所以 Istio 自己也弄了一套 IngressGateway）
而作为一个 API Gateway，Kong 要比官方的 Ingress Controller 强大很多很多，它首先兼容了 K8s 的 Ingress 定义，然后又通过 CRD 添加了一些额外的功能/特性。
所有参数都以 K8s yaml 的形式保存与配置。

使用 JWT 时，身份认证只需要 JWK 公钥（登录时才需要私钥生成 JWT），在 API Gateway 里设置好公钥，就能统一进行身份认证。（缺点是无法撤销授权）
而使用 Oauth2 时，需要单独的 Oauth2 认证服务器。

选择 API 网关

首先看一下 API Gateway - CNCF LandScape
API 网关的可选项还是挺多的，老牌的 Kong，以及国内才开源半年多的 APISIX，还有其他的实现如 tyk/gloo.

眼花缭乱，正在研究，以后补充。

API Gateway 与 Service Mesh（服务网格）

Gateway 是控制集群流量的出入，被称作南北向流量管理。
而 Service Mesh 是集群内部微服务之间的流量管控，被称作东西向流量的管理。

这两个东西并不是非常的泾渭分明，比如 Istio 作为一个服务网格，也搞了一套自己的 IngressGateway 和 EgressGateway，只是这两个 Gateway 并没有添加 API 相关的功能。

现在问题就来了：Istio 弄了一套自己的路由规则，Kong 又是以 k8s Ingress 为基础实现的 k8s 集成。那如果我们要同时用这两个东西呢？该怎么办？我的配置到底是用 Istio IngressGateway 还是 Ingress？Kong 和 Istio 要如何交互？

Kong-Ingress-Controller 在去年 9 月发布的 0.6 版本中，给出的解决方案是：

1. 入口网关的规则使用 Kong Ingress 配置，也就是抛弃掉 Istio 的 IngressGateway
2. Kong-Ingress-Controller 通过 Envoy SideCar 将流量导入到 Istio 服务网格中。

官方给的示意图如下，可和 Istio 部署示意图 对比查看：

如何为服务网格选择入口网关？ 里详细说明了上述集成方案的由来，他给出的图比 Kong 官方的更清楚些：

Kong 使用 k8s Ingerss 和自己的 CRDs 替换掉了 Istio 官方的 Gateway，Istio 服务网格层的 VirtualService 等不变。

参考

• 谈谈微服务中的 API 网关（API Gateway）
• Kubernetes 中使用 API Gateway 替代 Ingress
• 谈谈 API 网关
• 如何为服务网格选择入口网关？
• Api Gateway vs Service Mesh
• 基于 Apache APISIX 的下一代微服务架构
• Kong Ingress Controller 0.6 Released with Support for Admission Controller, Istio, and Kuma

API Gateway - Kong/APISIX 及其与服务网格的集成

原文：https://www.cnblogs.com/kirito-c/p/12394038.html