千万级消息中台设计的道与术（上）
一、为什么要做消息中台？
这个话题说起来很窘，在产品业内纷纷宣布需重新审视中台的今天，再谈建消息中台不免有些下头。
但其实是也不是。
以阿里巴巴为例，阿里拆中台，究其原因，是因为中台太大，牵一发而动全身，如果中台不能做到自我解耦，当业态产生变化时，它是很难做到快速响应业务变化。当前阿里中台对阿里巴巴仍是其支持天猫、淘宝、聚划算、1688对应其B2C、C2C、C2B、B2B等各类业态平台的重要载体，其中订单、消息、用户、促销等共享中心能力不但仍最大限度支撑着阿里巴巴全域业务运行，还为其留存了千亿级数据资产、也为其大数据、机器识别技术发展提供了宝贵基础。
以茅台为例，一方面因为酒水行业线上渗透率低，对于强依赖2C内数据资产沉淀的零售中台无法发力，另一方面白酒的重度消费群体，更多以通过2B（公司、单位)的方式来销售的，这些不是简单的线上流程可以替代的，仅就线上部分而言，全域的订单和营销追踪在这样一种业态中是很难发挥最大价值的，中台在其中也只是起到了类MDM的作用，更不谈能在这类传统的业务中起到快速响应迭代的作用。
而消息中台作为一种与业务较为独立的系统，可以做到以下三点：
- 开发成本：最大程度的完成消息分发系统与业务系统的解耦，最大程度减少开发资源的浪费与重复造轮子的问题；
- 拓展性：与放在业务系统单独开发不同，消息中台可接入各类消息媒介接口，建立消息模板体系，具备极强横向扩展属性；
- 适应性：与营、促销和订单中台等需结合业务做三开的产品不同，消息中台对于各种业态有极强的适应性，这也是得力于其仅仅承担了业务当中消息分发的能力；
二、消息的三大要素
讲完了消息中台的价值，下面我们简要谈谈消息这个东西。
1. 消息的本质
大家可以想一想，正如促销系统本质是一个改价系统一样，消息系统的本质是什么？这个问题其实可以通过标定我们日常生活中消息使用场景的固定要素来理解。
从前没有电话的时候我们使用信鸽进行通讯，传递消息的人需要将信绑在鸽子腿上，这是消息内容。而鸽子知道旅程去返地点，这是确认了消息发送的对象，也确定了发送方的信息。鸽子送信本身是一种媒介，如果不采取鸽子，还可以用马匹传递信件，可以类比于选择用微信还是打电话去告诉某人他被开除了一样。而消息策略则指的是要选择半日达、次日达或者是否需要其他方式补送信件之类的传递方法。
基于上面的一个描述，我们可以看到在整个消息分发的流程中，从角色上来看只存在三个对象：即发送方、媒介方、触达方
从要素上来看：消息内容、消息对象、消息策略。
所以其实消息分发系统其实只是一个快递系统，想要发送消息的用户只需要在系统中输入消息内容、消息对象、选择好消息媒介、设置好消息策略（可跳过）就可以将信息这个东西快递到指定的触达方。
三、消息中台的杂与简
1. 消息中台的简
前面讲了消息的三大要素：消息内容、消息对象、消息策略，其实我们发现在消息分发的全流程看来似乎涉及对象很是简单，但是一个成熟的消息中台产品真的是这样简单架构起来的吗？
答案显然是否定的，其实在这里可以借用梭罗的一句话“当我们用教义问答法的方式，思考着什么是人生的宗旨，什么是生活的真正的必需品与资料时，仿佛人们还曾审慎从事地选择了这种生活的共同方式，而不要任何别的方式似的。”来隐喻我们我们在产品设计当中的一些基本原则，即我们在做产品设计时候必须锚定一些最普适的原则，例如上述所言的消息要素，而在设计时候却又要审慎地去设计与拓展性相关的功能。
而为什么说这样一个产品是简单的呢？
主要有以下几个原因：
- 系统：产品与业务系统本身是几乎零耦合的状态，不需和业务系统进行大量数据交互，以PC来比喻，其实消息中台扮演了PC的CPU和内存两个PART的作用，甚至连INPUT也是由消息中台自己来扮演，业务系统仅仅是调用消息中台，挥一挥衣袖，把云彩全部留在了这里；
- 业务：业务层上涉及业务角色较少，所需要进行的功能设计较少，大部分是以一种上帝视角或者说管理员视角进行全流程的消息功能设计便可以完成全流程功能贯通，在有业务角色介入的时候，只需要对某些能力加以封装就基本完全满足对于业务的个性需求了。
2. 消息中台的杂
前面谈完了消息中台的简，下面我们来谈一谈消息中台的杂。
前面谈了它的简单之处，是在功能架构时的要素少，角色少，功能较少，数据交互少等几大原因，但是在进行业务和产品架构设计中，我们发现在也有他的复杂性存在：
（1）接口统一
一般的系统设计是需要与业务系统有耦合的，但是我们在设计消息中台产品时，从架构之初就确定了其只承担消息分发能力，所以其模式是完全与业务系统解耦的一种类型，这个模式可以这样理解：
从图上来看，业务系统在进行请求时，每一次请求的渠道和模板都会有异同，若是各自独立进行接口设计的话，届时API的对接一定是存在巨大隐患的，另一方面，接口需要设计哪一些关键参数也是维持接口统一性的重要保障。
基于上述的分析，笔者建议在消息中台建立标准接口机制，规范接口的入参，如笔者所参与的系统是将：
- 规范入参为：消息模板ID、变量PARAM
- 入参转义有：模板ID转义、消息对象ID转义、消息内容变量PARAM转义
这些放在了接口当中，除了一些基础的鉴权入参之外，其实只保留了两个较为有效的入参。
做到了这些，消息发送的入口便统一，接口具备扩展性，无需任何改动，即可实现消息通道的横向扩充。
（2）消息模板与组合模板
- 为什么要做消息模板
- 什么又是组合模板？
按道理不存在消息模板机制的话，业务系统在调用时候，是需要传递包括一条完整消息内容的全部相关参数，若是我们将包括像渠道、内容（变量、文本）、对象等之类的都打包城一个包裹，给他命名一个ID，这样在下次业务系统需要调用的时候不就可以直接使用了吗？
其实这里我们也可以看看微信的模板消息是怎么做的：
（但是这里也要考虑微信模板消息的特殊性，因为其不是中台架构的产品，所以调用的时候还是需要传参接收ID等内容，中台系统便其实不需要这样进行设计了）
既然已经有了模板的概念了，为什么还要有组合模板呢？其实很容易理解，我们前面所谈的消息模板都是挂在渠道下面的，也就是说一个模板只可以对应一个渠道，如果出现同样的分发内容，分发对象需要分发两次的情况，那不就意味着业务系统要调用两个模板吗？所以我们我可以把两个模板打包到一起形成一个新的模板，这样一种方式在某些中台里也称作通道授权。
（3）通道与模板：什么是通道？（业内也有各自YY的取名）
通道指的是业务维度的分发划分，比如营销中心营销通道，供应链通知通道这一类的；那为什么要提出这样一个概念呢？其实也很容易理解，消息中台按照前面的论述是被设计出来了，但是我们会发现一个问题：这么多消息模板怎么管理？
其实很显然，不管我们的消息中台怎么解耦，最终它都会被带上业务属性。我们不妨再把这些模板聚一个类，用于某个目的的模板都放在这样一个业务通道下面，这样一个账号可以附带多个通道，每个通道也可以覆盖多个模板，这样子后期再做子账号体系打通和权限资源树配置的时候也恰好可以做到一一对应，一举两得。
（4）功能拓展
- 从终局来看，消息三大要素每一部分都是可以单独拎出来做成分布式的功能模块的；
- 以对象要素为例，就可以拆解出黑、白名单、周期活跃用户筛选等一系列功能；
- 以消息数据查看为例，通道覆盖率、折损分析 、发送趋势、点击率等进行一系列运营功能也是能轻易被构建出来；
- 以消息策略为例，也可以形成如下图所示的一系列拓展。
（5）技术指标
笔者当前所处公司对于该块业务域的并发量推送与查询的数量级并不高，当前并不存在所述的这些风险，但是当消息媒介渠道逐渐拓展，接入系统增加，系统调用频率增高的情况产生时，则不得不考虑这些问题了。对于即将产生的这些问题，也要不断和技术沟通，识别哪些需要异步，哪些需要做分布式设计，是否又需要做读写分离，伴随着业务的不断丰富去迭代我们的技术框架。
四、消息中台的困局与出路
这一部分的内容，我就放在下篇来讲吧。
欢迎订阅，下篇：《千万级消息中台设计的道与术（下）》。
注：以上内容与我的任职机构无关，不代表任职机构意见，也不涉及投资建议。
本文作者 @罗镛 。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
