小雨傘已上線的觸達系統 https://mp.weixin.qq.com/s/wItL0k8oHOqF0_LlEctrRw 在過去一年裏，經過多次迭代，已經基本達到當時系統設計的目標。隨着業務接入的增多，也引來了我的一些思考。
當前觸達系統工作模式
觸達系統將要面臨的挑戰
1.隨着大量業務的接入，對於觸達的消費速度會面臨一定挑戰，當然可以通過簡單的擴展 消費進程或者直接加機器橫向擴展可以解決。
2.觸達系統作爲基礎業務，對於增加觸達類型多等操作，存在更大的風險，事故的影響範圍會越來越大，解耦服務及如何在不影響現有服務的情況下新增功能或消息類型會變得更重要。
3.如何更有效的利用系統資源，現有的進程模式相對線程、協程而言,佔用更多系統資源(內存，cpu)，且隨進程增加會越來越明顯(花在上下文切換時間越來越多)，系統資源利用率不高。
4.無法做到對某種消息的單獨擴展。比如客服消息的使用量大，而郵件的使用量相比客服消息小很多，如果要擴展，在現有模式下，只能整體擴展，無法單獨擴展客服消息的消費者，以提高某種消息類型的消費速度。同時各種消息類型單位時間內處理消息的條數存在差異。
5.redis作爲消息隊列實現，無法實現消費確認機制，會存在消息丟失的可能，且在併發速度上，無法和專業的MQ軟件到達相同的併發數量級。
觸達系統改進的想法
1.在不改變現有觸達系統的功能和協議的情況下，改進消費者的實現方式。
2.公司現有的基礎支撐
ETCD 支撐實現服務註冊和服務發現
RabbitMQ 代替 redis 實現更高量級的消費速度和消息可靠性
go 語言的推廣，go協程模式可實現更少的資源佔有和更高的併發速度
3.系統業務架構圖：
系統主要分以下角色
- Receiver 服務接收由於接口發送的消息協議，並解析發送到對應消息服務的隊列中。
- Consumer 負責消費消息，將消息發送到客戶端。
- Alarm System 告警系統(需要更多業務思考)
優化目的
- 解耦每種消息消費者並實現新消息類型服務註冊與服務發現。做到在不影響現有系統的情況下擴展功能。
- 實現不同消息的並行消費和水平擴展。
- 更換消息隊列模式，實現消息可靠傳遞與消費
- 減少資源使用提高消費速度。
- 建立觸達監控機制
初版觸達系統方案地址：https://mp.weixin.qq.com/s/wItL0k8oHOqF0_LlEctrRw