編輯導語：作為一名產品架構師，你研究過市面上哪些消息中臺產品？這些產品在設計方面又有怎么樣的獨到之處？作者分析歸納了消息中臺的三大設計要素，總結了萬級消息中臺設計的道與術。

一、為什么要做消息中臺？

這個話題說起來很窘，在產品業內紛紛宣布需重新審視中臺的今天，再談建消息中臺不免有些下頭。

但其實是也不是。

以阿里巴巴為例，阿里拆中臺，究其原因，是因為中臺太大，牽一發而動全身，如果中臺不能做到自我解耦，當業態產生變化時，它是很難做到快速響應業務變化。當前阿里中臺對阿里巴巴仍是其支持天貓、淘寶、聚劃算、1688對應其B2C、C2C、C2B、B2B等各類業態平臺的重要載體，其中訂單、消息、用戶、促銷等共享中心能力不但仍最大限度支撐著阿里巴巴全域業務運行，還為其留存了千億級數據資產、也為其大數據、機器識別技術發展提供了寶貴基礎。

以茅臺為例，一方面因為酒水行業線上滲透率低，對于強依賴2C內數據資產沉淀的零售中臺無法發力，另一方面白酒的重度消費群體，更多以通過2B（公司、單位)的方式來銷售的，這些不是簡單的線上流程可以替代的，僅就線上部分而言，全域的訂單和營銷追蹤在這樣一種業態中是很難發揮最大價值的，中臺在其中也只是起到了類MDM的作用，更不談能在這類傳統的業務中起到快速響應迭代的作用。

而消息中臺作為一種與業務較為獨立的系統，可以做到以下三點：

1. 開發成本：最大程度的完成消息分發系統與業務系統的解耦，最大程度減少開發資源的浪費與重復造輪子的問題；
2. 拓展性：與放在業務系統單獨開發不同，消息中臺可接入各類消息媒介接口，建立消息模板體系，具備極強橫向擴展屬性；
3. 適應性：與營、促銷和訂單中臺等需結合業務做三開的產品不同，消息中臺對于各種業態有極強的適應性，這也是得力于其僅僅承擔了業務當中消息分發的能力；

二、消息的三大要素

講完了消息中臺的價值，下面我們簡要談談消息這個東西。

1. 消息的本質

大家可以想一想，正如促銷系統本質是一個改價系統一樣，消息系統的本質是什么？這個問題其實可以通過標定我們日常生活中消息使用場景的固定要素來理解。

從前沒有電話的時候我們使用信鴿進行通訊，傳遞消息的人需要將信綁在鴿子腿上，這是消息內容。而鴿子知道旅程去返地點，這是確認了消息發送的對象，也確定了發送方的信息。鴿子送信本身是一種媒介，如果不采取鴿子，還可以用馬匹傳遞信件，可以類比于選擇用微信還是打電話去告訴某人他被開除了一樣。而消息策略則指的是要選擇半日達、次日達或者是否需要其他方式補送信件之類的傳遞方法。

基于上面的一個描述，我們可以看到在整個消息分發的流程中，從角色上來看只存在三個對象：即發送方、媒介方、觸達方

從要素上來看：消息內容、消息對象、消息策略。

所以其實消息分發系統其實只是一個快遞系統，想要發送消息的用戶只需要在系統中輸入消息內容、消息對象、選擇好消息媒介、設置好消息策略（可跳過）就可以將信息這個東西快遞到指定的觸達方。

三、消息中臺的雜與簡

1. 消息中臺的簡

前面講了消息的三大要素：消息內容、消息對象、消息策略，其實我們發現在消息分發的全流程看來似乎涉及對象很是簡單，但是一個成熟的消息中臺產品真的是這樣簡單架構起來的嗎？

