编辑导读：消息模块几乎每个产品都会拥有，而消息模块的设计是一个产品成长过程中必备的一个环节。特别是针对高频业务消息的分发，消息模块是业务模块的中间件，与不同的第三方、业务系统联动，保证企业核心业务流程的正常运转。本文以消息中台的思路设计方案，最终落地消息中心方案，以消息收发为基础应用，为不同业务线提供支撑。
当我们的团队集中度在一个产品时，我们的消息系统其实可以做到很简单，简单来说，核心目的是为了在适当的时间以合理的内容告知用户他应该知道的消息。
如果将消息独立一个系统，那么消息本身不存在应用价值，但是在业务线中，与其他业务流程进行组合，那么一个消息的价值可能就是一个量级的转化。
那么在一家成熟的企业来说，一个产品远远是无法支撑庞大的商业模式，所以想要提升自身的发展，无过于开源和节流。
开源即展示新的业务线，拓展新的产品线，都是一家企业打开了新挑战，对未来是存满不确定性的。而节流则对资源的合理利用，梳理现有业务流，剔除重复资源，减少重复劳动力。
那么在整合消息相关资源时，我们会发现最直观的问题：不同的产品线消息模块重复建设，从效率层面来看，本身可以通过一条流程走完的消息流，6以多分支的方式，各自做各自的工作，形成了应用资源和开发资源的浪费。
由于每个产品线的消息模块都是一个自成一体的系统，所以在业务人员或开发人员来说，都是一件头痛的事情，因为团队同时要对多套系统进行维护。
那么我们要如何通过一个消息中台来分发不同业务线的消息呢？下面笔者将详细分享自己对于消息中心从0到1的设计经验（以下内容数据方面有一定的模糊处理，仅供参考）。
一、业务背景
1.业务调研
想要对消息业务有所了解，我们需要先找到一个突破点，即日常工作职责中必须用到消息的职能部门。我们要对业务进行调研更多是对于一个流程、一套闭环工作进行了解，如果是需求调研更多是为了解决一个点的问题，而我们现在要对于整个流程进行了解和整理。
业务调研的流程，首先是要明确为什么要做，原始驱动力是什么？然后明确我们最终的目标，然后以目标反推哪些人与之相关。
知道要去找哪些人后，我们要先提前把问题想好，避免大眼瞪小眼的尴尬。把你不了解的、不熟悉的都记录下来，通过深入访谈或者会议进行沟通，访谈时采用提示引导法。通过你的问题引出他的想法以及问题。然后梳理不同角色的调研结果，通过结果总结分析问题。
前期调研方式和调研问题决定了我们后续对于消息中台的定义和设计，所以这里一定要仔细分别调研时的会谈价值，分析时同时要基于企业不同产品线考虑，尽可能做到多角度分析比对。
同样，如果你对消息没有概念，对系统没有认知，只是知道这套系统具体功能是做什么的，这样是远远不够的。你需要对外进行调研，我们可以适当进行竞品调研，这里可以推荐大家几个消息平台作为学习参考，这里仅介绍国外产品，国内的产品大家搜索引擎找一下都可以找到。
OneSignal：OneSignal:HighVolumeMobileandWebPushNotifications
VWO：：VWO–Application
AirShip：Airship
由于很多人确实没有对消息触达和架构这块并没有经验，而且也没有做过开发工作，所以是需要多学习一下竞品的流程与模式。当然，学习参考并不代表抄袭，因为别人有的你也抄不来，抄过来了也不代表适合你。但是我们做任何一个产品的时候都要保持敬畏之心，对竞品了解是最基础的。你可能会认为：人家做都也不怎么样呀，都没有上市。但我要告诉你，当你在了解其他产品时，有一条底层逻辑要谨记，任何一个消息推送类产品只要存在市场上，那肯定有它所具备的优势。
除了对外调研，内部的调研同样不可缺少，这里可以提供大家几个方向问题，帮助大家在调研消息业务时，进行业务方面的了解。
请麻烦描述一下目前我们的消息推送全流程是如何实现的，与哪些第三方渠道对接？目前业务方面对于消息的主动触达方式有哪些？频率如何？有没有遇到什么问题？你们在使用
