最近在实现一个类似于微博、网易云的消息中心模块。主要实现的功能是，将系统中的点赞、评论、@等消息做汇合。今天跟大家分享下，我们的设计和实现思路。
首先说明，我们目前是微服务的架构。所以本篇文章中对于消息中心的设计也是建立在微服务的基础上，消息中心与其他模块是互相独立的。
分析需求后，我们能会发现消息中心的角色如下图（以点赞消息为例）：
针对需求，我们有如下两种存储方案。
方案一：
消息表：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 表中的内容，有格式要求
综合实际的业务需求，建议大家使用方案二。因为在实际场景中，我们删除帖子或删除评论等操作，都需要影响到消息中的内容状态。方案二在更新内容上具有绝对优势。假如使用方案一，更新消息内容会是一件相当头疼的事情。
如果大家有疑问或有更好的建议，欢迎讨论~
