客户分群与会员忠诚度服务
客户分群、会员等级返现与合作伙伴返利配置
项目背景
每个租户都希望根据客户行为（例如充值金额）区别对待客户，并能自行配置。用户一注册就必须分配分群，还要定期针对每个租户和币种重新评估，并支持带审计记录的手动调整。
架构设计
管理 API（网关）→ 客户分群 gRPC 服务 → MySQL（配置、分配、历史、策略表）。身份服务的注册事件 → Kafka 消费者 → 默认分配。定时任务服务中的每日 Temporal 工作流 → 按租户/币种的子工作流 → 分类结果发布到 Kafka → 由带重试和死信 Topic 的消费者写入。
核心技术亮点
从零构建客户分群：9 张表、28 个 gRPC 和 16 个 HTTP 接口，事务化配置并保证默认分群唯一，带快照的变更历史
新用户通过 Kafka 注册事件获得默认分群；基于滚动周期充值阈值的规则自动分类
每日运行的 Temporal 工作流对每个租户和币种重新分类，按租户拆分子工作流，activity 带心跳并分页执行
面向不限层级合作伙伴网络的返利配置：逐级费率、Redis 旁路缓存配合 pipeline 批量失效，以及产品启用时由 Kafka 驱动生成默认配置
幂等的返现记录消费者：由唯一索引保证的确定性键
核心实现
基于事件的默认分配
Kafka 消费者订阅用户注册和用户创建事件，为用户分配租户的默认分群，并配有重试与死信 Topic。
Why: 分群分配不能依赖注册请求中第二次写入的成功；事件驱动的分配让身份与分群保持解耦。
可续跑的重新分类
每日工作流列出所有租户，并为每个租户和币种启动一个子工作流。每个子工作流加载升级映射和降级策略，分页遍历用户并上报 activity 心跳，然后发布结果。
Why: 重新评估所有用户是长时间运行的任务；心跳和分页让 Temporal 可以重试或续跑单个子工作流，而无需重跑整个流程。
合作伙伴返利配置
面向不限层级合作伙伴网络的逐级费率规则，缓存在 Redis 中并按租户整体失效；查询时并行解析用户整条合作伙伴链路上的费率。
Why: 结算任务需要每个用户的完整链路；缓存和并行查询让这一过程开销很低。
技术决策
| 技术决策 | 选择 | 替代方案 | 原因 |
|---|---|---|---|
| 分类在哪里执行 | 由 Temporal 工作流执行，结果发布到 Kafka | 在客户分群服务内通过 cron 分类 | 按租户的长时间任务需要重试、可视化和可续跑能力；发布结果则让写入路径集中在一个消费者中。 |