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

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

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

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

商城app的

社交app的:

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

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

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

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

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