API网关那些事【架构新知系列】

目前随着云原生ServiceMesh和微服务架构的不断演进，网关领域新产品不断出现，各种网关使用的技术，功能和应用领域也不断扩展，在各有所长的前提下也有很多功能重合，网上各种技术PR文章，评测资料和网关落地实践很多都有自己的立场和业务场景，很难客观判断各种网关技术的优缺点和适合场景。
本文从技术实现角度，对各种网关分分类，同时尽量理清各种网关的概念和适用场景（其实很难分清楚），方便大家进行讨论和决策

网关技术的演进

 

 

https://higress.io/zh-cn/docs/overview/what-is-higress


各网关github贡献者情况的变化，目前云原生网关是大趋势

https://git-contributor.com/?chart=contributorOverTime&repo=apache/apisix,solo-io/gloo,kong/kong,tyktechnologies/tyk,openresty/openresty,envoyproxy/envoy,istio/istio,apache/shenyu,spring-cloud/spring-cloud-gateway
 

网关按照技术实现分类

 

1. 基于Nginx + Lua的网关

 

网关	github	Github stars	Issue closed	项目开始时间	贡献者数量	社区活跃度
OpenResty	https://github.com/openresty/openresty	11.5k	447	2012	29	一般
KONG	https://github.com/Kong/kong	35.7k	3955	2015	322	高
APISIX	https://api7.ai/	12.4k	3970	2019	386	高

Nginx 是一个高性能的 HTTP 和反向代理 web 服务器，同时也提供了 IMAP/POP3/SMTP 服务。Nginx 是由伊戈尔·赛索耶夫为俄罗斯访问量第二的 http://Rambler.ru 站点（俄文：Рамблер）开发的，第一个公开版本0.1.0发布于2004年10月4日。
作为 Web 服务器：相比 Apache，Nginx 使用更少的资源，支持更多的并发连接，体现更高的效率，这点使 Nginx 尤其受到虚拟主机提供商的欢迎。能够支持高达 50,000 个并发连接数的响应，Nginx 选择了 epoll and kqueue 作为开发模型.


OpenResty(®) 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
OpenResty(®) 通过汇聚各种设计精良的 Nginx 模块（主要由 OpenResty 团队自主开发），从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样，Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块，快速构造出足以胜任 10K 乃至 1000K 以上单机并发连接的高性能 Web 应用系统。
OpenResty® 的目标是让你的Web服务直接跑在 Nginx 服务内部，充分利用 Nginx 的非阻塞 I/O 模型，不仅仅对 HTTP 客户端请求,甚至于对远程后端诸如 MySQL、PostgreSQL、Memcached 以及 Redis 等都进行一致的高性能响应。


Kong 是 API 管理的强大效率工具。对需要从事 API 管理的广大开发员来说，它是最出色的工具之一。Kong 是开源工具，具有可扩展性和模块性，可以在任何一种基础设施上运行。多年来，Kong 一直在支持优秀的开发项目，比如 Mashape（世界上规模最大的API市场）。最棒的是，Kong得到了强大的 Nginx 的支持。
Kong or Kong API Gateway is a cloud-native, platform-agnostic, scalable API Gateway distinguished for its high performance and extensibility via plugins.
By providing functionality for proxying, routing, load balancing, health checking, authentication (and more), Kong serves as the central layer for orchestrating microservices or conventional API traffic with ease.


