1. 从概念到生产Jev 到底在解决什么问题第一次听到“Jev”这个名字是在一个做智能客服系统的朋友嘴里。他当时原话是“我们那套规则引擎已经快被业务方逼疯了每天新增几十条 if-else后来换成 Jev 的思路重做了一遍决策层才算把维护成本压下来。”这句话让我印象很深因为大多数所谓“AI 决策系统”最后都死在同一个地方——概念阶段讲得天花乱坠一上生产就发现延迟扛不住、决策不可解释、业务方不敢用。Jev 这个项目标题里最关键的两个词一个是“AI 决策系统”一个是“从概念到生产”。前者决定了它的技术底色后者决定了它的工程难度。市面上讲 AI 决策的文章十篇里有八篇停在“用大模型做推理”这个层面真正把系统推到生产环境、扛住真实流量、让业务方愿意签字上线的少之又少。Jev 想做的事情本质上是把“决策”这件事从散落在各处的规则、模型、人工经验里抽出来做成一套可编排、可观测、可回滚的独立系统。那它到底适合谁看如果你正在做推荐系统、风控引擎、智能调度、客服工单分流、营销权益发放这类需要“根据一堆条件输出一个动作”的场景Jev 的架构思路对你直接有用。如果你只是想让大模型帮你写写文案那这套东西对你来说偏重了。它面向的是那种决策逻辑复杂、参与方多、上线后不能随便改、改错了要背责任的场景。这类场景里决策系统的价值不在于“多聪明”而在于“多可控”。我先把结论摆在这Jev 这类系统的核心竞争力从来不是模型有多强而是决策的可解释性、可回滚性和可观测性这三件事有没有做扎实。后面所有架构设计都是围绕这三件事展开的。理解了这一点你再看它的技术选型就不会觉得那些“看起来多余”的设计是过度工程了。2. Jev 决策系统的整体架构设计思路2.1 为什么不能把决策逻辑写进业务代码我见过太多团队的做法是业务代码里直接调模型接口拿到结果就 if-else 往下走。这种写法在项目初期特别爽两天就能上线一个功能。但问题会在半年后集中爆发。第一决策逻辑和业务逻辑耦合在一起改一个阈值要重新发版整个服务第二同一个决策在三个地方各写了一遍改了一处忘了另外两处线上出现不一致第三出了问题根本不知道是哪条规则、哪个模型版本导致的只能靠日志大海捞针。Jev 的架构第一刀就切在这里把决策逻辑从业务代码里彻底剥离出来做成独立的决策服务。业务方只负责发起“决策请求”决策服务负责返回“决策结果”中间怎么算的业务方不关心。这个边界一旦划清楚后面所有的可编排、可观测、可回滚才有落脚点。这个思路其实不新鲜规则引擎早就这么干了。但 Jev 和传统规则引擎的区别在于它把“模型推理”也当成决策链路里的一个标准节点而不是外挂。传统规则引擎处理不了“先查规则、再调模型、模型结果再进规则二次判断”这种混合链路Jev 可以。2.2 分层架构接入层、编排层、执行层、数据层Jev 的整体架构我习惯拆成四层来看这样跟团队讲的时候大家容易理解。接入层负责统一收口所有决策请求。不管是 HTTP 同步调用、消息队列异步触发还是定时任务批量跑都从这里进。这一层要做的事情包括鉴权、限流、请求参数校验、决策场景路由。为什么要单独一层因为生产环境里决策请求的来源太杂了如果不收口后面编排层要处理的协议能把你逼疯。编排层是 Jev 的核心。它维护着每个决策场景的“决策流”——也就是这个场景下先做什么、后做什么、什么条件下走哪个分支。编排层不执行具体逻辑它只负责调度。你可以把它理解成乐高说明书告诉你哪块积木先拼、哪块后拼但拼积木的动作是执行层干的。执行层是真正干活的地方。规则判断、模型推理、特征查询、外部接口调用都在这一层。每个执行单元都是独立的、可替换的。这一点很重要因为生产环境里模型会换、规则会改、外部接口会挂只有执行单元足够独立才能做到局部替换不影响全局。数据层负责决策过程中产生的所有数据决策日志、特征快照、模型版本、规则变更记录。这一层最容易被忽视但它是可观测性和可回滚性的基础。没有数据层出了问题你连现场都还原不了。2.3 决策流的编排模型DAG 还是状态机编排层用什么模型来描述决策流是个关键选型。常见的有两种DAG有向无环图和状态机。DAG 的好处是直观每个节点是一个执行单元边表示依赖关系天然支持并行。缺点是处理不了循环和复杂的状态回退。状态机的好处是能表达“决策到一半发现条件不满足退回去重新走另一条路”这种逻辑缺点是图一复杂就没人看得懂了。Jev 的选择是以 DAG 为主在需要循环的场景里用有限状态机封装成单个节点。这个折中方案是我认为比较务实的。因为绝大多数决策场景本质上是无环的查特征、跑规则、调模型、出结果一条路走到底。真正需要循环的场景很少而且往往可以封装成一个独立的子决策流。提示如果你的决策流里出现了超过两层的嵌套循环先别急着优化编排引擎回头看看是不是决策场景本身就没拆干净。我踩过的坑是一个“营销权益发放”的决策流里塞了七八个循环后来发现其实是三个独立决策场景被硬揉在一起了。2.4 为什么选择“决策即配置”而不是“决策即代码”Jev 的另一个核心设计是决策流以配置形式存在而不是硬编码。这个选择背后有很现实的考量。决策即代码的问题是每次改决策逻辑都要走完整的开发、测试、发布流程。一个风控阈值的调整从提出到上线可能要三天。业务方等不起就会绕过系统直接改数据库然后系统就失控了。决策即配置的好处是业务方可以在管理后台自己调整决策流改完即时生效不需要发版。当然这带来了新的风险业务方改错了怎么办所以 Jev 配套做了版本管理、灰度发布、一键回滚。配置变更走的是和代码发布一样的严谨流程只是操作者从开发变成了业务。这里有个经验配置化的粒度要控制好。粒度太粗业务方改不动粒度太细配置项多到没人看得懂。我的做法是把决策流的结构节点顺序、分支条件做成配置把执行单元的内部逻辑规则表达式、模型参数做成代码。这样业务方调整流程开发维护执行单元各管各的。3. 核心模块拆解与关键技术点3.1 规则引擎表达式求值的性能与安全规则判断是决策系统里最高频的操作。一个中等规模的决策场景一次请求可能要跑几十条规则。如果每条规则都解释执行性能很快就成瓶颈。Jev 在规则引擎这块的做法是编译期优化加运行期缓存。规则表达式在保存时就被编译成抽象语法树运行时不重新解析。同时对于输入参数相同的规则结果会被缓存。这个优化听起来简单但在实际场景里能砍掉大量重复计算。比如“用户等级是否大于 3”这条规则在一次决策请求里可能被多个节点引用缓存后只算一次。表达式求值还有个容易被忽视的问题是安全性。如果规则表达式允许执行任意代码那就是个巨大的漏洞。Jev 的做法是限制表达式的能力只允许访问预定义的上下文变量和一组白名单函数。这样即使配置写错了也不会造成破坏。# 规则表达式的上下文结构示意 context { user: {level: 5, age: 28, city: shanghai}, order: {amount: 299.0, items: 3}, history: {orders_30d: 12, refunds_30d: 1} } # 规则表达式示例受限语法 # user.level 3 and order.amount 100 and history.refunds_30d 0注意规则表达式的变量命名一定要有规范。我见过一个系统里同时存在userLevel、user_level、ulevel三种写法后来排查问题的时候差点崩溃。建议在配置保存时就做命名校验不合规的直接拒绝。3.2 模型推理节点同步、异步与降级策略模型推理是 Jev 里延迟最高的环节。一个稍微大点的模型单次推理几百毫秒很正常。如果决策流里有多个模型节点串行延迟直接爆炸。Jev 的处理策略是能并行就并行能异步就异步能降级就降级。并行指的是没有依赖关系的模型节点同时跑异步指的是模型结果不阻塞主流程先返回默认决策模型结果回来后再修正降级指的是模型服务不可用时自动切换到规则兜底。这里有个关键设计模型节点必须支持超时和熔断。生产环境里模型服务挂掉是常态不能因为一个模型超时就把整个决策请求拖死。Jev 给每个模型节点设置了独立的超时时间超时后走降级分支同时上报监控。模型版本管理也是个坑。同一个决策场景不同用户可能走不同版本的模型灰度发布。Jev 的做法是在决策请求里带上模型版本标识执行层根据标识路由到对应的模型服务。这样灰度切换的时候不需要改决策流配置。3.3 特征查询实时特征与离线特征的一致性决策系统离不开特征。用户画像、历史行为、实时统计这些都是决策的输入。特征查询最大的问题是实时特征和离线特征对不齐。离线特征通常是 T1 更新的实时特征是秒级更新的。如果决策流里同时用了这两种特征就可能出现“离线说这个用户是高风险实时说这个用户刚完成了一笔正常交易”这种矛盾。Jev 的做法是给每个特征标注时效性决策流编排时明确哪些节点用实时特征、哪些用离线特征避免混用。特征查询还有个性能问题。一次决策请求可能要查几十个特征如果每个特征都单独查一次网络往返就把延迟吃光了。Jev 的做法是特征批量查询把一次决策需要的所有特征打包成一个请求由特征服务统一返回。这个优化能把特征查询的延迟从几百毫秒压到几十毫秒。特征类型更新频率查询延迟适用场景实时统计特征秒级10-50ms风控、反欺诈用户画像特征天级5-20ms推荐、营销上下文特征请求级0ms随请求带入所有场景模型衍生特征模型级取决于模型二次决策3.4 决策日志与可观测性出了问题怎么查决策系统最怕的不是出错是出了错不知道怎么错的。Jev 在可观测性上做了三件事全链路追踪、决策快照、指标监控。全链路追踪记录一次决策请求经过了哪些节点、每个节点耗时多少、输入输出是什么。这个用 OpenTelemetry 这类标准方案就能做关键是要把决策 ID 贯穿始终。决策快照是在决策的关键节点保存当时的完整上下文。为什么需要快照因为决策依赖的特征是实时变化的事后去查数据库数据早就变了。有了快照就能精确还原“当时系统看到了什么所以做出了这个决策”。指标监控关注的是决策系统的健康度决策成功率、平均延迟、各节点失败率、降级触发次数。这些指标要能按决策场景、按模型版本、按用户分群下钻。我见过一个团队决策系统上线三个月没出问题就是因为他们的监控面板上有一个“决策结果分布”的图某天发现某个分群的决策结果突然全部偏向同一个值一查发现是特征服务返回了默认值。4. 从概念到生产的落地实操4.1 环境准备与依赖梳理把 Jev 从概念推到生产第一步不是写代码是把依赖梳理清楚。我习惯列一张表把所有需要对接的外部系统列出来标注清楚协议、延迟、可用性要求、降级方案。# 依赖清单示例 dependencies: - name: user-profile-service protocol: gRPC timeout: 50ms fallback: use_cached_profile - name: risk-model-service protocol: HTTP timeout: 200ms fallback: rule_based_decision - name: feature-store protocol: HTTP timeout: 100ms fallback: use_default_features这张表的价值在于它逼着你在写代码之前就想清楚每个依赖挂了怎么办。生产环境里没有“不会挂”的服务只有“挂了之后怎么办”没想清楚的服务。环境准备还包括配置管理。Jev 的决策流配置、规则配置、模型版本配置都需要有独立的管理界面和存储。我建议配置存储用支持版本控制的方案每次变更都有记录能对比、能回滚。4.2 决策流的定义与调试定义决策流是落地过程中最耗时的环节。我的经验是先画流程图再写配置。流程图用白板画就行关键是让业务方、开发、测试三方都看一遍确认没有遗漏分支。画完流程图转成 Jev 的配置格式。这里有个技巧先定义节点再定义边。节点定义清楚每个执行单元的类型和参数边定义清楚节点之间的跳转条件。这样配置结构清晰改起来也方便。调试决策流的时候Jev 提供了单步执行和模拟输入的功能。你可以构造一个虚拟的决策请求让决策流一步步跑看每个节点的输入输出。这个功能在排查“为什么这个用户走了这条分支”的时候特别有用。提示调试的时候一定要覆盖边界条件。我踩过的坑是一个决策流在正常输入下跑得好好的结果线上来了一个特征值为 null 的请求整个流程直接崩了。后来养成的习惯是每个决策流上线前必须跑一遍边界用例空值、极值、类型不匹配。4.3 灰度发布与回滚机制决策系统上线最怕的是“一刀切”。新决策流直接全量万一有问题就是事故。Jev 的灰度发布支持按用户 ID 哈希、按流量比例、按用户分群三种方式。灰度发布的粒度要细。我建议先按内部用户灰度再按小比例真实用户灰度最后全量。每个阶段至少观察一天重点看决策结果分布有没有异常偏移、延迟有没有上涨、降级有没有触发。回滚机制必须是一键的。而且回滚要能回滚到任意历史版本不只是上一个版本。因为有时候问题不是最新版本引入的是上上个版本就埋下了只是现在才暴露。Jev 的配置存储保留了所有历史版本回滚就是切换版本指针秒级生效。4.4 性能压测与容量规划决策系统上生产前必须压测。压测的目标不是看系统能扛多少 QPS而是看在目标 QPS 下P99 延迟是多少降级触发率是多少。压测的方法是从低到高逐步加压每个压力级别跑够时间观察指标变化。重点看两个拐点延迟开始明显上涨的拐点和降级开始触发的拐点。生产环境的容量要留在这两个拐点之前。容量规划还要考虑峰值。决策系统的流量往往有周期性比如电商大促期间决策请求量可能是平时的十倍。Jev 的做法是支持弹性扩容决策服务无状态可以快速加机器。但依赖的外部服务不一定能弹性扩容所以压测的时候要把外部服务的容量也考虑进去。压测阶段QPSP99延迟降级率结论基线10045ms0%正常2倍20052ms0%正常5倍50078ms0.1%可接受10倍1000210ms2.3%接近拐点15倍1500580ms12%不可接受5. 生产环境常见问题与排查实录5.1 决策结果不一致同一请求两次结果不同这是最让人头疼的问题。同一个用户同样的请求参数两次决策结果不一样。原因通常有三个特征值变了、模型版本变了、决策流配置变了。排查思路是先看决策快照。Jev 的决策快照记录了每次决策的完整上下文对比两次快照就能定位差异。如果特征值不同去查特征服务为什么返回了不同的值如果模型版本不同去查灰度配置如果决策流版本不同去查配置变更记录。预防这个问题的办法是决策幂等性设计。对于同一个决策请求用请求 ID 标识如果短时间内重复发起应该返回缓存的结果。这样既能保证一致性又能减少重复计算。5.2 延迟毛刺P99 突然飙升延迟毛刺的原因很多常见的有依赖服务抖动、GC 停顿、特征查询超时、模型推理排队。排查延迟毛刺先看监控的时间线。把决策延迟的曲线和依赖服务的延迟曲线放在一起看如果毛刺时间点吻合基本就能定位。如果依赖服务正常再看决策服务自身的指标GC 次数、线程池队列长度、连接池等待时间。我遇到过一次毛刺查了半天发现是决策日志的写入阻塞了主流程。决策日志本来是异步写的但日志队列满了之后变成了同步写直接把延迟拉高。后来把日志写入改成丢弃策略队列满了就丢不影响主流程。注意决策日志很重要但不能因为记日志把主流程拖死。日志的优先级永远低于决策本身。我现在的做法是核心决策日志同步写非核心的异步写且允许丢弃。5.3 模型服务不可用降级策略失效模型服务挂掉的时候降级策略应该自动生效。但有时候降级策略本身也有问题。比如降级到规则兜底结果规则兜底的逻辑也有 bug那就彻底没救了。降级策略的设计原则是简单可靠。降级逻辑不能太复杂最好是硬编码的默认值或者最简单的规则。我见过一个系统降级到“返回上一个版本的模型结果”结果上一个版本的模型服务也挂了降级变成了递归调用。降级策略还要定期演练。不能等到真出事了才第一次跑降级逻辑。Jev 支持手动触发降级演练定期跑一遍确保降级路径是通的。5.4 配置变更引发的事故如何避免手抖配置变更引发的事故比代码 bug 引发的事故更常见。因为配置变更往往没有经过完整的测试流程业务方改完就上线了。Jev 的防护措施有三层变更审批、变更预览、变更后自动校验。变更审批是流程上的重要配置的变更需要多人确认。变更预览是让业务方在保存前看到变更后的决策流长什么样。变更后自动校验是跑一组预设的测试用例如果决策结果和预期不符自动回滚。这三层防护里我认为变更后自动校验最有价值。因为人工审批和预览都可能疏忽但自动校验是客观的。测试用例要覆盖核心场景和边界场景每次配置变更都跑一遍。问题类型典型表现排查入口预防措施结果不一致同请求不同结果决策快照对比幂等性设计延迟毛刺P99 飙升依赖服务监控日志异步化降级失效模型挂了系统也挂了降级演练降级逻辑简化配置事故上线后行为异常变更记录自动校验6. 一些踩坑之后的经验之谈Jev 这套东西我从概念阶段跟到生产上线前后大概半年多。有几个体会是文档里不会写、但实际做的时候一定会遇到的。第一个是决策流的复杂度要控制。刚开始做的时候恨不得把所有逻辑都塞进一个决策流觉得这样才叫“统一决策”。后来发现决策流超过二十个节点之后调试成本急剧上升业务方也看不懂了。现在的做法是拆成多个子决策流每个子决策流不超过十个节点子决策流之间通过决策结果传递数据。第二个是业务方的参与度决定成败。决策系统最终是给业务方用的如果业务方不参与决策流的设计做出来的东西他们不会用。我的做法是拉着业务方一起画流程图让他们自己说清楚“什么情况下走哪条路”。这个过程很耗时但省掉了后面无数次的返工。第三个是监控要走在问题前面。不要等出了问题才加监控。决策系统上线前我就把决策成功率、延迟分布、降级率、各节点失败率这些指标全部接入了监控面板。后来有一次特征服务返回了全默认值监控面板上决策结果分布立刻出现了异常十分钟内就定位了问题。第四个是回滚要练。回滚机制做出来不代表能用。我每个月会做一次回滚演练随机选一个决策场景回滚到历史版本观察系统行为。这个演练救过我一次因为发现回滚之后缓存没有失效导致新旧配置混用。最后说个小的决策系统的命名一定要规范。决策场景名、节点名、特征名都要有统一的命名规范。我见过一个系统里同一个特征有三个名字后来做特征血缘分析的时候完全对不上。现在我的做法是所有命名在配置保存时做校验不符合规范直接拒绝保存。这个约束刚开始大家觉得麻烦后来都真香了。