目標

研發一套獨立的消息系統，此系統進行集中配置管理供各業務系統使用，用于支撐站內信、短信通知、短信驗證碼、郵件、微信消息、APP消息、IM等消息形式。

?

架構

?

?

1） 基于消息隊列采用發布、訂閱模式。消息的生產者為對外的消息接口，接收業務系統消息后將消息寫入到消息隊列指定的topic，訂閱者對消息進行處理并行的發送消息。

2） 所有通知消息定義唯一“消息ID”來標識消息類型。

3） 通知消息由各消息模塊（短信、郵件、站內信、微信、APP）自己負責本消息的發送，去讀取消息節點配置信息，根據當前的消息ID判斷自己是否需要發送消息，是則發送否則丟棄。

4） 消息體，消息體采用JSON報文格式，方便各系統之間對接。

?

消息數據定義

?

?

?

{

? msghead:

{

? msgtype:””,

? msgid:””,

? rcvuid:””,

? rcvcid:””,

? rcvmobile:””,

? rcvemail:””,

? time:””,

? system:””

? }

? ,

? msgbody:

? {

text:””,

noticemsg:””,

wxmsg:””,

appmsg:””,

immsg:””,

smsmsg:[{},{}]

? }

}

?

?

字段	說明	值
msghead	消息頭	?
?Msgtype	消息類型	消息類型：notice/sms/email/im/wx
?Msgid	消息id	定義全局唯一
?Rcvuid	接收帳號id	?
?Rcvcid	接收公司id	?
?Rcvmobile	接收手機號	?
?Rcvemail	接收郵箱	?
?Time	發送時間	?
?System	發送系統模塊	云倉
Msgbody	消息體	?
?Text	文本消息內容	?
?Noticemsg	站內信消息內容	?
?Wxmsg	微信消息內容	?
?Appmsg	APP消息內容	?
?Immsg	IM消息內容	?
?Smsmsg	短信消息內容	標簽->值數組，供短信模板使用

?

?

?

項目結構

?

消息接口API（msg_api）

1） 負責接收業務系統發送消息請求，將消息寫到消息隊列中；

2） 提供接口供業務系統查詢，如查詢用戶的站內信消息列表、查詢驗證碼是否正確等；

3） 提供數據接口供管理平臺使用，如配置信息發送結點；

?

?

短信處理程序（msg_handle_sms）

1） 負責訂閱消息，讀取消息進行短信發送；

2） 負責驗證碼的生成處理；

3） 數據操作調用消息接口API；

4） 通知消息需要讀取配置信息決定當前消息發送或丟棄；

?

?

郵件處理程序（msg_handle_email）

1） 負責訂閱消息，讀取消息進行郵件發送；

2） 數據操作調用消息接口API；

3） 通知消息需要讀取配置信息決定當前消息發送或丟棄；

?

?

站內信處理程序(msg_handle_notice)

1） 負責訂閱消息，讀取消息進行通知；

2） 通知消息需要讀取配置信息決定當前消息發送或丟棄；

3） 數據操作調用消息接口API；

?

數據庫

1） 使用一個消息數據庫；

2） 數據庫表分為短信模塊、站內信模塊、IM模塊（暫不做）、通知信息配置模塊；

轉載于:https://www.cnblogs.com/assion/p/7741562.html

總結

以上是生活随笔為你收集整理的最近重构公司消息服务的架构设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。