Apache APISIX 是一个动态、实时、高性能的云原生 API 网关。它构建于 NGINX + ngx_lua 的技术基础之上，充分利用了 LuaJIT 所提供的强大性能。 为什么 Apache APISIX 选择 NGINX+Lua 技术栈？。
国产开源的API网关， 2019 年左右开始研发的，
APISIX 核心：包括 Lua 插件、多语言插件运行时（Plugin Runner）、Wasm 插件运行时等；
功能丰富的各种内置插件：包括可观测性、安全、流量控制等。
APISIX 在其核心中，提供了路由匹配、负载均衡、服务发现、API 管理等重要功能，以及配置管理等基础性模块。除此之外，APISIX 插件运行时也包含其中，提供原生 Lua 插件的运行框架和多语言插件的运行框架，以及实验性的 Wasm 插件运行时等。APISIX 多语言插件运行时提供多种开发语言的支持，比如 Golang、Java、Python、JS 等。
APISIX 目前也内置了各类插件，覆盖了 API 网关的各种领域，如认证鉴权、安全、可观测性、流量管理、多协议接入等。当前 APISIX 内置的插件使用原生 Lua 实现，关于各个插件的介绍与使用方式，可以查看相关插件文档。

 

为什么 Apache APISIX 是最好的 API 网关？


以 Nginx 为内核的网关，比较成熟的选择是 Kong， 运行相对稳定，性能也比 Java 异步化网关好不少。Kong 作为相对传统的 API 网关，直接作为容器化环境中的网关需要不少额外工作，包括对 Kubernetes 基于 ETCD 注册中心的纳管和稳定运行，为生产业务的架构升级带来不少额外的开发、维护负担。
APISIX性能比KONG好，支持的插件和功能更多，对云原生支持更好，国产开源，本地化适配比较好，但没有KONG稳定。
API7企业版，在APISIX基础上增加了RBAC，审计日志，流量标签，SOAP协议支持等企业级特性，通过了 GDPR, FIPS等合规审计；支持全生命周期管理，集成了API设计工具和API门户。

 

1. 基于Java Netty的异步化网关

Spring Cloud Gateway
Apache Shenyu
Netflix Zuul1、Zuul2

网关	github	stars	Closed issues	开始时间
Spring Cloud Gateway	https://github.com/spring-cloud/spring-cloud-gateway	4.1k	1924	2017
Apache Shenyu	https://github.com/apache/shenyu/issues	8k	1901	2019
Netflix Zuul	https://github.com/Netflix/zuul	12.8k	1038	2013

Java 异步化网关的典型代表是 Spring Cloud 系列的 Zuul 2.x 和 Spring Cloud Gateway， 好处是基于 Java 语言开发，有 Spring Cloud 项目作为参考，自研实现、扩展、维护容易，适合以 Java 为核心语言栈的团队“折腾”，缺点是 Java 语言本身在异步效率、内存回收等性能方面难以与传统代理软件匹敌，在大规模流量场景下有明显的性能瓶颈。

 

1. 基于云原生技术的网关

Service Mesh 架构包括东西向使用 Sidecar 做服务治理，同时还有一个基于 Istio+Envoy 的 Gateway 负责做跨集群之间的流量互通。如果选择 Envoy 作为网关，后续就有可能跟 Service Mesh 整合成一个大的流量调度方案，从长远来看，这是更有利于未来向统一应用架构技术栈演进的选择。


开源 Istio + Envoy，目前业界比较流行的方案 Istio 服务网格从逻辑上分为数据平面和控制平面。

• 数据平面 由一组智能代理（Envoy）组成， 被部署为 Sidecar。这些代理负责协调和控制微服务之间的所有网络通信。 它们还收集和报告所有网格流量的遥测数据。
• 控制平面 管理并配置代理来进行流量路由。

Istio 的流量管理模型源于和服务一起部署的 Envoy 代理。 网格内服务发送和接收的所有 data plane 流量都经由 Envoy 代理， 这让控制网格内的流量变得异常简单，而且不需要对服务做任何的更改
虽然国内目前使用 Envoy 作为网关的开源项目或商业化产品不多，但是国外使用 Envoy 作为网关的产品或案例并不少，比如Tetrate、Gloo Edge、Ambassador（网关改名为 Emissary-ingress）等，虽然有的使用 Istio 作为控制面，有的选择自建控制面板，但大家都不约而同地把 Envoy 作为未来演进路线的一种选择。下一代云原生网关这个方向目前还没有形成一个事实上的标准，除了 Envoy，业内还有很多企业在探索这个方向。
Service Mesh 架构提供了一个新的可能，可以把中间件所有的通用能力下沉到 Sidecar，更方便地为业务提供增量特性，缩短新业务上线的时间。

 

