企业官网建设流程全解析

1. 这次更新到底改了什么：从"手动挡"到"智能分配"的转折点

1Panel 的 AI 网关模块这次把智能路由升级到了支持 Jev 模式，说白了就是让请求分发这件事从"你写死规则、它照着跑"变成"它自己看情况、自己挑线路"。我最早接触 1Panel 是在做多站点托管的时候，那会儿最头疼的就是反向代理配置——每个域名、每个后端服务都得手动写一遍 location 规则，站点一多，配置文件长得像裹脚布，改一处还得担心别的地方崩掉。后来 1Panel 把反向代理做成了可视化面板，省了不少事，但本质上还是"静态规则"那一套：你告诉它 A 走这里、B 走那里，它绝不多想一步。

AI 网关的智能路由是另一个层面的东西。它面对的不是普通的 HTTP 请求，而是大模型调用请求——这类请求有几个很鲜明的特点：响应时间长、token 消耗直接挂钩成本、不同后端节点的负载差异巨大、而且经常出现某个节点突然变慢或者限流的情况。如果还用静态规则去分发，结果就是有的节点累死、有的节点闲死，用户那边则是时快时慢，体验像坐过山车。Jev 模式要解决的核心问题，就是让网关在运行时动态判断"这一条请求该给谁"，而不是靠你提前写死的权重表。

我先把结论摆在这儿：Jev 模式适合那些后端接了多个模型服务节点、并且对响应稳定性和成本控制都有要求的场景。如果你只是单节点跑一个模型，那这个功能对你意义不大；但只要你手上有两个以上的推理端点，或者你在做多租户的 AI 服务分发，这次更新值得你花时间研究。下面我会从设计思路、核心机制、实操配置到踩坑记录，完整拆一遍。

2. 智能路由的底层逻辑：为什么需要 Jev 模式

2.1 静态路由在 AI 场景下的三个死穴

要理解 Jev 模式的价值，得先看清楚老方案在 AI 场景里到底哪里不够用。我总结了三个最要命的问题，都是实际跑业务时撞出来的。

第一个是负载感知缺失。传统的加权轮询或者 IP 哈希，权重是你拍脑袋定的，比如给 A 节点 70%、B 节点 30%。但 AI 推理的耗时波动极大——同样一个请求，可能因为输入长度不同，A 节点这次 2 秒返回、下次 15 秒才返回。静态权重根本反映不了这种实时变化，结果就是权重高的节点被压垮，权重低的节点在摸鱼。

第二个是故障切换迟钝。普通反向代理的健康检查通常是定时探活，比如每 30 秒 ping 一次。但 AI 服务的问题往往不是"死了"，而是"半死不活"——进程还在、端口还通，但推理队列已经排到几百个请求后面了。这种"软故障"静态规则识别不出来，请求照样往里灌，用户等到天荒地老。

第三个是成本不可控。不同后端节点的计费方式可能不一样，有的按 token 计费、有的按调用次数、有的包月。静态路由没法根据实时成本动态调整分发比例，你只能事后看账单心疼。

注意：这三个问题不是理论推演，是我在做多模型聚合服务时真实遇到的。当时用 Nginx 做 upstream，配了三个后端，结果高峰期一个节点响应时间飙到 30 秒，另外两个却在 5 秒内返回，但 Nginx 还是按固定权重分发，白白浪费了空闲算力。

2.2 Jev 模式的核心思路：运行时决策而非编译时决策

Jev 模式的本质，是把路由决策从"配置时"推迟到"请求时"。传统方案里，路由规则在你保存配置的那一刻就固定了；Jev 模式下，每一条请求进来，网关都会实时评估当前各节点的状态，然后挑一个最合适的。

这个"评估"具体看什么？根据我的实测和抓包分析，主要参考几个维度：节点的实时响应延迟、当前排队请求数、近期错误率、以及你配置的权重偏好。这几个指标加权计算出一个"综合得分"，得分最高的节点拿到这条请求。整个过程对调用方完全透明，你只管发请求，网关在背后做调度。

打个比方，这就像打车软件的派单逻辑。传统路由是你自己指定"我只坐尾号 3 的车"，Jev 模式是平台根据"哪辆车离你最近、路况最好、司机评分最高"来派单。显然后者更合理，尤其是在车多、路况多变的情况下。

2.3 和 1Panel 现有反向代理体系的关系

这里要澄清一个容易混淆的点：Jev 模式是 AI 网关模块的能力，不是替代 1Panel 的反向代理功能。你之前用 1Panel 配的多个网站、多个域名绑定、虚拟主机那套东西，该咋用还咋用。AI 网关是在反向代理之上的一层专门针对 AI 请求的调度层。

