通知系统的设计（一）

web应用和移动app中，通知系统是一个独立并且重要的功能。为了规范化，也为了重用，我们把通知和站内信做成一个独立的服务，在开发中统一调用。需要说明的是，我这里考虑的主要是强关系的应用型系统，至于弱关系的系统处理起来可能略有不同。

分析

统一概念

消息的分类方法仁者见仁智者见智，根据我的理解分为系统消息（公告和应用产生的消息），用户之间的消息，动态。

系统消息：管理员发通告（没把管理员当人)；应用产生的提醒。

用户之间：私信（暂时不做，以后直接用im来实现）。

动态：动态和应用产生的消息有什么区别呢？为什么分开呢？我想主要是为了降低噪音，尤其对于应用型而言，有些动态对于用户来讲意义不大，而消息我们认为用户需要处理。如果是若关系型，两者可以合二为一。

通知的分类

如果是弱关系，例如sns的评论等，处理不处理没有任何关系；但是如果是强关系，例如关注、邀请或者oa的审批通知，如果不处理业务就停止了。对于这两种类型的通知如果混在一起，对于应用型的系统会有问题。但是如果用两个业务处理，无疑会很麻烦。所以在通知中增加分类，由应用来决定如何处理。

通知的订阅

[x]  免打扰------------------------------不影响收到消息，只是没有声音或者弹出气泡。

订单类                                      微信   邮件  短信

订单审批                                   [x]       [x]    [x]

订单出库                                   [x]      [x]    [x]

...................

通知的方式

用户得到通知的方式大致分 web、微信、短信、电子邮件、移动app、浏览器（谷歌）几种，根据用户的使用习惯，我们会支持web、微信、短信、移动app。v1我们主要考虑web和微信。

1、web

是最基本的，浏览器应用内默认的方式。

2、微信

一个应用会对应一个微信公众号，用户绑定微信后，可以收到微信消息。

技术处理

通知的聚合

聚合是一个技术活，如果消息量很大，那么聚合将会更加困难。聚合包括给某个人一个对象的消息合并成一条，例如张三、李四、王二评论了你的xxx消息；也包括一个人对你发的多条消息，张三给您发了n条私信。

思考再三，算了吧...

通知的用户处理

消息到达用户是第一，然后就是用户如何处理消息。如果是弱关系，那么点击了，就处理了；如果是强关系，需要一个动作表示已经处理完了，这点有点墨迹，但是对于应用型的系统而言还是有必要的。而且我想再墨迹一点，还要增加待处理状态。

未读->已读

未读（已读）->待处理->已读

点击就认为是已读；对于未读和已读的可以标记微待办理。即保证了用户操作的简单，又满足一些有条理人士的需求。

要有批量设置，给懒又有洁癖的人一个选择。

通知推送的技术选择

web

常用方式是轮询、长轮询、长连接。v1用轮询就可以了，实现简单，我们大部分应用都是面向B的，用户量都不大。

以后的章节为：UI设计（二）、对象设计（三）、数据库设计（四）