https://istio.io/latest/zh/docs/ops/deployment/architecture/


阿里巴巴开源下一代云原生网关 Higress：基于 Envoy，支持 Nginx Ingress 零成本快速迁移
Higress是基于阿里内部的Envoy Gateway实践沉淀、以开源Istio + Envoy为核心构建的下一代云原生网关，实现了流量网关 + 微服务网关 + 安全网关三合一的高集成能力，深度集成Dubbo、Nacos、Sentinel等微服务技术栈，能够帮助用户极大的降低网关的部署及运维成本且能力不打折；在标准上全面支持Ingress与Gateway API，积极拥抱云原生下的标准API规范；同时，Higress Controller也支持Nginx Ingress平滑迁移，帮助用户零成本快速迁移到Higress。

 

云原生API网关选型对比

产品	Kong	APISIX	Traefik	Ambassador	Gloo	Istio Gateway
语言	Lua	Lua	Golang	Python	Golang	Golang
部署复杂度	中等	中等	简单	简单	简单	简单
依赖	Cassandra或Postgres，可DBless	ETCD	V2版本K8S	K8S	K8S	K8S
开源	Apache2.0开源	Apache2.0开源	MIT协议开源	Apache2.0开源	Apache2.0开源	Apache2.0开源
核心技术	Nginx/Lua	Nginx/Lua	Golang	Envoy	Envoy	Envoy
社区情况	大	大 国内	大	中	中	大
API认证授权	支持	支持	支持	支持	支持	支持
流控	支持	支持，高性能	支持	支持	商业版支持	基于Envoy全局限流
数据转换	基于HTTP	基于HTTP	不支持	基于HTTP	基于HTTP	不支持
路由策略	host, path, method	host, path, method	Host, path	host, head, path	header, queryparam, method, path, function	Host, head, path
容器集成	自带数据面、控制面	自带数据面、控制面	仅作为网关	作为控制面适配Envoy	作为控制面适配Envoy	作为控制面适配Envoy

 

1. 基于Java Agent技术的Sermant网关

https://github.com/huaweicloud/Sermant
Sermant(也称之为Java-mesh)是基于JavaAgent无代理的服务网格技术。其利用JavaAgent为宿主应用程序提供增强的服务治理功能，以解决大规模微服务体系结构中的服务治理问题。
Sermant的愿景还包括构建插件开发生态系统，以帮助开发人员更容易地开发服务治理功能，同时不干扰业务代码。Sermant架构描述如下。

Sermant中的JavaAgent广泛采用类隔离技术，以消除框架代码、插件代码和宿主应用程序代码之间的类加载冲突。
基于JavaAgent技术，通过ByteBuddy字节码增强技术修改Java服务的字节码，只支持Java微服务。

 

1. Dubbo Proxyless Mesh

Dubbo Proxyless 模式是指 Dubbo3 直接与 Istiod 通信，通过 xDS 协议实现服务发现和服务治理等能力。
Dubbo3 依旧保持了 2.x 的经典架构，以解决微服务进程间通信为主要职责，通过丰富的服务治理（如地址发现、流量管理等）能力来更好的管控微服务集群；Dubbo3 对原有框架的升级是全面的，体现在核心 Dubbo 特性的几乎每个环节，通过升级实现了稳定性、性能、伸缩性、易用性的全面提升。