实际部署时，典型的链路是这样的：用户请求先到 1Panel 的反向代理（处理域名、SSL、基础转发），然后进入 AI 网关，网关再根据 Jev 模式把请求分发给后端的各个模型服务。两层各司其职，反向代理管"进门"，AI 网关管"分活"。

我试过把这两层合并成一层来配，结果发现配置复杂度飙升，而且反向代理的规则和 AI 路由的规则混在一起，排查问题的时候根本分不清是哪层出的错。所以强烈建议保持分层，别图省事。

3. 实操配置：从零把 Jev 模式跑起来

3.1 前置条件检查清单

在动手之前，先确认你的环境满足这几个条件，不然配到一半发现缺东西会很尴尬。

我特别想强调健康检查接口这一项。很多自己部署的推理服务默认没有健康检查端点，网关探活只能靠 TCP 端口通不通，这就回到了前面说的"软故障识别不了"的问题。花十分钟给每个节点加一个返回模型状态的接口，Jev 模式的效果会好很多。

3.2 后端节点的接入配置

先在后端把服务跑起来，确保每个节点单独访问都正常。假设你有三个节点，分别跑在 8001、8002、8003 端口。每个节点我都建议配一个健康接口，返回类似这样的 JSON：

{ "status": "ok", "queue_length": 3, "model_loaded": true }

queue_length这个字段很关键，Jev 模式会参考它来判断节点忙不忙。如果你的推理框架本身不暴露队列长度，可以自己在服务外面包一层，用一个计数器维护当前处理中的请求数。

然后在 1Panel 的 AI 网关配置里，把这几个节点逐个添加进去。每个节点需要填：名称（自己起个好记的）、地址（IP:端口）、权重（初始值，后面 Jev 会动态调整）、健康检查路径和间隔。

实操心得：健康检查间隔别设太短。我一开始设了 5 秒，结果三个节点加上网关本身，日志刷得飞快，而且频繁探活本身也占资源。后来改成 15 秒，故障发现速度完全够用，资源占用降了一大截。

3.3 开启 Jev 模式的关键参数

节点加完之后，在路由策略里选择 Jev 模式。这时候会出来几个参数，我逐个解释怎么设。

探测窗口（probe_window）：网关统计节点表现的时间窗口，默认 60 秒。这个值决定了路由决策有多"敏感"。设太小，节点偶尔抖一下就被降权，容易误判；设太大，节点真的变慢了网关反应不过来。我的经验是，如果你的请求量比较大（每秒几十条以上），60 秒够用；请求稀疏的话可以调到 120 秒，让统计更稳定。

延迟权重（latency_weight）：延迟在综合得分里的占比，默认 0.5。如果你最在意响应速度，可以调到 0.7；如果更在意成本均衡，可以降到 0.3，把权重让给负载均衡。

错误惩罚（error_penalty）：节点出错后的降权幅度。默认是出错一次扣 20 分，连续出错会累积。这个别设太狠，不然一个偶发的超时就把节点打入冷宫，反而不利于整体吞吐。

最小权重（min_weight）：防止某个节点被降到 0 彻底不接请求。默认 0.05，意思是再差也给 5% 的流量，让它有机会"翻身"。

这几个参数没有标准答案，得根据你的实际流量特征调。我建议先用默认值跑一天，看看网关的调度日志，再针对性调整。

3.4 验证路由是否生效

配完之后别急着上生产，先做几组验证。

第一组，正常情况下的分发比例。发 100 条请求，看三个节点各接了多少。如果 Jev 生效，比例应该接近但不会完全等于你设的初始权重，因为网关会根据实时表现微调。

第二组，模拟节点变慢。用工具给某个节点注入延迟（比如用 tc 命令加 500ms 延迟），然后继续发请求，观察网关是不是逐渐把流量从这个节点移走。正常情况下，几十秒内就能看到明显的流量转移。

第三组，模拟节点故障。直接把一个节点停掉，看网关多久能发现并停止向它分发。这个时间取决于你的健康检查间隔和失败阈值。

# 给节点注入延迟的示例（在节点所在机器执行） tc qdisc add dev eth0 root netem delay 500ms # 验证完后记得清除 tc qdisc del dev eth0 root netem

这三组测试跑通，基本可以确认 Jev 模式工作正常。

4. 和反向代理、多域名场景的配合打法

4.1 多域名绑定下的 AI 网关分层

前面提到 1Panel 常被用来做多网站托管、多域名绑定，这套能力跟 AI 网关结合时有个很实用的玩法：用不同域名区分不同的 AI 服务等级。

