有了 NGINX 和 Kong，为何还须要 Apache APISIX？

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

你们好，很是开心给你们分享一个让我激动的主题《有了 NGINX 和 Kong，为何还须要 Apache APISIX》。 之因此咱们要作 NGINX 和 Kong 的替代项目，实际和咱们后端架构演变史大背景息息相关，我会先和你们一块儿分享后端架构演变过程，这很是重要。 首先作下自我介绍，本人叫王院生。和此次大会主办者净超同样咱们都作社区好久，我在 15 年写了一本电子书叫《OpenResty 最佳实践》，经过这本书结成了一个超万人社区。从那个时候开始我的对开源自己愈加感兴趣，15 年之前我基本上主要是开源软件的使用者，而后慢慢变成社区的一个协办者，再日后变成社区领导者，也许你会问为何？很简单，由于这本书是你写的，别人遇到各类各样的问题，有高级的也有比较普通的，问得多了我就逐步成为老师并最终成了社区领导者，像那句名言“走的人多了，也变成了路”。 2019 年我与合伙人温铭一块儿创办了深圳支流科技公司，它是一家以开源为依托的商业化公司。这家公司承载了我俩不少我的理想，也能够说是在作每一位普通程序员的理想，不想庸庸碌碌 996，我常常对别人说个人梦想就是“把个人名字刻入史册”，悲催的是人类已经不须要史册了。 这是咱们团队，你们主要是远程协做，全部人聚在一块儿比较难。公司早期阶段只有五六我的时，还能比较容易的把团队聚起来，但从今年以后就一直没聚齐过，这是咱们今年到目前以来最齐的一次（但依然有几位同窗没能一块儿）。 做为一家技术说了算的商业公司，技术在我司有很是大的话语权，尊重技术从尊重技术人才开始。没有 996 ，没有上班打卡，远程办公，欢迎感兴趣的同窗联系咱们，期待有梦想、有理想的你加入我司。 此次演讲主题须要一些背景，咱们先说说后端架构演变史。先跟你们回顾一下这张图，右图部分从上到下它不是具体数据流程图，它是咱们后端架构演变史。从最传统的单体大应用，而后变成面向服务架构(SOA)，而后是微服务，分别出现了 Spring Cloud 和 Kubernetes。Spring Cloud 架构主要服务 JAVA 语言开发者，Kubernetes 是容器编排支持任何语言，以及最近社区比较热的话题服务网格。 我常常跟公司同事说，我们展望将来五年，甚至是十年以后，哪一个架构是最终极方案？从目前信息看，服务网格会大几率胜出。即便当下它还有不少问题，但我相信这些问题都能被解决。 在创业之初，在脑子里过这张图的时候特别有意思。咱们可以看到，随着咱们后端架构的逐步迭代，咱们引入了各类不一样组件。好比到了 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。

回顾前面的架构演变图，相信不少同窗都已经发现问题在哪里。从上到下，从左到右，针对不一样场景，咱们最终“合理”的引入了各类组件来分别解决咱们的问题，架构师生存法则：选择当下最适合的。

当咱们趁手工具很少，在功能、动态、性能等之间咱们老是要妥协放弃一些，你们早已习惯甚至麻木。IT 技术发展迅速，时至今日它们是否仍是最合适方案？5G、物联网等发展迅速，如何弹性扩缩容、动态统一管理等新问题，逼着咱们从新思考。

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

除此以外 NGINX 自身路由比较弱，好比说我要根据某个请求参数好比 id 取模运算作灰度，你会发现 NGINX 彻底没法实现。因此咱们能看到不少小的开源系统，只要解决了上面的灰度场景，就能够是个独立开源项目。此外 gRPC 调用在微服务调用中愈来愈流行，但 NGINX 对它的支持只能是“简单能用”。

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

在进一步聊 Kong 以前，想和你们聊一下什么是云原生。这个名词从诞生到如今好久，但到如今没有统一明确的定义。我综合几家云厂商定义，归纳云原生特征主要有两点：第一要支持容器，第二要支持弹性伸缩部署。我认为 Kong 不彻底知足第二条，官方主推的 PostgreSQL 关系型数据库是单点，没法支持弹性扩缩容，是它架构选型硬伤。

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

