ToB企服应用市场:ToB评测及商务社交产业平台

标题: 【办理方案】Java 互联网项目中消息关照系统的计划与实现（上） [打印本页]

作者: 泉缘泉 时间: 2024-6-19 07:24
标题: 【办理方案】Java 互联网项目中消息关照系统的计划与实现（上）
目录

媒介

消息关照系统（notification-system）作为一个独立的微服务，完整地负责了 App 端内全部消息关照相干的后端功能实现。该系统既需要与文章系统、订单系统、会员系统等相干联，也需要和其它业务系统相干联，是一个偏底层的通用服务系统。
App 端内的消息关照类型常见有这几项：评论关照、点赞关照、收藏关照、订单关照、活动关照、个人中心相干关照等。该系统在可拓展性、高性能、较高可用性、数据一致性等方面有较高要求，最终目的是提升用户粘性、加强 App 与用户的互动、支撑焦点业务的发展。
文章的（上）篇将从需求分析、数据模型计划、关键流程计划这 3 部门来阐明，（下）篇将从技术选型、后端接口计划、关键逻辑实现这 3 部门来进行阐明。
一、需求分析

主要从发送关照、撤回关照、关照消息数、关照消息列表这 4 个子需求来展开。
1.1发送关照

该操作一般由业务系统发出关照，业务系统包括了 App 端和管理后台这两种；
App 内的发起的关照一般由 App 用户即会员（member）自己来操作，如：在评论区回复评论，则其父评论的发布者需要收到评论回复关照；
管理后台发出的关照一般是管理员将某种类型（文本or图片等）的消息发送至 App 用户，如：某个活动的运营者在后台给 App 用户发送获奖关照。

1.2撤回关照

这是一个可选操作，一般也是由业务系统来操作，具相识由管理后台来完成，在 App 端一般较少有此类操作；
管理后台可以针对已经发送成功的关照进行单条撤回或者批量撤回，App 用户的关照列表和未读消息数将会随之变革。

1.3关照消息数

在App ”我的“模块，新增消息关照 icon，建议命名为”关照“；
当有新关照时表现 x 条新消息（红色数字），表现数字为该用户全部未读新消息数之和；
有新增一条未读消息时数目+1，撤回一条未读消息数目-1；
未读消息数需要与消息关照列表的未读消息数一致。

1.4关照消息列表

点击 “关照” icon后进入消息关照列表，根据关照类型分为不同的 tab 页；
列表展示该用户收到的全部消息关照，并按关照时间倒序展示；
新消息用红点标识，查看后退出的状态标记为已读，即红点会消失；
点击具体的消息，假如是链接，则支持跳转到对应地址；假如是图文，则支持查看；假如是文章，则支持跳转查看。

二、数据模型计划

该系统的数据模型分为两部门：数据库与缓存。其中对数据库的概念模型（E-R图）和逻辑模型（表计划）进行展开，对缓存的数据结构在关键逻辑实现章节会进一步阐明。
2.1概念模型

该系统目前计划为3张表，命名为：notification（关照纪录表）、notification_config（关照配置表）、external_sys（外部系统表）。
概念模型使用 E-R 图来表现，其中 notification 与 notification_config 为1对多的关系，且下面为了便于描述，只给出关键字段，其它字段可以作为冗余。

E-R图 1external_sys 为单独纪录外部业务系统的信息，用于业务系统调用关照系统接口时的身份校验：

E-R图 22.2逻辑模型

下面只给出关键字段的表计划，其它字段可以作为冗余：
notification 表计划

notification_cofig 表计划

external_sys 表计划

三、关键流程计划

下面是业务简单拆分后的泳道图，基于此图再做关键流程的计划。

业务流程泳道图下面通过一个简单的时序图（不含撤回）来进行关键流程的拆解：

业务流程时序图本篇小结

到这里Java 互联网项目中消息关照系统的计划与实现（上）篇就暂告一段落了，剩下的部门包括技术选型、接口计划、关键逻辑计划会在下篇来进行阐明。
系统计划的文章都是通过大量的实践与验证，最后才气下笔成文分享给大家的。假如文章有不足和错误，还请大家指正。或者你有其它想说的，也欢迎大家在评论区里交流！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)