业务消息中心系统设计与实现(二)

本章节主要内容会讲述一下详细的场景与需求,以及设计的实现方案.

技术的产生源于去解决去问题,所以希望读到这里的小伙伴还是要认真阅读下本章节,详细了解产生这个方案的场景与背景.

先说下消息中心实现前现有的消息样式示例:如图下所示

商城app的

社交app的:

可能小伙伴觉得没啥问题.消息长得还不错,也和各自的业务有关系 ,那么问题来了

如果现在业务方新的需求来了,说要做一个新的app来聚合出来一些新的组合功能,包括商城订单的消息、社交的消息、甚至一些sms,email消息、im消息等等.

当程序员接到产品梳理好需求方的需求,第一时间要做的事我猜就是骂街,懂得都懂.因为意味着大量的重复性工作要做,而且后续的一些消息修改,三个服务甚至要后续更多类似服务要修改迭代的,意味着更加难以维护,如果量级达到一定程度,唯有跑路一条出路能解决需求了

当然,除了跑路外我们还有一条路,就是想办法去做一些服务或者业务中间件来满足我们的需求,解决问题才是最好的出路嘛.

当然在我们解决这类问题的时候,不单单是技术单方面问题,需要拉上产品与需求方进行多次讨论确认业务的方向,包括消息中心产生要解决什么样的问题,怎么来解决,怎么去兼容现有的业务包括后续可能的新业务与迭代功能.

作为程序员的我们,我个人觉得在这种场景下要坚持两个理念去设计你的系统,1是解耦、2是敏捷开发.

在与需求方与产品方几轮讨论后,得到了一些有用的结论:

1、将现有的所有上线的产品消息归位7大类,这个大类通俗点讲就是布局,每个类目的布局长得一样、内容不一样,这里我们把大类叫做layout,方便代码上的理解

 2、细化所有消息,每个消息的产生必定是用户的一个动作(下单,点赞、评论...)那么也就衍生出来一个动作对应一个layout,这里的动作其实也就是事件,我们后面在代码中叫做event

有了上边的两个结论其实我们程序员就可以开整了,当然还需要详细的原型,这里我们就省略此步骤了,不影响我们设计此服务.

我们可以简单的通过关系图讲解下怎么有event去实现layout然后进行推送到用户的一个过程

 我们详细讲解这这个图 (此处不做代码讲解,只说下思想,后面部分进行代码讲解)

开始是源消息部分,不管是我们接收到json类型的mq消息还是对象类型的rest请求,最终都是以对象形式进行代码处理,所以我们在接收的对象上实现接口约束以及打上我们的event类型注解

下面我们继续在简单看下真正的到我们各自的event处理中的过程

 

箭头指示的就是我们聚合完成消息后格式化的消息样式方法了,然后在推送给push服务由push服务调用三方的sdk类似mqtt等服务进行推送消息,之后原生或者pc端会拿到布局编号把对进行对应的样式加载以及数据填充.

基本的实现思想就是这样子的,后面两张我们用demo进行详细的代码编写以及讲解,

包括一些博主在介入mq消息时已到的非json协议消息的转换问题