← 返回項目列表
業務服務
通知與 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: 員工不該看到供應商的原始錯誤，新進員工上線也不該需要在供應商端手動設定。
技術決策
| 技術決策 | 選擇 | 替代方案 | 原因 |
|---|---|---|---|
| 最近聯繫清單 | 由事件維護的反正規化讀取模型 | 查詢時彙總通話紀錄 | 讀取遠比通話頻繁，而且清單需要橫跨身分資料的篩選條件。 |