有了 NGINX 和 Kong，为什么还需要 Apache APISIX？

2021 年 5 月，云原生社区技术沙龙·广州站，Apache APISIX 开源项目创始人 & PMC 王院生在活动上做了《有了 NGINX 和 Kong，为什么还需要 Apache APISIX》的分享，以下是现场分享的文字版。以下分享仅代表作者个人观点。

大家好，非常开心给大家分享一个让我激动的主题《有了 NGINX 和 Kong，为什么还需要 Apache APISIX》。

首先做下自我介绍，本人叫王院生。和这次大会主办者净超一样我们都做社区很久，我在 15 年写了一本电子书叫《OpenResty 最佳实践》，通过这本书结成了一个超万人社区。从那个时候开始个人对开源本身越发感兴趣，15 年以前我基本上主要是开源软件的使用者，然后慢慢变成社区的一个协办者，再往后变成社区领导者，也许你会问为什么？很简单，因为这本书是你写的，别人遇到各种各样的问题，有高级的也有比较普通的，问得多了我就逐步成为老师并最终成了社区领导者，像那句名言“走的人多了，也变成了路”。

这是我们团队，大家主要是远程协作，所有人聚在一起比较难。公司早期阶段只有五六个人时，还能比较容易的把团队聚起来，但从今年之后就一直没聚齐过，这是我们今年到目前以来最齐的一次（但依然有几位同学没能一起）。作为一家技术说了算的商业公司，技术在我司有非常大的话语权，尊重技术从尊重技术人才开始。没有 996 ，没有上班打卡，远程办公，欢迎感兴趣的同学联系我们，期待有梦想、有理想的你加入我司。

在创业之初，在脑子里过这张图的时候特别有意思。我们能够看到，随着我们后端架构的逐步迭代，我们引入了各种不同组件。比如到了 SOA 也就是面向服务的架构，引入反向代理组件，选型通常是 NGINX，HAProxy。迭代到微服务架构后，通常会选择一些更现代的 API 网关产品，比如 Kong、Traefik ，当然也有一些用户因为惯性习惯，还会继续选择使用 NGINX，虽然它有能力弱、使用不方便等缺点，但胜在稳定、可靠。说句题外话，从全球市场占有率看，NGINX 成为占有率最高的 Web Server 是在 2019 年 4 月份，感兴趣的同学可以到看下最新的 netcraft 报告 April 2021 Web Server Survey。

随着后端架构持续迭代，进入到了 Kubernetes 时代后，流量出入口 Ingress 大家默认会使用官方的 Kubernetes Ingress，这个项目是基于 NGINX 本地配置文件。在国内也有一些公司在使用 Traefik 作为 Ingress，这与国内 Golang 开发者基数比较大有很大关系。

我们再看看左侧比较有意思的 JAVA ，Spring Cloud 内置 API 网关先后经历了 ZUUL、ZUUL2，但还是不好用，性能、架构官方都不满意，所以 Spring Cloud 官方发起了新项目 Spring Cloud Gateway，最终形成全家桶解决方案。

最后说说右下角部分的服务网格，对于服务网格已经形成一种选择就是 istio(CP) + envoy(DP)。后面我们又看到了阿里巴巴开源的 mosn，一句话概括：Golang 版本的 envoy。

如图这些都是 NGINX 缺点，比如 NGINX 的低活跃度社区。虽然我们可以在公司层面投入更多资源，但他的社区是真不友好，不友好到什么程度呢？上面这张图可以看得到，NGINX 在 Github 的仓库只是镜像，issue 功能是关闭的，想提交 issue 不可能了，即使你提交 PR 官方也是不会合并的。

除此之外 NGINX 自身路由比较弱，比如说我要根据某个请求参数比如 id 取模运算做灰度，你会发现 NGINX 完全无法实现。所以我们能看到很多小的开源系统，只要解决了上面的灰度场景，就可以是个独立开源项目。此外 gRPC 调用在微服务调用中越来越流行，但 NGINX 对它的支持只能是“简单能用”。

最后就是 NGINX 集群统一管理，几乎每家互联网厂商都有自己的 NGINX 配置管理系统，系统虽然大同小异但就是没有统一方案，十几年了一直空白。

最后简单总结一下 NGINX 和 Kong 的问题：

