编辑导读：消息模块几乎每个产品都会拥有，而消息模块的设计是一个产品成长过程中必备的一个环节。特别是针对高频业务消息的分发，消息模块是业务模块的中间件，与不同的第三方、业务系统联动，保证企业核心业务流程的正常运转。本文以消息中台的思路设计方案，最终落地消息中心方案，以消息收发为基础应用，为不同业务线提供支撑。

当我们的团队集中度在一个产品时，我们的消息系统其实可以做到很简单，简单来说，核心目的是为了在适当的时间以合理的内容告知用户他应该知道的消息。

如果将消息独立一个系统，那么消息本身不存在应用价值，但是在业务线中，与其他业务流程进行组合，那么一个消息的价值可能就是一个量级的转化。

那么在一家成熟的企业来说，一个产品远远是无法支撑庞大的商业模式，所以想要提升自身的发展，无过于开源和节流。

开源即展示新的业务线，拓展新的产品线，都是一家企业打开了新挑战，对未来是存满不确定性的。而节流则对资源的合理利用，梳理现有业务流，剔除重复资源，减少重复劳动力。

那么在整合消息相关资源时，我们会发现最直观的问题：不同的产品线消息模块重复建设，从效率层面来看，本身可以通过一条流程走完的消息流，以多分支的方式，各自做各自的工作，形成了应用资源和开发资源的浪费。

由于每个产品线的消息模块都是一个自成一体的系统，所以在业务人员或开发人员来说，都是一件头痛的事情，因为团队同时要对多套系统进行维护。

那么我们要如何通过一个消息中台来分发不同业务线的消息呢？下面笔者将详细分享自己对于消息中心从0到1的设计经验（以下内容数据方面有一定的模糊处理，仅供参考）。

一、业务背景