介绍

Higress 是一个开源的、基于 Istio 和 Envoy 构建的下一代云原生网关，主要用于服务网关和边缘网关的统一管理。它由阿里巴巴主导开发，旨在为微服务和云原生应用提供高性能、扩展性强的流量管理解决方案。

架构

Higress 的工作方式与 Istio 的服务网格不同，它并不是像 Istio 那样在每个 Pod 旁边创建一个独立的 Envoy Sidecar Proxy。相反，Higress 是一种统一的服务网关解决方案，采用集中式部署模式，而不是服务网格的分布式 Sidecar 模型。

而非为每个 Pod 创建一个 Envoy 代理。它在 Kubernetes 集群中部署一组集中式的 Envoy 网关实例，负责处理所有外部流量。这种设计在功能和性能之间找到平衡，适合需要高性能、低复杂度的 API 网关和流量治理场景。

架构图如下：

Istio 和 Envoy 是云原生服务网格体系中的核心组件，它们在架构中分别承担了不同的功能，可以简单理解为控制平面（Istio）和 数据平面（Envoy）的分工协作。以下是它们的具体作用：

Istio：控制平面

Istio 作为服务网格的 控制平面，主要负责管理和配置 Envoy 代理，并实现流量治理、服务发现、安全策略等高级功能。

核心功能：

• 服务发现：自动检测微服务的实例和变化，维护服务拓扑。

• 配置流量规则

  • 实现流量路由（如基于 URL、请求头或版本的路由）。

  • 支持灰度发布、金丝雀部署和流量分发。

• 安全管理

  • 提供服务间的 mTLS（双向传输层安全）加密通信。

  • 实现认证和授权策略。

• 观测与监控

  • 提供指标数据收集（如 Prometheus 支持）。

  • 集成分布式追踪系统（如 Jaeger）。

  • 提供日志采集功能。

• 策略执行

  • 速率限制、重试策略等规则由 Istio 控制。

总结角色：

Istio 作为 大脑，通过定义规则和策略控制数据平面的行为。它自己并不直接处理请求，而是通过 API 下发指令，管理多个 Envoy 代理的行为。

Envoy：数据平面

Envoy 是一个由 Lyft 开发的开源、高性能的云原生边车代理（Sidecar Proxy），用于服务网格中作为 数据平面 的核心组件。它的主要功能是管理微服务之间的通信，提供高级的网络治理能力，并优化服务间的性能和安全性。

Envoy 最初由 Lyft 工程师 Matt Klein于 2016 年开源，是现代服务网格（如 Istio）和分布式系统中常用的流量管理工具。

Envoy 是服务网格的 数据平面，它作为边车代理（Sidecar Proxy），直接处理服务之间的流量，执行 Istio 下发的规则。

核心功能：

• 请求路由和转发

  • 根据 Istio 的配置进行动态路由。

  • 执行负载均衡策略，如轮询、权重等。

• 服务间通信

  • 提供透明的服务间通信，无需修改应用程序代码。

  • 处理协议转换（如 gRPC 到 HTTP）。

• 流量管理

  • 实现流量镜像、熔断、限流、重试等功能。

  • 执行 Istio 下发的路由规则（如版本切换、分流策略）。

• 安全通信

  • 实现 mTLS 加密，确保流量安全。

  • 执行 Istio 配置的认证和授权策略。

• 高性能代理

  • 基于高效的 C++ 架构，支持高并发和低延迟流量处理。

• 可观测性

  • 采集流量指标数据和日志，反馈给 Istio。

总结角色：

Envoy 作为 执行者，处理服务间的具体请求流量。它是网络流量的 门卫，根据 Istio 的指令来路由和治理流量。

两者关系

• Istio 是控制者，Envoy 是执行者。

• Istio 负责定义和下发规则，管理服务网格的全局行为。

• Envoy 负责执行这些规则，处理服务之间的网络流量。

简化理解：

