概述

Higress 是一个基于 Istio 和 Envoy 的云原生 API 网关，具备先进的 AI 功能。通过 Go/Rust/JS 编写的 Wasm 插件提供可扩展的架构，并提供了基于 Node 和 Java 的 console 模块，使得用户可以可视化使用 Higress。

Higress 最初由阿里巴巴研发，旨在解决 Tengine 配置 reload 对长连接造成影响，以及 gRPC/Dubbo 服务负载均衡能力不足的问题，于 2022 年开源。如今，阿里云云原生 API 网关、MSE 云原生网关、专有云飞天企业版 API 网关等网关产品系列均采用了 Higress 的统一架构，它已成为阿里云 API 网关产品的基础。

本文主要面向开发者和开源爱好者，围绕 Higress 基本的架构，分享一些 Higress 的基本原理，欢迎一起共建 Higress。

Higress 产品介绍

网关产品在不同场景，不同发展阶段可能会加上很多修饰词前缀，这本质上是网关主要是一层代理，伴随着应用架构的演进，网关的身份也会发生转变。

正如单体式应用到 SOA 架构时 ESB 总线的称谓，微服务架构阶段时的微服务网关，K8s 云原生架构下的云原生网关，再到现如今 AI 时代的 AI 网关。可以发现不仅仅是 Higress 如此，传统的 API 网关产品以及国内外的 API 网关云厂商，都非常默契地将自家用户页面的入口换上了 AI 网关的皮肤。按照用户场景，Higress 可以有以下几种定位：

AI 网关

AI 网关相比传统 API 网关有了一些本质的变化：

AI 网关伴随 AI 原生架构演进，会提供各类 AI 原子能力和场景化能力，助力企业应用完成智能化升级。同时，随着越来越多 AI 的概念被提出，例如 MCP、A2A，为了解决对应的场景的问题，Higress 也提供了对应的解决方案，在这些场景下我们也可能会称呼 Higress 为 MCP 网关、Agent 网关。

背景

Ingress 是 Kubernetes 中一个值得关注的模块，作为外部访问 Kubernetes 集群服务的入口，市面上已经有了多种 Ingress controller 的实现。国产实时、高性能的 API 网关 Apache APISIX 推出的 Apache/apisix-ingress-controller 就是其中一员，作为功能更加强大的 ingress 对外提供服务。笔者准备在阿里云 ACK 集群上部署测试。

Kong（https://github.com/Kong/kong）是一个云原生，高效，可扩展的分布式 API 网关。 自 2015 年在 github 开源后，广泛受到关注，目前已收获 1.68w+ 的 star，其核心价值在于高性能和可扩展性。

为什么需要 API 网关

在微服务架构之下，服务被拆的非常零散，降低了耦合度的同时也给服务的统一管理增加了难度。如上图左所示，在旧的服务治理体系之下，鉴权，限流，日志，监控等通用功能需要在每个服务中单独实现，这使得系统维护者没有一个全局的视图来统一管理这些功能。API 网关致力于解决的问题便是为微服务纳管这些通用的功能，在此基础上提高系统的可扩展性。如右图所示，微服务搭配上 API 网关，可以使得服务本身更专注于自己的领域，很好地对服务调用者和服务提供者做了隔离。

上一篇文章使用 Kong 完成了负载均衡的配置，本文介绍下在此基础上如何集成 jwt 插件来保护内部服务的安全。前置知识点：Jwt 基础概念。推荐阅读：

通俗易懂地介绍 Jwt https://blog.leapoahead.com/2015/09/06/understanding-jwt/

Jwt 的官网 https://jwt.io/

使用 Kong Community Edition（社区版 v1.3.0）来搭建一个负载均衡器，由于 Kong 是基于 Openresty 的，而 Openresty 又是 Nginx 的二次封装，所有很多配置项和 Nginx 类似。

来看一个较为典型的 Nginx 负载均衡配置

环境准备

采用三台阿里云服务器作为测试
10.19.52.8 部署网关应用 -gateway
10.19.52.9, 10.19.52.10 部署用于测试的业务系统

压测工具准备

选用 ab 作为压力测试的工具，为了方便起见，直接将 ab 工具安装在 10.19.52.8 这台机
测试命令如下：

1

ab -n 10000 -c 100 http://10.19.52.8:8080/hello/testOK?access_token=e0345712-c30d-4bf8-ae61-8cae1ec38c52

其中－n 表示请求数，－c 表示并发数, 上面一条命令也就意味着，100 个用户并发对 http://10.19.52.8/hello/testOK 累计发送了 10000 次请求。

服务器, 网关配置

由于我们使用的 tomcat 容器，关于 tomcat 的一点知识总结如下：

前言

Zuul 是 Netflix 提供的一个开源组件, 致力于在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。也有很多公司使用它来作为网关的重要组成部分，碰巧今年公司的架构组决定自研一个网关产品，集动态路由，动态权限，限流配额等功能为一体，为其他部门的项目提供统一的外网调用管理，最终形成产品 (这方面阿里其实已经有成熟的网关产品了，但是不太适用于个性化的配置，也没有集成权限和限流降级)。

不过这里并不想介绍整个网关的架构，而是想着重于讨论其中的一个关键点，并且也是经常在交流群中听人说起的：动态路由怎么做？

再阐释什么是动态路由之前，需要介绍一下架构的设计。

传统互联网架构图

上图是没有网关参与的一个最典型的互联网架构 (本文中统一使用 book 代表应用实例，即真正提供服务的一个业务系统)

加入 eureka 的架构图

book 注册到 eureka 注册中心中，zuul 本身也连接着同一个 eureka，可以拉取 book 众多实例的列表。服务中心的注册发现一直是值得推崇的一种方式，但是不适用与网关产品。因为我们的网关是面向众多的 ** 其他部门 ** 的 ** 已有 ** 或是 ** 异构架构 ** 的系统，不应该强求其他系统都使用 eureka，这样是有侵入性的设计。

最终架构图

要强调的一点是，gateway 最终也会部署多个实例，达到分布式的效果，在架构图中没有画出，请大家自行脑补。

本博客的示例使用最后一章架构图为例，带来动态路由的实现方式，会有具体的代码。