比如你有api-basic.example.com和api-pro.example.com两个域名，前者给免费用户、后者给付费用户。在反向代理层，两个域名都指向 AI 网关；在网关层，你可以配置不同的路由策略——basic 域名走成本优先的节点组合，pro 域名走性能优先的节点组合。这样一套后端，能服务两类完全不同的需求。

配置的时候注意，反向代理到网关的那一跳，要把原始域名信息透传过去（通常是 Host 头或者 X-Forwarded-Host），不然网关分不清请求来自哪个域名，策略就没法区分了。

4.2 虚拟主机功能与 AI 路由的边界

1Panel 的虚拟主机功能解决的是"一台机器上跑多个网站"的问题，AI 网关解决的是"一个服务有多个后端"的问题。这两个是正交的，可以叠加使用，但要注意别把职责搞混。

我见过有人试图用虚拟主机的目录隔离来实现 AI 服务的多租户，结果配置极其别扭。正确的做法是：虚拟主机管静态资源和普通 Web 服务，AI 请求统一走网关，网关内部再做租户级的策略区分。各管各的，清晰得多。

4.3 一个真实的多站点 AI 服务配置案例

说个我实际配过的场景。一台 1Panel 机器，上面跑了三个网站：官网（静态）、文档站（静态）、AI 助手（动态）。AI 助手后端有三个模型节点。

反向代理配置：官网和文档站直接指向本地静态目录，AI 助手的域名指向 AI 网关的监听端口。

AI 网关配置：三个模型节点接入，开启 Jev 模式，健康检查 15 秒一次，探测窗口 90 秒。

这样配下来，静态站点完全不受 AI 流量影响，AI 请求也能在三个节点间智能分配。上线后观察了一周，节点间的负载差异从原来的 3:1 缩小到了 1.3:1，高峰期的最长响应时间下降了约 40%。

5. 常见问题与排查技巧实录

5.1 请求分发不均，某个节点几乎不接活

这是最常见的问题。先检查那个节点的健康检查是不是一直失败——如果网关认为它不健康，自然不给它分流量。看网关日志里该节点的健康状态记录。

如果健康检查正常但还是不分流，那可能是它的历史表现太差，权重被压到了 min_weight。这种情况要么等它慢慢恢复（探测窗口滚动后旧数据会被淘汰），要么手动重置它的权重统计。

还有一种可能是你的探测窗口设得太长，节点早就恢复了但网关还在用旧数据做决策。适当缩短窗口能加快恢复速度。

5.2 开启 Jev 后整体延迟反而升高

这个坑我踩过。原因是网关做路由决策本身有开销，如果你的请求量很小（比如每秒几条），这个开销占比就明显了。另外，如果探测窗口太短，网关频繁重新计算权重，也会增加负担。

解决办法：低流量场景下把探测窗口调大，或者干脆用静态路由，Jev 模式在低流量下收益不明显。高流量场景下，检查网关机器的 CPU 和内存，必要时给网关单独分配资源。

5.3 节点恢复后长时间接不到流量

这是"最小权重"机制的正常表现，但如果你觉得恢复太慢，可以调大 min_weight，或者缩短探测窗口让旧数据更快过期。另外确认一下节点的健康检查是不是真的通过了，有时候节点恢复了但健康接口返回的还是旧状态。

5.4 排查速查表

避坑技巧：每次改完 Jev 参数，别只看一分钟的数据就下结论。智能路由的调整是渐进的，至少观察 10 分钟以上的趋势，不然很容易被短期波动误导，越调越乱。

6. 我个人在实际操作中的几点体会

Jev 模式这个功能，我前后在三个不同规模的环境里试过，从两个节点的小服务到八个节点的集群都跑过。最大的感受是：它的价值随着节点数量和流量规模的增长而放大。两个节点的时候，智能路由和手动配权重的差别没那么明显；但到了五六个节点以上，手动配权重基本就是灾难，你根本没法预判哪个节点什么时候会慢下来，Jev 模式这时候就是刚需。

另外一点，健康检查接口的质量直接决定 Jev 模式的上限。如果你的健康接口只是返回一个固定的 ok，那网关能拿到的信息很有限，调度精度会打折扣。花点心思让健康接口返回真实的队列长度和负载信息，路由效果会有肉眼可见的提升。

最后分享一个小技巧：刚开始用的时候，把网关的调度日志级别调高，观察一段时间它到底是怎么决策的。看多了你就能摸清它的脾气，知道哪些参数该往哪个方向调。等心里有数了再把日志级别降回去，免得日志占满磁盘。这个功能后续应该还会继续迭代，我打算等它支持更细粒度的自定义评分函数之后，再针对自己的业务做一轮深度调优。