• Istio = 大脑：负责管理、配置和策略。

• Envoy = 手脚：负责执行流量治理、通信和代理任务。

在服务网格架构中，这种分工模型确保了系统的灵活性、扩展性和高性能，同时为微服务通信带来了强大的流量治理能力和安全保障。

工作流程

CRD 的作用

• Higress 通过 CRD（如 Ingress、Service 或其增强的自定义资源类型）来定义流量规则、路由策略、限流、灰度发布等行为。

• 用户的操作（如修改路由、添加插件、调整负载均衡策略）会通过 CRD 表达这些需求。

修改 CRD 时的核心流程

1. 用户修改 CRD：

   • 用户通过 kubectl 或 API 修改 Higress 的 CRD 对象。

   • 例如，修改一个 Ingress 对象的路由规则、限流策略或服务地址。

2. Higress 控制器捕获变更：

   • Higress 的控制平面（Controller Manager）会监听 Kubernetes 中 CRD 对象的变更事件。

   • 控制器根据用户修改的 CRD 提取新的配置信息。

3. 控制平面生成 Envoy 配置：

   • 控制平面将 CRD 定义的规则（如路由、负载均衡）转换为 Envoy 的动态配置。

   • 配置格式符合 Envoy 的

     xDS API

     规范，包括以下关键部分：

     • LDS（Listener Discovery Service）：定义 Envoy 的监听器，接收流量的入口。

     • RDS（Route Discovery Service）：定义路由规则，将流量转发到目标服务。

     • CDS（Cluster Discovery Service）：定义后端服务的目标集群。

     • EDS（Endpoint Discovery Service）：定义集群的具体实例（Endpoints）。

4. 动态下发配置到 Envoy：

   • Higress 的控制平面通过 xDS API 将新生成的配置下发给 Envoy。

   • Envoy 接收到新的配置后，热加载这些配置，无需重启。

5. Envoy 应用新规则：

   • Envoy 根据新配置实时更新自身行为（如路由、负载均衡策略等）。

   • 客户端的请求会立即受到新规则的影响。

与Nginx对比

Nginx的reload与restart

介绍

Nginx reload 是指通过重新加载 Nginx 的配置文件来更新运行中的 Nginx 服务器的行为，而无需中断服务或停止正在处理的连接。

在 Nginx 中，配置文件 (nginx.conf) 用于定义服务器的行为，比如：

• 路由规则

• 负载均衡策略

• HTTPS 配置

• 日志策略

• 静态资源服务等

当这些配置发生修改时，必须让 Nginx 应用新的配置。而 reload 的作用就是在不停止当前正在运行的服务的情况下，应用新的配置。

特点

• 无中断服务

  • 在 reload 的过程中，Nginx 不会中断正在处理的请求。

  • 当前的工作进程（Worker Processes）会继续处理现有的连接，直到处理完毕后再退出。

• 动态加载新配置

  • 重新加载新的配置文件，以适应环境或业务需求的变化。

• 安全性

  • 如果配置文件有错误，reload 会回滚到旧的配置，确保服务正常运行。

实现原理

Nginx 的架构分为主进程（Master Process）和工作进程（Worker Processes），reload 的核心机制是通过信号控制主进程让其重新解析配置文件并控制子进程。

工作流程

1. 发送 SIGHUP 信号：

   • nginx -s reload 会向主进程发送 SIGHUP 信号，告诉主进程重新加载配置。

2. 主进程重新解析配置文件：

   • 主进程会检查 nginx.conf 配置文件的合法性。

   • 如果配置合法，主进程会启动新的 Worker 进程，并使用新配置运行。

3. 平滑关闭旧的 Worker 进程：

   • 旧的 Worker 进程会继续处理已有的请求，直到完成后退出。

   • 新的 Worker 进程开始接收新的请求。

4. 服务不中断：

   • 在整个过程中，Nginx 保证服务始终处于可用状态，没有中断或丢失连接。

缺点

