最近在梳理外卖霸王餐活动的用户资格校验代码发现这块业务比表面看起来要复杂得多。一个霸王餐活动上线牵扯到新用户判定、地域限制、设备风控、邀请关系校验、每日名额控制这些规则散落在订单、用户、营销、风控好几个服务里每次活动改版都要同时改三四个服务联调和发布都让人头大。所以当时做了一个比较大的调整把资格校验逻辑从各个业务服务中抽出来做成一个独立的校验服务。这篇文章就是把这次微服务架构下的解耦设计完整复盘一遍从为什么拆、怎么拆、落地时踩了什么坑到线上问题的排查思路都写出来。这套方案对三类人特别有价值一是正在做营销活动系统的后端开发二是想把散落的业务校验逻辑收敛成统一服务的架构师三是面试前想梳理“服务拆分真实案例”的同学。文章里的方案我都实际跑过线上流量高峰期扛过日均百万级校验请求不是纸上谈兵可以直接参考。1. 霸王餐资格校验的业务背景与解耦诉求1.1 霸王餐活动到底在做什么资格校验为什么这么难外卖平台的霸王餐本质上是补贴换增长。用户完成平台设定的条件比如邀请新用户、连续三天点单、指定店铺下单满额就能获得一张接近免费的大额补贴券或者直接享受免单。这个模式在很多城市和校园市场是拉新激活的利器诱导分享的效果比纯发券好很多但代价是用户需要被校验的条件特别多。一个典型的霸王餐活动规则可能是“新用户且所在城市为活动开放城市设备指纹无高风险记录30天内未参加过同类霸王餐活动且当日本活动剩余名额充足邀请关系链上的邀请人未被风控”。这条规则拆开看就是五个小判断每个判断的数据来源都不在一个服务里。新用户状态在用户中心城市信息在用户画像服务设备风险在风控团队参与频次在营销系统自己的库里邀请关系链在邀请关系服务。难点就在这里资格校验不是一个简单的“查一张表就能判断”的操作它是一次跨多个基础服务的数据聚合计算。业务规则还经常变这周要求“新用户且在校大学生”下周可能改成“老用户回归且近七天未下单”如果每次改规则都要动业务代码整个研发节奏根本跟不上运营的需求。1.2 传统实现下我踩过的坑最早做霸王餐活动的时候资格校验逻辑是直接写在订单服务的下单接口里的。入口一进来先调用户服务查new_user_flag再调画像服务查city_code然后调风控服务查risk_level最后查自己库里的活动参与记录。看起来一步到位实际运行起来全是问题。最头疼的是规则口径不统一。订单服务里判断“新用户”用的是用户服务返回的注册天数小于30天营销服务发券时判断“新用户”用的却是首单未支付两边判断结果经常冲突。用户明明在订单侧通过了资格校验到了发券环节却被拦下来客服咨询量暴增。其次是改一个活动要动好几个服务。运营说“新用户判定改成注册小于15天的用户”订单服务要改、发券服务要改、可能还有推送服务的过滤逻辑要改。三个服务联调一遍加上测试回归一个规则调整的完整上线周期至少得三天。活动通常只有一两周的有效期规则上线就滞后了。还有高峰期的链路性能问题。下单高峰期一个资格校验要串行调用五个下游服务最外层接口P99耗时经常超过1.5秒最要命的是这会占用订单服务自身应用的线程池资源导致整个下单链路都变慢。后面排查线上问题的时候我经常看到订单服务因为依赖了太多校验逻辑出现了非业务原因的线程池满。1.3 解耦设计究竟拆的是什么遇到这些问题之后我重新梳理了一下发现“资格校验”这个抽象概念其实可以分成三层能力第一层是规则定义也就是“这次活动到底要满足什么条件”这一层天然应该配置化业务运营调整规则时不应该动到代码。第二层是规则执行引擎也就是“拿着一堆条件怎么按优先级和依赖关系去依次判断”这一层是纯技术组件没有业务含义完全可以复用。第三层是数据获取也就是“每一个条件的数据从哪里来”这一层需要和各基础服务打通但上游服务不应该反向感知校验逻辑。解耦设计拆的就是这三层。把规则定义配置化把规则执行引擎独立把数据获取收敛到统一的校验服务内部。对外校验服务只暴露一个“传入用户和活动传出是否能参加及原因”的接口对内它自己管理规则配置、执行编排和下游依赖。这么一来上游的订单服务、发券服务不再关心校验细节只需要调用统一接口。校验逻辑变更时大多数情况只改校验服务本身甚至只改配置不用动代码。各基础服务也不需要为每个活动适配一套校验参数。2. 整体架构设计把校验动作从业务链路里抽出来2.1 职责边界谁发起、谁执行、谁提供数据解耦之后整个链路的职责划分变得很清晰。我习惯用“发起方、执行方、数据源”来划分边界。发起方指的就是业务链路上需要做资格判断的服务。典型的下单服务需要在用户下单时确认是否能享受霸王餐优惠发券服务需要在发放补贴券前确认用户是否够资格核销服务需要在用户使用券时校验一遍资格是否仍然有效。这三个场景都是发起方它们只需要关心“用户有没有资格”不需要关心“用户为什么有资格”。执行方就是独立的资格校验服务内部包含规则缓存、规则引擎、下游数据聚合模块。它做的事情很简单接收一次校验请求根据活动ID加载规则配置并行或串行地获取决策所需的数据跑完规则链条返回一个通过与否的结果附带上拒绝原因码。数据源是各基础服务。用户服务提供用户状态、注册时间、首单时间画像服务提供地理位置、消费偏好风控服务提供设备风险评分营销数据服务提供参与历史邀请关系服务提供邀请链路信息这些数据都收归到校验服务的上游依赖中。有一个边界原则我严格执行资格校验服务只做判断绝不允许做数据修改。也就是说它不会去调用修改接口把用户标记成“已使用资格”也不会去扣减名额这些写操作必须由发起方或者最终发券服务完成。只读边界保证了校验服务无状态水平扩展和灰度发布都更简单。2.2 统一的接口契约与数据模型接口设计是解耦成功的一半。我最后定的接口结构很简单请求体大概长这样{ userId: 888001234, activityId: act_20241220, sceneType: ORDER_SUBMIT, traceId: a1b2c3d4e5f6, extContext: { merchantId: mb_1024, orderAmount: 3600, channel: H5_PROMOTION } }响应体也做了定型{ pass: true, code: PASS, rejectReason: , rejectDetail: {}, verifyId: vh_20241220_0001 }如果拒绝code和rejectReason会返回具体原因比如“NOT_ELIGIBLE_CITY”表示不在开放城市“USER_DAILY_LIMIT_EXCEEDED”表示当日名额已用完“INVITE_RELATION_RISK”表示邀请人存在风险。rejectDetail里可以放一些现场数据比如当前名额剩余数量方便前台做差异化提示。这个接口契约定下来之后上游服务完全不需要感知校验逻辑的内部变化。后续我们把规则引擎重写了一遍从自研的规则引擎换成了一套新的开源规则实现上游服务一行代码都没改这是解耦带来的最直接的红利。2.3 规则引擎的设计规则组、短路与编排规则引擎是整个校验服务的核心我把它设计成了“规则组 原子规则 编排器”三层结构。规则组是面向一个活动的配置单元。每个活动对应一个规则组规则组里挂多条规则规则之间用执行策略标识来标明关系比如“全通过才通过”或“任一通过即通过”。大多数活动是AND关系比如我们上面提到的五个条件必须全部满足。少数活动是OR关系比如“老用户回归7天内有首单”或“新用户完成首单”二者满足其一即可。原子规则是单一条件的判断封装。每个原子规则接收之前规则累积产生的上下文以及从数据源获取的字段集合输出一个布尔值结果和一个原因码。原子规则自身不感知前面已经跑了哪些规则这样可以自由组合。编排器是执行的主逻辑。它的核心优化点是短路执行。对于AND关系的规则组只要前面有一条规则不通过后面的规则就可以全部跳过不用再去耗下游资源。比如一个活动里“设备风险高”这条规则直接拦截了请求就没必要再去查邀请关系链路的明细数据。我举一个具体执行过程的例子。一次活动校验规则组按序执行第一条规则是“新用户判定”数据来自用户服务耗时40ms不通过则直接返回拒绝后续不再执行。第二条规则是“城市开放校验”数据来自画像服务耗时20ms。第三条是“设备风险过滤”数据来自风控服务耗时60ms。第四条是“近30天参与频次”数据来自本服务数据库耗时10ms。第五条是“当日名额余量”数据来自Redis计数器耗时5ms。全部通过之后再写一次校验结果日志到本地文件再通过消息队列异步写一份到数据仓库。这条链路在正常情况下总耗时大概140ms其中网络IO和数据获取占了绝大部分规则本身的计算时间几乎可以忽略。遇到风控服务响应变慢时因为前两条规则已经能拦截掉大概60%的无效请求后面的规则根本不会触发对风控依赖的尖峰流量被自然削掉了。3. 关键模块的实操落地3.1 规则配置的存储与缓存策略规则配置是整个校验服务的大脑大脑出问题全链路都完蛋。所以配置存储我做了两层保护。第一层是MySQL持久化一张活动规则配置表字段包括activity_id、rule_group_id、rule_id、rule_type、rule_params、version、effective_time、expire_time。规则启停不是物理删除而是用一个status字段做逻辑删除保证能灰度回退。配置表还设计了一个version字段每次修改都递增方便后面做配置对比和发布追踪。第二层是Redis缓存。校验服务每次处理请求不能直接查MySQL否则规则变更还没来得及发布数据库就被打挂了。我通常把全量规则配置在Redis里存一份key设计成exam:rule:config:{activityId}value是JSON序列化后的规则组信息。加载策略是本地缓存预热服务启动时从MySQL全量加载到内存同时启动一个定时任务每隔30秒刷新一次配置缓存。有一个细节值得提配置变更时我们不直接改线上数据而是先写入新版本配置通过管理后台的发布按钮推送到Redis等校验服务某个实例的本地内存确认加载新版本后再把数据库里的status切到新版本。万一新配置有问题还有一个一键回滚开关直接把Redis里旧版本配置顶回去十秒内生效。这个机制救了我们好几次。3.2 预校验 异步复核的削峰方案纯粹同步校验在流量高峰时会遇到不小挑战。大促节点霸王餐活动的校验请求QPS能把下游风控服务打到限流一旦风控服务拒绝响应校验服务就得设计重试和超时的逻辑整体P99就上去了。我的解决方案是拆分预校验和异步复核两个阶段。预校验是同步做的只执行那些开销小、命中率高的硬性规则比如当日名额是否充足、用户是否已被拉黑、活动是否在有效期内。这些规则的数据都在本地缓存或Redis里单次执行不到10ms。预校验通过后下单接口直接放行用户侧感受不到延迟。异步复核则是把剩下的所有规则放进消息队列由后台消费者重新跑一遍完整规则链。复核阶段如果发现用户其实不符合资格就推一个事件给订单系统触发订单的后续处理比如回收补贴、取消优惠、通知用户。这里有一个资损隐患需要自己把握好边界。异步复核是“先放行后追查”就存在用户已经拿到优惠甚至吃了霸王餐但资格不满足的情况。所以我做了两层控制一是异步复核的时限要尽可能短我当时用RocketMQ的延迟消息做了15分钟内的复核保证绝大多数资格问题的追认都在用户消费之前完成二是预校验阶段宁可多放一些边界用户也不能漏掉本应拦截的明显风险用户。海量流量削峰和严格风控之间需要一碗水端平这套方案是在可控范围里做的折中。3.3 降级兜底与白名单机制任何一个依赖组件的可用性都不可能做到100%资格校验服务也要考虑依赖挂掉时怎么处理。我在这块设计的核心思路是“能静默就静默能放行就放行能拦截绝不误伤”。下游数据源不可用时校验服务不应该无限等待重试而是把一个较短超时时间内的快照数据作为替代。比如用户服务超时就用本地缓存里该用户上一次的画像字段做参考中心缓存不可用时直接降级查MySQLMySQL也不可用时我们就用本机内存里预加载的活动规则和用户名单做本地判断。纯粹做本地判断是最后的兜底通过率会比完整规则链高一些保护的是用户体验。正常情况下用户服务挂掉的概率很低就算因此多放了一些边界用户进来后续的异步复核还能兜住。但如果是明确的风控条件比如该用户命中黑名单、设备高风险这类规则绝不允许降级放行必须把请求拦截掉这种规则我会标记为不可降级硬规则。白名单机制也是必须要有的。内部测试人员、客服账号、产品体验账号以及几个战略合作商户的关联用户都需要直接放行进活动。白名单不仅在校验服务里有一份还会同步到发起方服务相当于双重保障。4. 常见问题与排查技巧实录4.1 缓存穿透、击穿和雪崩的实际处理资格校验服务对缓存的依赖很高线上踩坑最多的就是缓存的三个经典问题。先讲穿透。霸王餐活动通常会有集中的流量入口运营会在短视频平台投放下单链接瞬间涌进来大量首次访问的用户。这些用户去查活动规则缓存或用户画像缓存时如果Redis里没有对应key请求就会直接打到数据库Redis扛不住数据库也可能扛不住。常规手段是缓存空值把不存在的key也缓存起来设置较短TTL。这个方案对大部分场景够用但对恶意攻击时大量伪造的不存在ID无能为力因为每次伪造ID都不一样缓存空值就没有意义。所以在校验服务里我针对高频非热点活动ID加了布隆过滤器在请求进缓存之前先判断规则key是否存在不存在直接返回默认配置省掉一次数据库查询。击穿是热点活动瞬间过期导致的。一个爆款霸王餐活动同一秒内几万请求打在同一个key上如果这个key刚好过期全部请求会穿透到数据库。我的处理方式是把规则配置分为两级缓存Redis缓存负责存储最终生效的配置本地内存缓存负责提供热路径读取。Redis里的key即使过期本地缓存里旧版本配置还能继续顶一段时间同时后台加载线程拿新配置去覆盖。这里要给本地缓存设置一个很小的过期时间比如30秒保证配置新鲜度不至于旧配置用了太久雪崩。雪崩是大面积缓存同时失效造成的。解决方案是给所有缓存key的TTL加随机扰动比如设置基础TTL为5分钟实际TTL在4.5到5.5分钟之间随机避免同一时间段集体过期。同时用多级缓存让雪崩的概率降到尽可能低。4.2 规则口径不一致引发的资损问题这是我从头到尾踩过的最深的一个坑。公司刚开始做霸王餐时订单服务判断“活动用户”用的是“注册时间小于30天”营销服务发券判断“活动用户”用的却是“未支付订单金额大于0”。这两个定义同时存在导致了严重的资损一批用户在下单时得到了免单资格但在领补贴券环节被判为不符补贴券发不出去用户找客服要说法客服只能手动补偿。资损不是被黑产薅走的是业务逻辑自己打架造成的。后来做解耦设计时我花了很多精力统一口径。把“新用户”这类关键定义收敛到用户服务中心由它维护一个标准解译器提供标准化的判定参数给所有下游。资格校验服务不再自己定义口径而是直接依赖用户服务中心返回的标准化字段。同时我在校验服务里加入了规则数据血缘的概念每次校验请求的结果都会记录是哪条规则、依据哪个数据源字段得出的结论并把这些信息随校验结果日志一并上报。线上一旦发现两边的判断结果不一致就可以直接翻出血缘记录看具体是哪边的数据源字段定义出现了偏差。这比让两个团队互相扯皮要高效得多。4.3 线上问题的排查链路与日志设计资格校验服务在线上的排查效率很大程度取决于日志设计得好不好。我自己的习惯是拒绝无脑打印设计了两类日志。第一类是校验主日志每个校验请求打一条包含activityId、userId、verifyId、规则执行结果列表、每个规则的执行耗时、最终结论和拒绝原因。日志格式固定为JSON方便接入日志平台做结构化检索。第二类是数据源调用日志每次调用下游服务都记录服务名、耗时、返回码以及本次校验请求关联的traceId。这样在排查“为什么某个规则的判断结果不对”的时候我可以直接通过traceId找到这个用户当时的风控数据、画像数据快照。这里分享一下排查慢校验问题的具体思路。线上反馈校验变慢我先看校验服务整体的P99耗时趋势图确认是某个时间段突然升高还是稳定平缓上升。突然升高大概率是某次活动配置变更引起的那就去查校验主日志里新增规则是哪个再查这条规则关联的数据源耗时。稳定平缓上升多半是数据量增长导致的比如参与频次表数据量太大或某个下游服务性能退化这时候按数据源调用日志里耗时TOP的服务逐个排查。一次典型的排查过程是观测到某活动校验耗时突然从100ms涨到500ms翻日志发现新增了一条“城市开放校验”的规则这个规则调用了画像服务的批量接口但画像服务这个接口存在缓存失效时的数据库慢查询。画像团队定位后确认是接口的一个字段没走索引加上索引后耗时恢复。整个过程不到半小时就定位到了根因就是因为日志里带了规则执行明细。4.4 一个活动上线的容量估算参考最后分享一次实际活动的容量估算过程供参考。那次霸王餐活动在周五晚高峰上线预估目标用户100万乐观预估峰值请求QPS在8000左右。按照单次校验平均耗时150ms计算单机可以支撑大概10核16G配置下200 QPS的稳定处理能力理论需要40台机器。但考虑到JVM GC暂停、日志写盘抖动和部分规则突发慢查询我按三倍冗余准备到了120台实际观察峰值QPS在6500左右时P99耗时稳定在220ms以内机器平均CPU使用率不到50%还是偏保守了。规则配置缓存需要的Redis容量也可以预判一下。当时线上大约有300个活动配置信息每个配置约2KB只需要不到1MB容量完全不是瓶颈。反而是用户画像、风控快照这类业务数据缓存容量比较大按每个用户1KB估算100万用户就是1GB要给Redis预留到5GB以上的内存再叠加上其他业务的占用才有安全感。容量估算这件事我踩过不少次亏。有一次图省事把规则配置和信息预热到本地内存活动上线后运营突改了3次规则配置本地缓存刷新延迟导致头几十秒用的是旧配置有小部分用户被误判。后期就改成只在配置变更时主动清空本地缓存强制下一次请求回源加载新配置这才彻底解决。结尾资格校验的解耦设计做到现在回头看最值得的不是省了多少代码量而是让整个业务链路的负责人回归了各自的职责边界。订单服务专注订单流转营销服务专注补贴发放校验服务专注规则判断数据源各自维护好数据质量。后续如果再上新的霸王餐玩法比如直播专场、门店专属、秒杀叠加只需要新增活动配置和规则数据代码层面的改动被压到了最小。最后再分享一个实用的设计习惯解耦不只是接口层面的拆分更是数据语义的统一。如果各个服务对“新用户”“活跃用户”“风险用户”的理解都没有拉齐再漂亮的架构也挡不住业务逻辑的相互打架。把口径标准化这一步做好了微服务架构下的资格校验才能真正做到可复用、易维护、扛得住流量冲击。