Dubbo 3已经实现了对 Istio 体系的全面接入，可以用 Istio 控制面治理 Dubbo 服务，而在数据面部署架构上，针对 Sidecar 引入的复杂性与性能问题，Dubbo 还支持无代理的 Proxyless 模式。 除此之外，Dubbo Mesh 体系还解决了 Istio 架构落地过程中的很多问题，包括提供更灵活的数据面部署架构、更低的迁移成本等。
Proxyless 模式使得微服务又回到了 2.x 时代的部署架构，同 Dubbo 经典服务治理模式非常相似，所以说这个模式并不新鲜， Dubbo 从最开始就是这样的设计模式。这样做可以极大的提升应用性能，降低网络延迟。有人说这种做法又回答了原始的基于 SDK 的微服务模式，其实非也，它依然使用了 Envoy 的 xDS API，但是因为不再需要向应用程序中注入 Sidecar 代理，因此可以减少应用程序性能的损耗。
但相比于 Mesh 架构，Dubbo 经典服务治理模式并没有强调控制面的统一管控，而这点恰好是 Service Mesh 所强调的，强调对流量、可观测性、证书等的标准化管控与治理，也是 Mesh 理念先进的地方。
在 Dubbo Proxyless 架构模式下，Dubbo 进程将直接与控制面通信，Dubbo 进程之间也继续保持直连通信模式，我们可以看出 Proxyless 架构的优势：

• 没有额外的 Proxy 中转损耗，因此更适用于性能敏感应用
• 更有利于遗留系统的平滑迁移
• 架构简单，容易运维部署
• 适用于几乎所有的部署环境

初步结论
目前APISIX相比KONG，由于后发优势，在性能和功能方面有优势，开源社区比较活跃，国产开源，针对云原生做了很多改造，本土化适配和支持比较好，但稳定性不如KONG，可以先进行小规模研究和使用，逐步作为东西向网关使用，解决协议转换，限流等需求。

Apache Shenyu，Spring Cloud Gateway，Zuul，阿里CSB2.0都是基于Java异步化的网关，适合业务团队作为业务网关使用，Shenyu功能最多，目前Bug比较多，稳定性一般，有业务网关需求的团队可以内部使用。

在云原生的大背景下，Service Mesh是目前的技术趋势，开源 Istio + Envoy目前社区非常活跃。很多大厂已经完成规模化落地云原生网关，但是下一代云原生网关这个方向目前还没有形成一个事实上的标准，GateWay API标准刚出来没用多久。但是如果公司缺乏相关的技术储备和人才，短期落地会比较困难。

目前国内很多公司（阿里系公司）已经从Dubbo2升级到Dubbo3，升级的好处包括结合Service Mesh框架实现统一的云原生服务治理；下一代通信协议 Triple，实现Stream、跨网关调用；应用级服务发现模型，降低单机及注册中心资源消耗。升级Dubbo3可以解决目前Dubbo2框架不再维护，微服务架构逐渐落后的问题，还可以同时把JDK8升级到JDK17，在性能和微服务治理方面都有收益，长期看是应该升级的。 建议先从新项目或相对独立的业务开始升级验证。






参考资料
亲历者复盘：网易的 Envoy 网关选型、开发与改造_语言 & 开发_蔡芳芳_InfoQ精选文章
SpringCloud Gateway 在微服务架构下的最佳实践_阿里云_阿里巴巴云原生_InfoQ写作社区
阿里巴巴开源下一代云原生网关Higress：基于Envoy，支持Nginx Ingress零成本快速迁移_语言 & 开发_蔡芳芳_InfoQ精选文章
云原生时代，18岁的NGINX过时了吗？_语言 & 开发_Tina_InfoQ精选文章
业务网关的落地实践_文化 & 方法_Qunar技术沙龙_InfoQ精选文章
从Kong到Envoy，网易严选网关架构演进之路
Apache ShenYu 介绍 | Apache ShenYu
雪球基于Apache APISIX的双活架构演进_架构_雪球基础组件团队_InfoQ精选文章
Proxyless Mesh 在 Dubbo 中的实践
https://github.com/apache/dubbo/issues/9436
https://cn.dubbo.apache.org/zh-cn/overview/mannual/java-sdk/upgrades-and-compatibility/2.x-to-3.x-compatibility-guide/
是时候考虑升级 JDK 17 了 - 知乎
【推荐】ShenYu网关快速接入 (多端注册)
ingress控制器那么多，到底该选哪一个？累觉不爱。