# higress网关组件级拆解


Higress 是阿里巴巴开源的 AI 原生云原生 API 网关，当前版本 v2.1.8，基于 Istio + Envoy 内核，使用 Go 语言 开发。

# 核心定位
AI 网关：统一协议对接国内外所有主流 LLM 模型厂商（OpenAI、通义千问、DeepSeek 等），支持 AI 可观测、多模型负载均衡、token 流控、AI 缓存等
MCP Server 托管：通过插件机制托管 MCP Server，使 AI Agent 能方便调用各类工具和服务
K8s Ingress 网关：兼容 Nginx Ingress 注解，支持 Gateway API 标准
微服务网关：对接 Nacos、ZooKeeper、Consul 等服务注册中心，深度集成 Dubbo
安全网关：提供 WAF 防护、多种认证鉴权策略

# 组件级拆解
higress网关基于istio+envoy构建，所以我们首先需要弄清楚 istio 和 envoy 是什么，higress是如何围绕它们进行构建的。

## istio：云原生服务网格控制平面
Istio 是由 Google、IBM、Lyft 联合推出的开源服务网格框架，同样为 CNCF 毕业项目，核心定位是流量管理层。

它本身不直接处理流量，而是作为控制中心管理所有 Envoy 代理实例，将用户的治理规则统一转换为 Envoy 可识别的 xDS 配置并下发。核心能力包括：
- 流量治理：灰度发布、流量拆分、熔断限流、故障注入等
- 安全治理：服务间 mTLS 加密、身份认证、授权策略
- 服务发现：对接 Kubernetes 等平台的服务注册体系
- 可观测性：统一采集数据面的指标、日志、链路数据

其核心控制组件为 Istiod，内部整合了 Pilot-Discovery（配置转换与 xDS 下发）、Citadel（证书管理）、Galley（配置校验）等模块。

istio的出现是为了解决微服务架构带来的治理复杂度问题，在未出istio之前，这些流量治理、安全以及运维层面的能力大多通过业务代码嵌入或引入 SDK 二方库实现，典型代表如 Spring Cloud、Dubbo、Twitter Finagle。

这种侵入式SDK治理方案在实践中暴露出结构性缺陷，存在语言强绑定、业务强耦合，标准不统一，存量改造难问题。而随着云原生基础设施的下沉趋势，Kubernetes 解决了服务部署、容器编排、基础服务发现等底层问题，但它的能力只覆盖到四层网络，七层流量治理、服务间安全、全链路可观测性仍然是平台层的空白。

行业共识逐渐形成：治理能力应该从业务应用中剥离，下沉为基础设施的一部分，业务开发只需要关注业务逻辑本身。Kubernetes 的 Pod 多容器特性，也为 “旁挂代理、接管流量” 的 Sidecar 模式提供了天然的部署基础。

所以2016 年前后，服务网格（Service Mesh）的概念被正式提出：通过在每个服务旁部署一个轻量代理（Sidecar），由代理接管所有进出流量，再通过统一的控制平面集中管理所有代理，从而实现治理能力的完全下沉。

而2017年推出的开源服务网格 Istio 正式成为行业的事实标准，目标是成为云原生时代服务治理的统一标准，其本质上是用 “Sidecar 数据面 + 统一控制面” 的架构，系统性解决了微服务治理中侵入性、碎片化、复杂度高的核心痛点。

下图是istio官网对istio的介绍图：
![Alt text](/images/202606/service-mesh.svg "service mesh")

## Istio 与 higress 网关区别
higress作为api网关时，与istio更为相关，但二者仍然定位不同、互补而非替代：
- 传统 API 网关 / Ingress 主要解决南北向流量（外部到集群）的入口路由问题
- Istio 核心解决东西向流量（服务间内部调用）的全链路治理问题，同时也提供原生 Ingress Gateway 作为南北向入口

所以Higress 可以替代 Istio 原生 Ingress Gateway 作为集群入口，同时对接 Istio 服务网格体系，形成「Higress 管入口 + Istio 管内部服务治理」的组合架构。

