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

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

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

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

商城app的

社交app的:

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

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

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

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

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

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

soulbboy

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值