CASE 02 / ENGINEERING IN DETAIL
集团营销触达平台
用 Kafka 承接请求，用规则链组织校验，再按渠道分发。
问题与约束
集团业务通过 IVR、短信、Push 和机器人触达用户。请求可能集中到达，各渠道的配额和处理速度却不同。我负责平台架构与核心开发，重点处理异步请求、规则组合和供应商接入。
核心链路简化示意
以下图示为技术思路的简化表达。
- 01 / 请求承接Kafka 异步处理
- 02 / 规则组织过滤、限流与校验
- 03 / 渠道策略渠道类别与供应商选择
- 04 / 发送处理渠道接入与异常处理
架构取舍与实现
Kafka 缓冲集中到达的请求
难点请求可能集中到达，而下游渠道有自己的处理节奏和接入限制。
方案使用 Kafka 异步处理触达请求，将业务请求的受理与下游执行分开组织，缓解集中流量对后续链路的冲击。
考虑请求受理与渠道发送可以按各自速度处理；队列只能暂存速度差，仍需结合积压和渠道配额检查消费能力。
用责任链组合校验规则
难点黑名单、流量限制、号码获取和模板要求混在一起，会让规则变化难以管理。
方案主导规则引擎开发，用责任链组织黑名单过滤、流量限流、手机号获取、批次拆分和模板校验，按业务场景组合处理职责。
考虑业务场景可选择需要的规则；调整组合时仍需检查先后顺序，以及号码获取、拆批和模板校验的数据依赖。
在渠道层处理供应商选择
难点不同渠道与短信供应商涉及运营商、权重、额度和不可用通道等差异。
方案按渠道类别解析输入并通过渠道策略分发；短信供应商选择考虑运营商、权重和发送配额，无可用通道时进入配置对应的异常处理。
考虑上层按渠道提交请求，运营商匹配、供应商权重和配额检查留在渠道实现中处理。
这套设计解决了什么
实现 Kafka 异步请求处理、责任链规则引擎和多渠道接入，短信分发按运营商、权重与配额选择供应商。
验证关注点
- 集中请求进入后，队列积压、消费速度与渠道配额是否能够对应检查？
- 规则组合改变时，过滤、批次拆分和模板校验是否保持预期语义？
- 供应商额度不足或无可用通道时，是否进入明确的异常处理路径？
我的职责
负责平台架构与核心开发，主导规则引擎开发，对接第三方消息服务并处理渠道接入和推送问题。