在传统的 Nginx reload 机制中，即使它可以实现平滑重载，但仍然存在以下问题：

流量抖动

1. 旧工作进程退出的时机：

   • 在 Nginx reload 时，旧的工作进程会继续处理现有连接，但不会接收新连接。

   • 当旧进程退出时，所有现有的长连接会被强制中断。

   • 对于短连接的 HTTP 请求，这种影响较小，但对长连接（如 WebSocket、gRPC、AI 推理流式通信）来说，强制断开会导致流量抖动甚至中断。

2. 负载均衡影响：

   • reload 可能引发瞬时的负载不均衡，新工作进程接管所有新流量，而旧工作进程仍在处理已有流量，导致工作进程负载分布不均。

配置生效延迟

• Nginx 的配置文件是静态加载的，reload 的过程中需要完成以下步骤：

  • 检查配置文件合法性。

  • 启动新工作进程，加载新配置。

  • 等待旧工作进程完成现有连接的处理后退出。

• 这些步骤需要时间，导致配置变更无法“实时”生效，尤其是在高并发场景下，reload 的过程可能需要数秒甚至更长时间。

长连接场景的局限性

• AI 业务和 WebSocket 等场景通常依赖长连接（如 gRPC 数据流或模型推理的实时数据传输）。

• Nginx reload 会强制中断旧进程的长连接，对用户体验和业务连续性影响较大。

xDS

Higress 基于Envoy 和xDS 动态配置机制，实现了高效、实时的配置更新，无需像 Nginx 一样依赖 reload，从根本上解决了流量抖动和配置延迟的问题。

Higress 使用 Envoy 的 xDS API，通过控制平面动态下发配置给数据平面（Envoy），无需重启进程或中断连接。

gRPC 长连接

• Envoy 通过 gRPC 建立与控制平面的长连接，控制平面可以实时推送新的配置。

• 配置更新是 增量式 或 流式 的，Envoy 不需要重新拉取整个配置。

动态配置的核心原理

1. xDS 动态配置协议：

   • LDS（Listener Discovery Service）：动态更新监听器（如端口、协议等）。

   • RDS（Route Discovery Service）：动态更新路由规则（如路径匹配、负载均衡策略等）。

   • CDS（Cluster Discovery Service）：动态更新后端服务集群。

   • EDS（Endpoint Discovery Service）：动态更新服务实例的 IP 和端口。

2. 实时生效：

   • 控制平面捕获配置变更后，生成新的 xDS 配置，直接推送给 Envoy。

   • Envoy 接收到配置后立即应用新规则，而不会中断现有连接或影响正在处理的流量。

3. 毫秒级配置更新：

   • 配置下发的整个过程是异步和增量式的，无需重启任何进程，更新通常在毫秒级别完成。

长连接友好

1. 无感知连接迁移：

   • Envoy 支持保持现有连接的状态，即便新的配置下发后，现有的长连接（如 WebSocket、gRPC 流）仍然可以继续使用旧配置完成流量处理。

   • 新的连接会自动应用新的配置，从而实现“无感切换”。

2. 高并发与稳定性：

   • Envoy 的线程模型和异步处理能力更适合处理大规模长连接场景。

   • 对于 AI 推理等高并发流式数据场景，Envoy 的长连接处理性能远优于传统代理。

消除流量抖动

1. 流量切换无缝过渡：

   • Higress 的动态配置机制不会中断现有流量，旧的流量可以继续使用旧配置完成，而不会受新配置影响。

   • 旧配置资源被逐步释放，避免了 Nginx reload 带来的“瞬时流量冲击”。

2. 连接负载均衡优化：

   • Envoy 内置的负载均衡算法（如轮询、最小请求、随机）可以动态调整，避免因为新配置生效导致的不均衡。

总结

nginx原来的配置是静态的 所以要开发reload 但是现在higress配置换成动态拉取了 就不需要reload了。

由静态配置到动态配置。