api网关的本质

不用扯那么多，也不用画图，一句话说清楚
api网关：流量总入口，得以集中控制！
就这么简单

api网关协议上最基本要支持HTTP 和 WebSocket，功能强大点的更会支持tcp/udp的负载均衡接入
正因为支持的是http协议，所以api网关不仅仅可以作为 RESTful API 接入，接入带页面的web都可以的，完全可以当成一个web负载均衡器使用

api网关的作用

解决：认证、鉴权、安全、流量管控、缓存、服务路由，协议转换、服务编排、熔断、灰度发布、监控报警等问题
本质上，流量从我过，我就可以做想做的控制，上面列的就是我需要的控制
有了api网关才不至于裸奔，才不至于在业务层“重复建设”，才不至于在业务层去用redis+lua实现“亲，你访问过于频繁，请稍后再试”，这个事交给api网关就成

api网关比较

开源api网关大全

之前流水理鱼把市面上开源的api网关整理了个大全 “开源API网关大全20款+” https://www.iamle.com/archives/2591.html ，大部分都加入了CNCF

以下api网关3Scale、Ambassador、APISIX、Express Gateway、Gloo、Kong、KrakenD、Mia-Platform、MuleSoft、Reactive Interaction Gateway、Sentinel、Tyk、WSO2 API Microgateway
加入了CNCF

开源api网关技术栈情况

api网关技术栈，老一派的使用java，新派的使用golang、openresty+lua
小众Node.js、.net、C++ 技术栈虽然不一样，达到的目的却是一样的。
用静态语言编写api网关是有弊端的
使用静态语言编写的api网关都会有插件编写不方便的问题
使用java编写的老牌网关性能差，历史包袱重
openresty+lua也许是最佳的api网关、waf、web防火墙解决方案
依托于openresty平台具备超高性能，又依托于lua获得了动态性
CloudFlare也是春哥当年用openresty+lua技术栈做的引擎

我们从不同的技术栈来做个api网关分类
openresty+lua开源api网关
代表有Kong、APISIX、3scale、、API Umbrella

Kong不用做太多介绍，应该是开源里面最热的一个api网关了，相对庞大复杂
APISIX，轻巧+极致性能+热插件，值得一提到是插件中有个serverless的支持，简单说就是写一段自定义lua脚本，挂载到openresty任意阶段执行！

golang开源api网关
代表有Tky、Manba、GOKU API Gateway、Ambassador(基于Envoy)、Gloo(基于Envoy)、KrakenD、BFE

java开源api网关
代表有Gravitee、Zuul、Sentinel、MuleSoft、WSO2、Soul

Erlang开源api网关
代表有RIG – Reactive Interaction Gateway

.net开源api网关
代表有Ocelot

Node.js开源api网关
代表有express-gateway

闭源商业api网关

从gartner（艾瑞咨询类似）的权威报告可以找到老牌的api网关玩家是谁
行业老大：Apigee、3Scale、Amazon等
各大云都是玩家，比如阿里云api网关、腾讯云api网关、Amazon API Gateway
国内还有几家也在做商业api网关，具体搜索下就能找到

总结下api网关选型建议

• 前提满足功能需求
• 不在乎商业闭源绑定，不想麻烦，选你最容易获取的商业api网关例如云平台卖的商业网关
• 国内用户选 apisix 为代表的openresty+lua技术栈api网关，可以得到中文群组支持
• 希望国际化的选 kong 为代表的openresty+lua技术栈api网关
• 有大量的某语言开发人员，可以选基于这个技术栈的api网关，例如java选Gravitee，golang选tyk、Manba