1. 项目概述LiteFlow引擎与短信自动化的完美结合在当今企业级应用开发中业务流程的灵活编排和自动化执行已成为刚需。最近我在一个会员通知系统中成功落地了LiteFlow工作流引擎来实现短信自动化发送这种轻量级解决方案相比传统硬编码方式展现出惊人的灵活性和可维护性。LiteFlow作为国产优秀的工作流引擎框架其基于流程图的编排能力和热更新特性特别适合像短信发送这类需要频繁调整业务规则的场景。这个项目的核心目标是通过配置化的方式实现以下功能根据不同的业务事件如订单支付、物流更新、账户变动触发短信发送动态决定短信模板、接收人群和发送渠道实现发送失败后的自动重试和补偿机制避免短信轰炸风险内置流控和频次限制提示选择LiteFlow而非Activiti/Flowable这类重型引擎主要考量是其学习成本低、接入简单对于短信发送这种中等复杂度的业务流程恰到好处。2. 技术选型与架构设计2.1 为什么选择LiteFlow在技术选型阶段我们对比了多种工作流引擎方案引擎类型优点缺点适用场景LiteFlow轻量级、热部署、学习曲线平缓复杂流程支持有限中小型业务规则编排Flowable功能强大、BPMN标准支持资源消耗大、需要数据库支持复杂审批流自研状态机完全可控、性能优异开发成本高、难以维护简单固定流程Spring Statemachine声明式编程、Spring生态整合复杂流程配置繁琐状态明确的业务流最终选定LiteFlow的核心原因有三点热更新能力短信模板和发送规则经常需要调整LiteFlow支持在不重启服务的情况下修改流程逻辑可视化编排通过EL表达式或图形界面就能定义流程运营人员经过培训后可以自主调整轻量级架构作为嵌入式引擎运行不需要额外部署流程服务降低运维复杂度2.2 系统架构设计整个短信自动化系统的架构分为四层[触发层] → [规则引擎层] → [执行层] → [监控层] │ │ │ │ │ │ │ │ 事件驱动 LiteFlow 短信服务商 Prometheus (DB变更/API) 流程编排 (阿里云/腾讯云) Grafana关键组件说明触发层通过数据库变更监听Debezium或HTTP API接收业务事件规则引擎层LiteFlow解析流程定义执行条件判断和分支路由执行层对接多个短信服务商API实现故障自动转移监控层实时统计发送成功率、延迟等指标触发告警3. 核心实现细节3.1 流程定义与节点开发LiteFlow的核心概念是链式流程我们将短信发送拆解为以下几个原子节点chain namesmsFlow then valueparamValidate/ !-- 参数校验 -- then valueriskControl/ !-- 风控检查 -- then valuetemplateSelect/ !-- 模板选择 -- then valuechannelRouter/ !-- 渠道路由 -- then valuerealSend/ !-- 实际发送 -- then valueresultRecord/ !-- 结果记录 -- /chain每个节点需要实现NodeComponent接口例如风控检查节点的实现LiteflowComponent(riskControl) public class RiskControlNode extends NodeComponent { Override public void process() { SmsContext context this.getContextBean(SmsContext.class); // 检查接收人是否在黑名单 if(blacklistService.isBlocked(context.getMobile())){ throw new RuntimeException(手机号在黑名单中); } // 检查当日发送频次 int todayCount smsLogService.getTodayCount(context.getMobile()); if(todayCount 5) { this.setIsEnd(true); // 终止流程 context.setResult(超过每日发送限制); } } }3.2 关键配置详解在liteflow.properties中需要重点配置以下参数# 流程定义文件位置 liteflow.rule-sourceconfig/sms-rule.xml # 是否开启监控日志 liteflow.monitor.enable-logtrue liteflow.monitor.queue-limit200 # 并行线程池配置 liteflow.when-max-wait-seconds15 liteflow.when-max-workers10 liteflow.when-queue-limit5000 # 热刷新间隔秒 liteflow.polling-delay30注意生产环境建议将规则配置存储在数据库或配置中心而非本地文件避免集群节点间配置不一致。3.3 短信发送的容错设计在实际运行中我们遇到最多的三个问题及其解决方案服务商接口超时为realSend节点配置重试策略node idrealSend typesms_send retry3 retryInterval2000/多服务商故障转移逻辑private SmsProvider getAvailableProvider() { for (SmsProvider provider : providers) { if(healthChecker.isHealthy(provider)){ return provider; } } throw new RuntimeException(所有服务商不可用); }模板变量渲染失败使用安全的渲染方式String renderedContent StrSubstitutor.replace( template, params, new StrMatcher(${, }));突发流量导致队列积压在流程入口添加流控节点if(!rateLimiter.tryAcquire()) { throw new BusyException(系统繁忙请稍后重试); }4. 性能优化实践4.1 批量发送处理当需要批量发送短信时如活动通知原始的单条处理模式会导致性能瓶颈。我们通过以下改造实现批量优化在流程定义中增加批量模式分支chain namebatchSmsFlow then valuebatchSplit/ !-- 将大批量拆分为小批次 -- when valueparallelSend/ !-- 并行发送 -- then valuebatchAggregate/ !-- 汇总结果 -- /chain实现并行发送节点Override public void process() { ListSmsTask batch this.getContextBean(SmsContext.class).getBatchTasks(); ListCompletableFutureSendResult futures batch.stream() .map(task - CompletableFuture.supplyAsync( () - smsService.send(task), parallelExecutor)) .collect(Collectors.toList()); ListSendResult results futures.stream() .map(CompletableFuture::join) .collect(Collectors.toList()); this.getContextBean(SmsContext.class).setBatchResults(results); }4.2 缓存优化通过多级缓存提升模板获取效率本地缓存使用Caffeine缓存高频模板CacheString, Template templateCache Caffeine.newBuilder() .maximumSize(1000) .expireAfterWrite(5, TimeUnit.MINUTES) .build();分布式缓存Redis存储全量模板数据Cacheable(value smsTemplates, key #templateId) public Template getTemplate(String templateId) { return templateMapper.selectById(templateId); }降级策略当缓存失效时使用默认模板public Template getTemplateWithFallback(String templateId) { try { return templateCache.get(templateId, id - redisTemplate.opsForValue().get(template:id)); } catch (Exception e) { return defaultTemplate; } }5. 监控与运维5.1 埋点设计在关键节点添加监控指标// 使用Micrometer指标 Counter.builder(sms.flow.count) .tag(chain, chainName) .register(meterRegistry) .increment(); Timer.builder(sms.node.time) .tag(node, nodeId) .register(meterRegistry) .record(() - node.process());5.2 告警规则配置在Grafana中设置关键告警成功率告警sum(rate(sms_send_total{statusfailed}[5m])) by (channel) / sum(rate(sms_send_total[5m])) by (channel) 0.05延迟告警histogram_quantile(0.9, sum(rate(sms_node_duration_seconds_bucket[5m])) by (le, node) ) 3积压告警sms_pending_tasks 10005.3 日志追踪通过MDC实现全链路日志追踪public abstract class BaseNode extends NodeComponent { Override public void process() { MDC.put(traceId, this.getRequestId()); try { doProcess(); } finally { MDC.clear(); } } protected abstract void doProcess(); }日志格式示例2023-08-20 14:30:45 [INFO] [traceIdabcd123] [noderiskControl] 风控检查通过 mobile138001380006. 踩坑经验与最佳实践6.1 五个关键教训流程拆分粒度错误做法把整个发送逻辑写在一个大节点中正确做法按照单一职责原则拆分节点每个节点只做一件事经验值每个节点的执行时间控制在50-300ms为宜上下文设计反模式在各个节点间通过Map传递参数推荐方案定义强类型的Context对象Data public class SmsContext { private String mobile; private String eventType; private String templateId; private MapString, Object params; private String channel; private String result; // getters/setters... }异常处理必须区分的异常类型业务异常直接终止流程可重试异常触发重试机制系统异常告警并人工介入测试策略单元测试覆盖每个节点的各种分支流程测试验证完整链路执行顺序压力测试验证线程池配置是否合理版本控制流程定义文件必须纳入Git管理每次变更记录修改原因和影响范围生产环境启用审核发布机制6.2 三个性能优化技巧预热加载PostConstruct public void preload() { FlowBus.reloadRule(); templateCache.putAll(templateService.loadHotTemplates()); }并行优化!-- 当多个节点没有先后依赖时使用并行 -- when paralleltrue node valuecreditCheck/ node valuemarketingTag/ /when懒加载Lazy Autowired private ExpensiveService expensiveService;7. 扩展应用场景基于LiteFlow的短信自动化框架经过验证后我们进一步扩展到了以下场景多通道通知在短信发送失败时自动切换邮件/站内信chain namemultiChannelNotify then valuesmsSend/ when valuecheckResult/ then valuefallbackChannel on-errortrue/ /chain营销自动化结合用户行为事件触发个性化营销用户浏览商品 → 加入购物车 → 30分钟未支付 → 触发优惠券短信验证码服务统一管理各类验证码的发送和校验public boolean verifyCode(String mobile, String code) { return codeCache.getIfPresent(mobile_sms) ! null; }这套方案上线后短信发送的运维效率提升了60%业务规则变更的响应时间从小时级降到分钟级日均稳定处理百万级短信发送请求。最重要的是它让业务团队获得了自主调整流程的能力真正实现了配置即开发的理想状态。
1. 项目概述LiteFlow引擎与短信自动化的完美结合在当今企业级应用开发中业务流程的灵活编排和自动化执行已成为刚需。最近我在一个会员通知系统中成功落地了LiteFlow工作流引擎来实现短信自动化发送这种轻量级解决方案相比传统硬编码方式展现出惊人的灵活性和可维护性。LiteFlow作为国产优秀的工作流引擎框架其基于流程图的编排能力和热更新特性特别适合像短信发送这类需要频繁调整业务规则的场景。这个项目的核心目标是通过配置化的方式实现以下功能根据不同的业务事件如订单支付、物流更新、账户变动触发短信发送动态决定短信模板、接收人群和发送渠道实现发送失败后的自动重试和补偿机制避免短信轰炸风险内置流控和频次限制提示选择LiteFlow而非Activiti/Flowable这类重型引擎主要考量是其学习成本低、接入简单对于短信发送这种中等复杂度的业务流程恰到好处。2. 技术选型与架构设计2.1 为什么选择LiteFlow在技术选型阶段我们对比了多种工作流引擎方案引擎类型优点缺点适用场景LiteFlow轻量级、热部署、学习曲线平缓复杂流程支持有限中小型业务规则编排Flowable功能强大、BPMN标准支持资源消耗大、需要数据库支持复杂审批流自研状态机完全可控、性能优异开发成本高、难以维护简单固定流程Spring Statemachine声明式编程、Spring生态整合复杂流程配置繁琐状态明确的业务流最终选定LiteFlow的核心原因有三点热更新能力短信模板和发送规则经常需要调整LiteFlow支持在不重启服务的情况下修改流程逻辑可视化编排通过EL表达式或图形界面就能定义流程运营人员经过培训后可以自主调整轻量级架构作为嵌入式引擎运行不需要额外部署流程服务降低运维复杂度2.2 系统架构设计整个短信自动化系统的架构分为四层[触发层] → [规则引擎层] → [执行层] → [监控层] │ │ │ │ │ │ │ │ 事件驱动 LiteFlow 短信服务商 Prometheus (DB变更/API) 流程编排 (阿里云/腾讯云) Grafana关键组件说明触发层通过数据库变更监听Debezium或HTTP API接收业务事件规则引擎层LiteFlow解析流程定义执行条件判断和分支路由执行层对接多个短信服务商API实现故障自动转移监控层实时统计发送成功率、延迟等指标触发告警3. 核心实现细节3.1 流程定义与节点开发LiteFlow的核心概念是链式流程我们将短信发送拆解为以下几个原子节点chain namesmsFlow then valueparamValidate/ !-- 参数校验 -- then valueriskControl/ !-- 风控检查 -- then valuetemplateSelect/ !-- 模板选择 -- then valuechannelRouter/ !-- 渠道路由 -- then valuerealSend/ !-- 实际发送 -- then valueresultRecord/ !-- 结果记录 -- /chain每个节点需要实现NodeComponent接口例如风控检查节点的实现LiteflowComponent(riskControl) public class RiskControlNode extends NodeComponent { Override public void process() { SmsContext context this.getContextBean(SmsContext.class); // 检查接收人是否在黑名单 if(blacklistService.isBlocked(context.getMobile())){ throw new RuntimeException(手机号在黑名单中); } // 检查当日发送频次 int todayCount smsLogService.getTodayCount(context.getMobile()); if(todayCount 5) { this.setIsEnd(true); // 终止流程 context.setResult(超过每日发送限制); } } }3.2 关键配置详解在liteflow.properties中需要重点配置以下参数# 流程定义文件位置 liteflow.rule-sourceconfig/sms-rule.xml # 是否开启监控日志 liteflow.monitor.enable-logtrue liteflow.monitor.queue-limit200 # 并行线程池配置 liteflow.when-max-wait-seconds15 liteflow.when-max-workers10 liteflow.when-queue-limit5000 # 热刷新间隔秒 liteflow.polling-delay30注意生产环境建议将规则配置存储在数据库或配置中心而非本地文件避免集群节点间配置不一致。3.3 短信发送的容错设计在实际运行中我们遇到最多的三个问题及其解决方案服务商接口超时为realSend节点配置重试策略node idrealSend typesms_send retry3 retryInterval2000/多服务商故障转移逻辑private SmsProvider getAvailableProvider() { for (SmsProvider provider : providers) { if(healthChecker.isHealthy(provider)){ return provider; } } throw new RuntimeException(所有服务商不可用); }模板变量渲染失败使用安全的渲染方式String renderedContent StrSubstitutor.replace( template, params, new StrMatcher(${, }));突发流量导致队列积压在流程入口添加流控节点if(!rateLimiter.tryAcquire()) { throw new BusyException(系统繁忙请稍后重试); }4. 性能优化实践4.1 批量发送处理当需要批量发送短信时如活动通知原始的单条处理模式会导致性能瓶颈。我们通过以下改造实现批量优化在流程定义中增加批量模式分支chain namebatchSmsFlow then valuebatchSplit/ !-- 将大批量拆分为小批次 -- when valueparallelSend/ !-- 并行发送 -- then valuebatchAggregate/ !-- 汇总结果 -- /chain实现并行发送节点Override public void process() { ListSmsTask batch this.getContextBean(SmsContext.class).getBatchTasks(); ListCompletableFutureSendResult futures batch.stream() .map(task - CompletableFuture.supplyAsync( () - smsService.send(task), parallelExecutor)) .collect(Collectors.toList()); ListSendResult results futures.stream() .map(CompletableFuture::join) .collect(Collectors.toList()); this.getContextBean(SmsContext.class).setBatchResults(results); }4.2 缓存优化通过多级缓存提升模板获取效率本地缓存使用Caffeine缓存高频模板CacheString, Template templateCache Caffeine.newBuilder() .maximumSize(1000) .expireAfterWrite(5, TimeUnit.MINUTES) .build();分布式缓存Redis存储全量模板数据Cacheable(value smsTemplates, key #templateId) public Template getTemplate(String templateId) { return templateMapper.selectById(templateId); }降级策略当缓存失效时使用默认模板public Template getTemplateWithFallback(String templateId) { try { return templateCache.get(templateId, id - redisTemplate.opsForValue().get(template:id)); } catch (Exception e) { return defaultTemplate; } }5. 监控与运维5.1 埋点设计在关键节点添加监控指标// 使用Micrometer指标 Counter.builder(sms.flow.count) .tag(chain, chainName) .register(meterRegistry) .increment(); Timer.builder(sms.node.time) .tag(node, nodeId) .register(meterRegistry) .record(() - node.process());5.2 告警规则配置在Grafana中设置关键告警成功率告警sum(rate(sms_send_total{statusfailed}[5m])) by (channel) / sum(rate(sms_send_total[5m])) by (channel) 0.05延迟告警histogram_quantile(0.9, sum(rate(sms_node_duration_seconds_bucket[5m])) by (le, node) ) 3积压告警sms_pending_tasks 10005.3 日志追踪通过MDC实现全链路日志追踪public abstract class BaseNode extends NodeComponent { Override public void process() { MDC.put(traceId, this.getRequestId()); try { doProcess(); } finally { MDC.clear(); } } protected abstract void doProcess(); }日志格式示例2023-08-20 14:30:45 [INFO] [traceIdabcd123] [noderiskControl] 风控检查通过 mobile138001380006. 踩坑经验与最佳实践6.1 五个关键教训流程拆分粒度错误做法把整个发送逻辑写在一个大节点中正确做法按照单一职责原则拆分节点每个节点只做一件事经验值每个节点的执行时间控制在50-300ms为宜上下文设计反模式在各个节点间通过Map传递参数推荐方案定义强类型的Context对象Data public class SmsContext { private String mobile; private String eventType; private String templateId; private MapString, Object params; private String channel; private String result; // getters/setters... }异常处理必须区分的异常类型业务异常直接终止流程可重试异常触发重试机制系统异常告警并人工介入测试策略单元测试覆盖每个节点的各种分支流程测试验证完整链路执行顺序压力测试验证线程池配置是否合理版本控制流程定义文件必须纳入Git管理每次变更记录修改原因和影响范围生产环境启用审核发布机制6.2 三个性能优化技巧预热加载PostConstruct public void preload() { FlowBus.reloadRule(); templateCache.putAll(templateService.loadHotTemplates()); }并行优化!-- 当多个节点没有先后依赖时使用并行 -- when paralleltrue node valuecreditCheck/ node valuemarketingTag/ /when懒加载Lazy Autowired private ExpensiveService expensiveService;7. 扩展应用场景基于LiteFlow的短信自动化框架经过验证后我们进一步扩展到了以下场景多通道通知在短信发送失败时自动切换邮件/站内信chain namemultiChannelNotify then valuesmsSend/ when valuecheckResult/ then valuefallbackChannel on-errortrue/ /chain营销自动化结合用户行为事件触发个性化营销用户浏览商品 → 加入购物车 → 30分钟未支付 → 触发优惠券短信验证码服务统一管理各类验证码的发送和校验public boolean verifyCode(String mobile, String code) { return codeCache.getIfPresent(mobile_sms) ! null; }这套方案上线后短信发送的运维效率提升了60%业务规则变更的响应时间从小时级降到分钟级日均稳定处理百万级短信发送请求。最重要的是它让业务团队获得了自主调整流程的能力真正实现了配置即开发的理想状态。