## Envoy：云原生标准数据平面代理
Envoy 是由 Lyft 开源、C++ 编写的高性能七层 / 四层代理，是云原生服务网格领域的事实标准数据面组件，为 CNCF 毕业项目。

它的核心定位是流量执行层，负责实际承接和转发网络流量，执行具体的路由、限流、安全等策略。核心特性包括：
- xDS 动态配置协议：通过 LDS（监听器发现）、RDS（路由发现）、CDS（集群发现）、EDS（端点发现）、SDS（密钥发现）一套标准接口，实现配置热更新；配置变更无需重启进程，不会中断业务连接，这是它与 Nginx 最核心的差异之一。
- 插件化过滤器链：支持在网络层、HTTP 层插入自定义处理逻辑，原生具备负载均衡、熔断、重试、流量镜像等治理能力。
- 原生可观测性：内置指标、链路追踪、访问日志输出能力，原生适配云原生可观测体系。

Envoy 只负责「执行」，不负责「管理」：它本身是一个数据面代理，所有配置都来自控制面，这也是 xDS 协议的设计初衷 —— 数据面与控制面完全解耦。

istio 的核心价值就是扮演了这个控制面的角色：它把用户的治理规则转换成 Envoy 可识别的 xDS 配置，统一下发给所有 Envoy 实例。

Higress 则是在 Envoy 数据面 + Istio 控制面核心的基础上，进一步针对网关场景做了产品化增强。

# Higress 基于 Envoy + Istio 的开发与增强
Higress 是阿里云开源的云原生网关，它并非从零自研，而是以 Envoy 为转发内核、以 Istio 控制面为基础，针对网关场景做了深度裁剪、定制与增强，最终形成聚焦南北向流量的 “流量 + 微服务 + 安全” 三合一网关。

1. 数据面：基于 Envoy 的定制与增强
Higress Gateway（数据面）直接以 Envoy 作为转发内核，完整继承了 Envoy 的高性能与 xDS 热更新能力，同时做了场景化适配：
- 复用 Istio 的 Pilot Agent 组件，负责 Envoy 进程的生命周期管理、健康检查、xDS 请求代理与自动恢复。
- 增强 Wasm 插件沙箱机制，支持认证、限流、AI 路由等能力的可插拔扩展；插件通过 OCI 镜像分发，热加载全程无损流量。
- 扩展多协议转换能力，比如 HTTP 转 Dubbo、HTTP 转 gRPC 等，适配企业微服务场景。

2. 控制面：基于 Istio 的裁剪与扩展
Higress Controller（控制面）复用了 Istio 核心的 Pilot-Discovery 组件作为 xDS 配置下发引擎，继承了 Istio 成熟的流量治理模型，同时做了大量网关专属的扩展：
- 新增 Higress Core 适配层：将 Kubernetes Ingress、Gateway API、Higress 自定义 CRD，以及 Nacos/Consul/ZooKeeper 等多注册中心的服务信息，统一转换为 Istio 可识别的配置模型，再通过 Pilot-Discovery 生成 xDS 下发给数据面。
- 裁剪冗余能力：去掉了 Istio 中 Sidecar 服务网格相关的大量功能，只保留网关所需的控制逻辑，整体更轻量，启动更快、资源占用更低。
- 扩展网关专属能力：新增动态证书管理、Wasm 插件全生命周期管理、WAF 安全防护、AI 网关路由（LLM 降级、限流、多模型调度）等 Istio 原生不具备的网关能力。

3. 整体设计思路
简单总结三者的关系就是：
- Envoy 解决了 “高性能、热更新、标准化转发” 的底层执行问题；
- Istio 解决了 “配置标准化、治理模型、xDS 下发” 的控制面基础问题；
- Higress 在此之上解决了 “网关场景易用性、多生态适配、业务能力扩展、AI 场景适配” 的产品化问题，让 Envoy+Istio 的技术栈从服务网格场景延伸到了更通用的 API 网关、AI 网关场景。


# 参考
1. [Istio服务网格](https://istio.io/latest/zh/about/service-mesh/)