← 返回项目列表
业务服务
通知与 CRM 服务
公告、站内信箱与呼叫中心 CRM 后端
重构通知服务 · 从零构建 CRM 集成 · 最大贡献者 · 2024.10 — 2026.01
Go go-zero gRPC MySQL/GORM Kafka REST
8
设计表数
15
RPC 接口数
项目背景
呼叫中心人员按“最近联系时间”排序的客户列表逐一跟进。每次查看列表都聚合通话历史无法扩展，而客户数据本身又存放在身份服务中。
架构设计
后台 → 网关（客户触达 API + 服务商客户端）→ 客户触达 gRPC 服务 → MySQL。身份服务事件（注册、手机号变更、状态变更）→ Kafka 消费者 → 以事务方式更新最近联系记录行。公告：发布 → Kafka → WebSocket 服务 → 已连接的客户端。
核心技术亮点
01
重构公告与站内信：多语言内容、按用户分组定向、逐用户已读状态与未读计数、通过 Kafka 和 WebSocket 实时推送
02
从零构建客户触达后端：基于 8 张表（坐席、通话与短信记录、设置）的 15 个 gRPC 接口
03
23 个后台管理接口，以及对接云联络中心与短信服务商的签名 REST 客户端，支持自动创建坐席组
04
“每位客户最近一次联系”读模型，通过 Kafka 用户事件保持同步，带重试与死信 Topic，并以事务方式写入
05
读模型在线回填：建临时索引 → INSERT … SELECT … ON DUPLICATE KEY UPDATE → 删除索引
核心实现
1
事件驱动的读模型
每位客户一行，记录其最近一次通话和短信；注册时创建，手机号或状态变更时重置，并与每条通话记录在同一事务中更新。
Why: 列表页面每位客户只读一行，无需聚合历史；数据也无需同步调用即可跟随身份服务更新。
2
服务商集成
通用的签名 REST 客户端，将服务商错误码映射为本地化的平台错误，并在当前坐席组已满时自动创建新的坐席组。
Why: 员工不应看到服务商的原始错误；新员工入职也不应需要在服务商侧手动配置。
技术决策
| 技术决策 | 选择 | 替代方案 | 原因 |
|---|---|---|---|
| 最近联系列表 | 由事件维护的反范式读模型 | 查询时聚合通话历史 | 读取远比通话频繁，而且列表需要跨身份数据的筛选条件。 |