API 网关选型及包含 BFF 的架构设计一背景介绍下图是我从网络上找到的一个

一背景介绍下图是我从网络上找到的一个微服务架构的简单架构图，如图可见 API Gateway 在其中起到一个承上启下的作用，是关键组件。
文章插图
图片来源于网络
在更通用的场景下我们会使用 NGINX 这样的软件做前置，用来处理SLB负载均衡过来的流量，作用是反向代理、集群负载均衡、转发、日志收集等功能。
然后再将 NGINX 的请求 proxy 到 API Gateway 做统一网关处理。
在上面的这个场景下 API Gateway 可以包含以下功能：

安全
限流
缓存
熔断
重试
负载
反向路由
认证、鉴权
日志收集和监控
其他

熟悉 NGINX 的朋友应该可以看出来，上面列出的这些功能和 NGINX 的部分功能是重合的，不过由于架构结构不同，在上面我提到的场景中，即 NGINX 在前 API gateway 在后的结构中，他们两者关注的维度也不一样，所以即使有重合也正常。
二架构调整下图是我基于云原生微服务架构设计的架构图其中前端流量是通过 SLB -> NGINX -> API Gateway 再到具体服务。

文章插图
三 java技术栈的 API Gateway 选型由于后端采用java 的 spring cloud 开发的，所以在语言一致性上更倾向 java 语言开发的组件。如上图虽然在 API Gateway 的位置上写的是 spring cloud gateway ，然而也可以采用像 zuul、zuul2 这些同样是 java 语言开发的组件。对于具体 zuul 和 spring gateway的选型，是这样考虑的：

文章插图
Spring Cloud Gateway 的性能比 Zuul 好基本上已经是业界公认的了，实际上， Spring Cloud Gateway 官方也发布过一个性能测试，这里节选如下数据：

文章插图
Spring Cloud Gateway 构建于 Spring 5+ ，基于 Spring Boot 2.x 响应式的、非阻塞式的 API 。同时，它支持 websockets ，和 Spring 框架紧密集成。从目前来看， gateway替代zuul是趋势。基于以上这些，综合考虑在架构中使用Spring Cloud Gateway 。
四非java技术栈的 API Gateway 选型【API 网关选型及包含 BFF 的架构设计】现代 API Gateway 越来越需要或者流行可编程网关了。上面介绍的都是基于 java 语言开发的可编程的 API Gateway 。下面我们来聊聊非 java 语言开发的网关。从前面的架构图上看，我们完全可以将 NGINX 和 API Gateway 合并起来，他们的功能的重合点自然消除了，也能降低架构的复杂性和运维成本。
NGINX 是一款优秀的软件，然而它在动态性方面的不足导致不太灵活，后面出现的 OpenResty、tengine 这些基于NGINX 和 Lua 的软件在动态性、灵活方面有本质上的改善，加上基于Lua脚本和插件，可以实现所谓的可编程。
市面上基于OpenResty 以 API Gateway 为应用场景的应用软件有 Kong、APISIX、tyk 等。以下是CNCFland scape 的一个概览

文章插图
比较了一下 NGING 和 KONG

文章插图
经过考虑，在架构上，后期有可能将 NGINX、Spring Cloud Gateway 替换成KONG 或其他软件。