• NGINX 和 Kong 都有各自不一样应用场景；

• NGINX 缺乏官方集群统一管理方案；

• Kong 的控制面不是彻底云原生架构。

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

这张图的左右分别是 DP（Date Plane）和 CP（Control Plane），跟你们所熟悉的后端服务体系同样。APISIX 从架构第一天就没有想去本身造新东西，因此关于配置中心选择了当下最成熟的 etcd。

在这个架构里面，你找不到一个单点。这里的任何一个服务出现异常宕机等事故，都不会影响 APISIX 正常对外提供服务的能力。当总体架构中的每个点都支持高可用时，用户生产系统的高稳定性就很是容易实现。

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

给你们简单地汇报一下 APISIX 当前状态，APISIX 从开源到如今两年的时间，APISIX 已经成为了全世界最活跃的开源 API 网关项目，并且这个状态已经持续了一年多。请记住最下面一句话，APISIX 已经生产可用，功能、性能、架构全面优于 Kong。在 2019 年 9 月份贝壳找房就已经把 APISIX 项目用到生产环境。

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

通过咱们实际的客户走访，支持多语言这个特性是很是有必要的。毕竟对于不少公司而言，都有本身熟悉的技术栈，不少公司对 NGINX C 和 Lua 这两个技术栈是空白。前些日子 APISIX 已经正式宣布支持多语言，目前已经支持了 Java 语言，后续也将逐步支持 Golang 、Rust、NodeJS 等语言。

APISIX 的全动态、高性能，其实和高质量的周边生态是分不开的。APISIX 的路由使用我司主导并开源的项目叫 resty-radixtree ，简单来讲它使用 radixtree 方式完成路由匹配，匹配效率相比竞品提高了一到两个数量级。其余还有 jsonschema、ipmatcher 等周边库，它们都比同类开源项目性能强几个数量级。

APISIX 支持多语言的特性，已经放到开源项目，欢迎感兴趣的同窗能够随时关注并参与。这个实现方案的优点是简单、通用，你们能够原生的使用本身熟悉语言。

聊了这么多，给你们介绍下 APISIX 有哪些优点？请看上图。

前面三个（基金会项目、安全、稳定）我以为是最重要的，做为基金会项目，它已经不属于某我的或某家公司，而是全人类的财产，咱们能够永远使用它。与之相对应的是商业公司开源项目，它能够随时修改开源项目 License，你们最近都听过相似的消息。APISIX 的安全和稳定得益于它的基石 NGINX，可以成为目前最流行、使用量最广的 web server，底蕴仍是很厉害的。

高性能、动态、社区活跃是 APISIX 的王牌，它们已经造成了良性互动。

若是一句话归纳 APISIX 的自豪，我认为是：APISIX，全世界最活跃的 API 网关项目。在此共识下，咱们把更多资源倾斜给社区，咱们相信社区会让 APISIX 稳健健康成长。

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

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

针对传统的 LB 和 API Gateway 场景，APISIX 比较大的优点就是从静态变成所有动态，不再须要 reload，要知道不少科技公司的 NGINX reload 是半小时起步。前面提到的根据请求 id 取模运算灰度场景，在 APISIX 里使用精细化路由能够很容易完成。

APISIX Ingress Controller 则完整解决了上面提到的全部问题，继承了 APISIX 的全部优点，此外还支持原生 k8s CRD ，方便用户迁移。

服务网格，这里面有必要跟你们重点聊聊。将来五年或者十年以后，最有可能主流的服务端架构是什么？若是让我回答，我选择服务网格。

右图部分就是 APISIX Mesh 的内部架构图。

聊了这么多 APISIX 的当下，也和你们聊聊 APISIX 的将来。

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

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

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 这个世界上最活跃的开源网关项目。聪明的开发者们！快来加入这个活跃而多样化的社区，一块儿来给这个世界带来更多美好的东西吧！

• Apache APISIX 项目地址：github.com/apache/apis…
• Apache APISIX 官网：apisix.apache.org