最近接手一个企微二次开发项目，业务方要求"新客户加好友后发欢迎语、三天没说话推一条产品介绍、咨询过产品没下单的七天后跟进"——这种带时序、带条件、带多步骤的流程，硬编码写一周能跑，改流程再写一周。两个多月折腾下来，最终落地的不是某个工作流引擎，是一套"配置化迁移"的工程方法。Eyun 平台开放的企微 API，消息收发和客户管理这些原子能力走它，本文重点不在调接口，在"怎么把写死的业务流程变成可配置"。
先判断什么该配置化
不是所有流程都该配置化。判断标准几条：
-
流程步骤会频繁变（运营要调时序、加分支）
-
多个客户群走类似但不同的路径（个性化）
-
业务方想自助调整不想排研发档期
-
流程上线后要灰度、要回滚
四条都满足才上配置化。只满足一两条的，硬编码反而稳——配置化的复杂度不值得。最早我们想把所有流程都配置化，结果一些一年改一次的流程也搞了配置表，维护成本远超收益。
配置化的三个层次
配置化不是一刀切，分三层，按需上：
参数化：流程结构写死，只暴露参数。比如欢迎语文案、推送时间、跟进天数。改这些不用发版，运营后台改字段即可。
规则化：流程步骤固定，但分支条件可配。比如"咨询过产品的客户七天后跟进"——什么算"咨询过"、跟进谁、跟进什么内容，规则表里定义。
流程化：步骤本身可编排。加分支、加步骤、改顺序都靠配置。这才是真正的工作流配置。
三层从简到繁，能用第一层就不上第三层。一上来就流程化等于自建工作流平台，成本爆炸。
配置存储：不要全塞 key-value
最早图省事，所有配置塞一张 key-value 表，value 是大 JSON。跑两周问题一堆：JSON 改一个字段要整体覆盖、没法做字段级审计、查询只能整串读、热加载要整串解析。
后来按配置类型分表：
param_config 表: 参数化配置（key、value、scope、version）
rule_config 表: 规则配置（rule_id、condition、action、priority、enabled）
flow_config 表: 流程配置（flow_id、version、nodes、edges、trigger）
分表后字段级查询、增量更新、独立审计都好做。流程配置这种复杂的单独建表，nodes 和 edges 用 JSON 存但加版本号和作者字段。
热加载和缓存一致性
配置不能每次现读库，要缓存。但缓存带来一致性问题——运营改了配置，服务还用老的。
落地方案：本地缓存 + 版本号轮询。每分钟拉一次配置版本号，版本号变了才拉全量。改配置时版本号自增，最多一分钟内全网生效。紧急情况下有强制刷新接口，手动触发。
踩过坑：最早用 TTL 失效缓存，配置量大时 TTL 到期瞬间所有节点同时回源，数据库被打挂。改成版本号轮询后再没出过问题。
回滚和灰度
配置改错比代码改错更危险——代码改错发版有 review，配置改错运营点个保存就生效。必须支持回滚。
每个配置带 version 字段，历史版本留存。回滚就是切回旧 version。灰度按客户 ID 哈希分配 version，10% 客户走新配置、90% 走旧配置，稳定后全量切。
代码示意：
def load_config(flow_id, customer_id):
version = pick_version(flow_id, customer_id) # 灰度路由
return config_store.get(flow_id, version)
def pick_version(flow_id, customer_id):
rollout = rollout_store.get(flow_id)
if rollout and rollout.enabled:
bucket = hash(customer_id) % 100
if bucket < rollout.percentage:
return rollout.new_version
return rollout.base_version
dry-run：上线前必做
配置改完直接上生产等于裸奔。必须有 dry-run 模式：用真实事件样本跑一遍新配置，看会触发什么动作、走到哪个节点，但不真正执行。
我们做了一个回放后台：选一段时间内的事件，用新配置重放，输出每个事件的执行路径对比老配置的差异。差异点人工 review，没问题才上。
不做 dry-run 上线必出事故。曾经运营把"咨询过产品"的条件从"7天内"改成"30天内"，没 dry-run 直接上，结果几万个沉睡客户被一次性激活跟进，客服当天被客户消息淹没。
配置治理
配置化不是运营想改就改。要建立治理：
-
改配置要走 review（同代码 review）
-
改完有审计日志（谁、什么时候、改了什么、为什么）
-
关键配置（涉及金额、客户外发）要二次审批
-
配置变更有通知（改完推群里让相关人知道）
这套不建起来，配置化就是给运营发了把自由改业务的钥匙，出事找不到人。
写在最后
可配置工作流的本质不是搭一个 DSL 引擎，是把"业务流程"从代码里一层层剥出来变成可管理的配置资产。判断什么该配置、分层上、存储分表、热加载版本号、回滚灰度、dry-run、治理——每一项都不深奥，但少做一项配置化就跑不稳。这套做扎实，运营调流程不再排研发档期，研发精力才真正放在能力建设而不是改业务路径上。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/2603_96320844/article/details/166367927
