最近在實現一個類似於微博、網易雲的訊息中心模組。主要實現的功能是，將系統中的點贊、評論、@等訊息做匯合。今天跟大家分享下，我們的設計和實現思路。
首先說明，我們目前是微服務的架構。所以本篇文章中對於訊息中心的設計也是建立在微服務的基礎上，訊息中心與其他模組是互相獨立的。
分析需求後，我們能會發現訊息中心的角色如下圖（以點贊訊息為例）：
針對需求，我們有如下兩種儲存方案。
方案一：
訊息表：message。欄位如下： user_id【訊息歸屬使用者】，sender_id【傳送訊息的使用者】，src_type【訊息對應的內容來源】，src_id【帖子id】，action【動作】，content_json【內容】，create_time【訊息建立時間】
欄位說明：
src_type 與 src_id 主要用來標識該筆訊息的來源，點選進入詳情的時候需要用到。
action 欄位主要用於儲存操作的型別，用於區分該訊息是點贊還是評論還是其他型別。
content_json 欄位用來儲存該筆訊息展示時需要的所有內容，其中需要包括帖子內容，帖子圖片，帖子建立者等等資訊。
方案二：
訊息表：message。欄位如下：
user_id【訊息歸屬使用者】，sender_id【傳送資訊的使用者】，src_type【訊息對應的來源】，src_id【帖子id】，action【動作】，action_id【動作id】，create_time【訊息建立時間】
action_id 欄位主要用來查詢動作的內容。當動作是點贊或評論時，不需要存該欄位。當動作是評論時，通過該欄位可以到訊息內容表中取值。
訊息內容表：message_content，欄位如下：
src_type【內容來源：帖子，評論等】，src_id【內容id】，content【內容】，status【內容狀態】
有人可能會奇怪，為何需要 message_content 表？其實一開始我們就有提到過，我們是微服務的架構。訊息中心與其他模組是相互獨立的，所以訊息中心不會去各模組取值，也不應該去各模組取值，它是一個相對獨立的模組。所以就需要有一個內容庫去儲存我們系統中的內容。方案一中的 content_json 欄位，之所以需要存這麼多的內容，也是同理。
接下來我們看一下兩個方案的對比情況。
方案一：
優勢：1.擴充性高，無論何種訊息都可以扔進 message 表裡 2.與其他專案的耦合度低 劣勢：1.更新動作複雜 2.冗餘資料較多
方案二： 優勢：1.更新動作簡單 2.與其他專案的耦合度低 劣勢：1.擴充性較低，對存入 message_content 表中的內容，有格式要求
綜合實際的業務需求，建議大家使用方案二。因為在實際場景中，我們刪除帖子或刪除評論等操作，都需要影響到訊息中的內容狀態。方案二在更新內容上具有絕對優勢。假如使用方案一，更新訊息內容會是一件相當頭疼的事情。
如果大家有疑問或有更好的建議，歡迎討論~