Aralez 是一款基于 Cloudflare 开源框架 Pingora 构建的高性能反向代理与负载均衡器，使用 Rust 编写。本指南面向新手，一次讲透三大核心能力：轮询算法（Round Robin）、健康检查（Health Check）与粘性会话（Sticky Sessions），并附上安装步骤与常见问题，帮助你快速上手 Aralez 负载均衡配置。

💡 项目状态说明：Aralez 项目已完成更名与仓库迁移，本镜像仓库的 README.md 中保留了最新的迁移指引，获取完整源码时请以项目最新仓库为准。

一、什么是 Aralez 反向代理？为什么选它

一句话理解：Aralez 是一个站在 Pingora 肩膀上的轻量级反向代理。

Pingora 是 Cloudflare 用 Rust 编写、经过超大规模生产环境验证的反向代理框架，Aralez 在其之上封装了更易用的配置与运维体验。对新手来说，这意味着你可以用一份简单的配置文件，就获得企业级的流量分发能力。

核心特性速览：

二、轮询算法（Round Robin）：最简单的流量分配方式

轮询是负载均衡最基础的算法：请求按顺序依次分发给每台后端服务器，一轮结束后再从头开始。

┌──────────────┐ 用户请求 ────────▶│ Aralez │ │ 反向代理 / 负载均衡器 │ └─┬────┬────┬──┘ │ │ │ ┌─────▼┐┌──▼───┐┌▼─────┐ │ 后端 A ││后端 B ││后端 C │ └────────┘└──────┘└──────┘ 请求1 → A 请求2 → B 请求3 → C 请求4 → A（循环往复）

它的好处显而易见：简单、公平、无需额外状态。三台后端各承担约 1/3 的流量，天然均衡。

局限在于它"不看负载"——如果某台机器配置更高或某台响应更慢，轮询也不会区别对待。因此实际使用中，轮询算法通常要和后文的健康检查组合使用：先把"不可用"的节点踢出轮询池，再在"可用"节点间公平分发。

三、Aralez 健康检查配置详解：自动剔除故障节点

健康检查（Health Check）是负载均衡可靠性的基石。Aralez 会周期性地向每台后端发起探测请求（通常是访问一个轻量级的 HTTP 路径），根据响应结果判断节点是否健康。

典型的配置项包含：

配置示意（具体字段以项目最新配置文档为准）：

upstream: servers: - 192.168.1.10:8080 - 192.168.1.11:8080 - 192.168.1.12:8080 health_check: path: /health interval: 10s timeout: 3s

工作机制可以概括为：

1. ⏱️ Aralez 按间隔对每台后端执行探测；
2. ❌ 某节点连续探测失败 → 从轮询池中移除，新请求不再发往它；
3. ✅ 该节点恢复后再次探测成功 → 自动重新加入轮询池。

整个过程全自动、无需人工干预，配合轮询算法即可实现"坏节点自动下线、好节点自动回归"的高可用效果。

四、如何配置粘性会话（Sticky Sessions）：让用户"记住"后端

有些业务天然带着"会话属性"：用户的购物车、未完成的登录流程、本地缓存的临时状态……如果这类状态只存在于某一台后端机器上，轮询把下一次请求随机分到另一台机器时，用户就会"掉状态"。

这就是粘性会话要解决的问题：让同一用户的连续请求始终路由到同一台后端。

Aralez 默认基于 Cookie 实现：用户首次请求时，Aralez 在响应中写入一个携带后端标识的 Cookie；后续请求携带该 Cookie 回来，Aralez 便直接定位到对应的后端服务器，不再参与轮询。

upstream: sticky_sessions: cookie: aralez_session

💡 使用建议：

• 需要开启：后端保存了用户本地状态、且没有集中式会话存储（如 Redis）；
• 可以不开：服务本身无状态，或已使用集中存储——此时保持纯轮询更利于负载均衡的均匀性；
• 注意权衡：粘性会话会让流量分布随用户量倾斜，且强依赖客户端支持 Cookie，建议与集中式会话存储方案对比后再决定。

五、三者如何协作：一次请求的完整旅程

单独看每个特性都容易理解，关键在于它们在 Aralez 中如何联动。一次请求的完整旅程如下：

1. 📥 请求到达 Aralez 监听端口；
2. 🍪 检查请求中是否携带粘性会话 Cookie——有则先定位到对应后端；
3. ❤️ 若该后端已被健康检查标记为不健康，则放弃粘性，回落到常规调度；
4. 🔄 否则按轮询算法，从当前"在线"节点中选择下一台后端；
5. 📤 请求转发到后端，响应原路返回用户。

一句话总结：健康检查决定"谁能被选中"，轮询算法决定"按什么顺序选"，粘性会话决定"熟客直接去哪"。三者叠加，就是生产级负载均衡的完整闭环。

六、Aralez 安装步骤与最小可用配置

Aralez 是 Rust 项目，只要环境里装好了 Rust 工具链（cargo），即可从源码构建：

git clone https://gitcode.com/gh_mirrors/ga/aralez cd aralez cargo build --release

构建产物位于target/release目录。运行前准备一份最小配置（示意）：

upstream: servers: - 127.0.0.1:9001 - 127.0.0.1:9002 health_check: path: /health interval: 10s

将配置文件路径传给可执行文件即可启动。建议先用两台本地后端（127.0.0.1:9001、127.0.0.1:9002）验证轮询与健康检查行为，再扩展到真实集群。

⚠️ 注意：本镜像仓库的 README.md 提示项目已更名迁移，构建与部署请以项目最新仓库的说明和配置文档为准。

七、新手常见问题 FAQ

Q1：负载均衡和反向代理有什么区别？

反向代理是"替后端接收请求并转发"的角色；负载均衡是反向代理的一种典型用法——把请求按策略分发到多台后端。Aralez 同时扮演这两个角色。

Q2：粘性会话必须开启吗？

不是。只有当后端存在"机器本地状态"且没有集中式会话存储时才需要。无状态服务保持纯轮询即可。

Q3：故障节点被剔除有多快？

取决于检查间隔与失败阈值：间隔 10 秒、失败 2 次，则最坏约 30 秒内完成剔除，恢复后同样需要再探测成功才会回归。

Q4：为什么选择基于 Pingora 而不是传统 Nginx？

Rust 带来更少的运行时开销与更好的并发模型，且 Aralez 的负载均衡能力（健康检查、粘性会话等）开箱即用、配置更贴近开发者习惯。

八、总结

Aralez 把这三项能力封装在基于 Pingora 的高性能底座之上，让新手用一份配置就能搭出可靠的多后端负载均衡架构。建议从两台本地后端开始实验：先跑通轮询，再打开健康检查"杀掉"一个节点观察自动剔除，最后加上粘性会话验证 Cookie 路由——三个步骤走完，你就真正掌握了 Aralez 负载均衡的核心用法。