答案顯然是否定的，其實在這里可以借用梭羅的一句話“當我們用教義問答法的方式，思考著什么是人生的宗旨，什么是生活的真正的必需品與資料時，仿佛人們還曾審慎從事地選擇了這種生活的共同方式，而不要任何別的方式似的?！眮黼[喻我們我們在產品設計當中的一些基本原則，即我們在做產品設計時候必須錨定一些最普適的原則，例如上述所言的消息要素，而在設計時候卻又要審慎地去設計與拓展性相關的功能。

而為什么說這樣一個產品是簡單的呢？

主要有以下幾個原因：

1. 系統：產品與業務系統本身是幾乎零耦合的狀態，不需和業務系統進行大量數據交互，以PC來比喻，其實消息中臺扮演了PC的CPU和內存兩個PART的作用，甚至連INPUT也是由消息中臺自己來扮演，業務系統僅僅是調用消息中臺，揮一揮衣袖，把云彩全部留在了這里；
2. 業務：業務層上涉及業務角色較少，所需要進行的功能設計較少，大部分是以一種上帝視角或者說管理員視角進行全流程的消息功能設計便可以完成全流程功能貫通，在有業務角色介入的時候，只需要對某些能力加以封裝就基本完全滿足對于業務的個性需求了。

2. 消息中臺的雜

前面談完了消息中臺的簡，下面我們來談一談消息中臺的雜。

前面談了它的簡單之處，是在功能架構時的要素少，角色少，功能較少，數據交互少等幾大原因，但是在進行業務和產品架構設計中，我們發現在也有他的復雜性存在：

（1）接口統一

一般的系統設計是需要與業務系統有耦合的，但是我們在設計消息中臺產品時，從架構之初就確定了其只承擔消息分發能力，所以其模式是完全與業務系統解耦的一種類型，這個模式可以這樣理解：

從圖上來看，業務系統在進行請求時，每一次請求的渠道和模板都會有異同，若是各自獨立進行接口設計的話，屆時API的對接一定是存在巨大隱患的，另一方面，接口需要設計哪一些關鍵參數也是維持接口統一性的重要保障。

基于上述的分析，筆者建議在消息中臺建立標準接口機制，規范接口的入參，如筆者所參與的系統是將：

• 規范入參為：消息模板ID、變量PARAM
• 入參轉義有：模板ID轉義、消息對象ID轉義、消息內容變量PARAM轉義

這些放在了接口當中，除了一些基礎的鑒權入參之外，其實只保留了兩個較為有效的入參。

做到了這些，消息發送的入口便統一，接口具備擴展性，無需任何改動，即可實現消息通道的橫向擴充。

（2）消息模板與組合模板

• 為什么要做消息模板
• 什么又是組合模板？

按道理不存在消息模板機制的話，業務系統在調用時候，是需要傳遞包括一條完整消息內容的全部相關參數，若是我們將包括像渠道、內容（變量、文本）、對象等之類的都打包城一個包裹，給他命名一個ID，這樣在下次業務系統需要調用的時候不就可以直接使用了嗎？

其實這里我們也可以看看微信的模板消息是怎么做的：

（但是這里也要考慮微信模板消息的特殊性，因為其不是中臺架構的產品，所以調用的時候還是需要傳參接收ID等內容，中臺系統便其實不需要這樣進行設計了）

既然已經有了模板的概念了，為什么還要有組合模板呢？其實很容易理解，我們前面所談的消息模板都是掛在渠道下面的，也就是說一個模板只可以對應一個渠道，如果出現同樣的分發內容，分發對象需要分發兩次的情況，那不就意味著業務系統要調用兩個模板嗎？所以我們我可以把兩個模板打包到一起形成一個新的模板，這樣一種方式在某些中臺里也稱作通道授權。

（3）通道與模板：什么是通道？（業內也有各自YY的取名）

通道指的是業務維度的分發劃分，比如營銷中心營銷通道，供應鏈通知通道這一類的；那為什么要提出這樣一個概念呢？其實也很容易理解，消息中臺按照前面的論述是被設計出來了，但是我們會發現一個問題：這么多消息模板怎么管理？

其實很顯然，不管我們的消息中臺怎么解耦，最終它都會被帶上業務屬性。我們不妨再把這些模板聚一個類，用于某個目的的模板都放在這樣一個業務通道下面，這樣一個賬號可以附帶多個通道，每個通道也可以覆蓋多個模板，這樣子后期再做子賬號體系打通和權限資源樹配置的時候也恰好可以做到一一對應，一舉兩得。

（4）功能拓展

• 從終局來看，消息三大要素每一部分都是可以單獨拎出來做成分布式的功能模塊的；
• 以對象要素為例，就可以拆解出黑、白名單、周期活躍用戶篩選等一系列功能；
• 以消息數據查看為例，通道覆蓋率、折損分析 、發送趨勢、點擊率等進行一系列運營功能也是能輕易被構建出來；
• 以消息策略為例，也可以形成如下圖所示的一系列拓展。

（5）技術指標

筆者當前所處公司對于該塊業務域的并發量推送與查詢的數量級并不高，當前并不存在所述的這些風險，但是當消息媒介渠道逐漸拓展，接入系統增加，系統調用頻率增高的情況產生時，則不得不考慮這些問題了。對于即將產生的這些問題，也要不斷和技術溝通，識別哪些需要異步，哪些需要做分布式設計，是否又需要做讀寫分離，伴隨著業務的不斷豐富去迭代我們的技術框架。

四、消息中臺的困局與出路

這一部分的內容，我就放在下篇來講吧。

歡迎訂閱，下篇：《千萬級消息中臺設計的道與術（下）》。

注：以上內容與我的任職機構無關，不代表任職機構意見，也不涉及投資建議。

本文由 @羅鏞 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Pexels，基于CC0協議。