NGINX 和 Kong 都有各自不同应用场景；
NGINX 缺少官方集群统一管理方案；
Kong 的控制面不是完全云原生架构。

在介绍 APISIX 之前，还是有必要先感谢两位前辈，站在巨人肩膀思考，确实让我们从一开始就有更高起点。APISIX 已经两岁多，请看架构图：

这是 APISIX 的生态图，从该图可以准确看到目前都支持了哪些周边生态。左侧是支持的协议，可以看到常见的 7 层协议有 HTTP(S)、HTTP2、Dubbo、QUIC 和物联网协议 MQTT 等，4 层协议有 TCP/UDP 。右侧部分则是一些开源或者 SaaS 服务，比如 SkyWalking、Prometheus 、Vault 等。下面就是一些比较常见的操作系统环境、云厂商和硬件环境，作为一家全球化公司，我们也支持 ARM64 等更丰富的平台。

简单解释一下这张图，可以叫它贡献者增长曲线。横坐标是时间线，纵坐标是贡献者总数。能够看到 APISIX 和 Kong 这两个项目相对更活跃，APISIX 的增长速度从开源第一天就保持着非常不错的增长率，在接近 Kong 两倍的速度成长，可见 APISIX 受欢迎程度。当然评价一个项目活跃度还有很多其他方法，比如查看每月活跃 issue、PR 总数等方式，很开心的和大家说，这些方式看 APISIX 的活跃度依然第一。

APISIX 支持多语言的特性，已经放到开源项目，欢迎感兴趣的同学可以随时关注并参与。这个实现方案的优势是简单、通用，大家可以原生的使用自己熟悉语言。

看到这张图台下的你估计一下子就明白了 APISIX 要干什么。APISIX 目标：统一代理基础设施。

也许台下的你这里会有疑问：APISIX 要支持这么多场景，是否会让 APISIX 变得四不像？这里我简单解释一下，APISIX 的核心是高性能代理服务，自身不绑定任何环境属性。当它演变为 Ingress、服务网格等产品，都是外部服务与 APISIX 配合，变化的是外部程序而不是 APISIX 自身，后面逐步为大家说明 APISIX 是如何具体支持这些场景。

服务网格，这里面有必要跟大家重点聊聊。未来五年或者十年之后，最有可能主流的服务端架构是什么？如果让我回答，我选择服务网格。

聊了这么多 APISIX 的当下，也和大家聊聊 APISIX 的未来。

因为 APISIX 目前是 Apache 基金会项目，所以它已经不再属于个人或公司，而是全人类共享财产。这样社区中的每一个你，都有权利决定他往哪个方向发展。

开源版本 APISIX 目前默认搭配的配置中心是 etcd ，虽然目前它依旧是最好的选择，但我们在和用户沟通时依然经常会听到是否支持其他配置中心，比较常见的原因是 etcd 这个产品太新了，公司现有运维产品支持列表中没有它。所以我们计划让 APISIX 可以与其他配置中心协作。

统一本身不是目标，统一之后的收益才是我们追求的背后逻辑，下面分别给出几个不同角度来分别阐述。

运维角色：使用相同的运维工具收集日志、Metric 指标等，复用已有积累；
开发角色：基于标准化的 APISIX 插件开发，能力可以方便复用，并且积累的经验可以应用到 LB、API Gateway、K8s Ingress 等不同产品线；
公司价值：统一技术栈，降低公司运营成本，降低过渡到微服务、云原生的难度，加速企业数字化转型。

关于 Apache APISIX

Apache APISIX 是一个动态、实时、高性能的开源 API 网关，提供负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。Apache APISIX 可以帮忙企业快速、安全的处理 API 和微服务流量，包括网关、Kubernetes Ingress 和服务网格等。全球已有数百家企业使用 Apache APISIX 处理关键业务流量，涵盖金融、互联网、制造、零售、运营商等等，比如美国航空航天局（NASA）、欧盟的数字工厂、中国航信、中国移动、腾讯、华为、微博、网易、贝壳找房、360、泰康、奈雪的茶等。200 余位贡献者，一同缔造了 Apache APISIX 这个世界上最活跃的开源网关项目。聪明的开发者们！快来加入这个活跃而多样化的社区，一起来给这个世界带来更多美好的东西吧！