如何去設計前端框架能力？星巴克消息開放項目從0到1，從點到面的思考

本文由淘寶前端工程師羅嗣分享，主要講述了做者在星巴克消息開放項目中的總結和思考，但願對你們有幫助，讓業務分享更加有價值。

摘要

從知足星巴克項目需求單點出發，發散到從點到面的思考。從而總結了本身思考的基本流程（方法論）。從以下四個遞進方面思考。

• 業務拓展：拓展自有業務的邊界，和其餘業務合做共建，造成標準的能力透出, 協力共建。
• 業務趨勢：業務的特色和趨勢是如何。技術能夠如何儲備來應對將來業務的變化。
• 技術趨勢：技術命題，技術趨勢。選擇適合的技術來解決如今的問題。保持技術對將來的彈性。
• 需求問題：客觀存在的事實，如今需求存在哪些問題，咱們如何去幫助業務更加穩定，更加高效。

本文提綱

筆者從0到1構建一個IM前端系統，再從點到面思考整合突破原有的自有業務限制，儘可能設計出的可擴展，可交互，甚至小而美的系統能力。本文會從以下幾個方面去介紹。

• 點：項目背景及需求難點（支付寶星巴克小程序入駐客服接待），以及現有的能力。
• 面：需求作完反向思考，當前BC/CC遇到的問題及痛點，如何在同一個領域模型下作推進標準化能力。

需求介紹

項目背景

客服接待能力由手淘消息平臺和CCO團隊合做共建，總體採用AMP＋XSPACE的方案落地，AMP承接C端用戶聊天界面，XSPACE承接B端聊天界面，同時接待又須要原有BC的聊天能力。星巴克客服接待兩縱一橫，底部須要對接不一樣的服務端，上層須要保證同一套UI來提高一致性體驗。

設計思路

整體設計思想：設計分離出數據層和UI層，數據層和UI層以標準化協議對接。這樣分層就能夠解決當前業務遇到的問題，以下是當時需求的標準SDK事例

點到面的思考

星巴克客服消息接待開放是一種輕量級（H5形式）的客服接入能力。思考當前業務的問題是什麼，如何改進，業務價值的意義等。 筆者會從以下幾個方面去思考。

1. 原有H5旺旺因爲歷史緣由有穩定性和體驗的問題，這套方案能不能提供替換成原來的H5旺旺，同時對聊天接入統一收口（標準化組件）。從而達到更加穩定，更加的體驗性。
2. H5旺旺聊天能夠投放到阿里系的其餘端上（優酷，餓了嘛，拍賣等），甚至如今不少外投的廣告業務。把H5聊天能力作強對淘寶的引流及成交都有很大的意義。
3. 同時集團裏面還有小蜜做爲客服聊天能力。能不能站在前端的角度思考整合輸出。

4. 針對集團二方業務。須要定製個性化消息和UI能力，須要把SDK能力提供給他們去進行上層業務擴展，

   1. 爲保證他們低成本的接入須要提供基礎能力，二方去擴展插件。
   2. 同時工具鏈路上須要保證提升效率。生成閉環的開發環境，接入業務方只要關係本身的業務需求

思考模型

基於以前的背景和訴求，總體設計思路: 抽離UI層和數據層（模塊），UI層和數據層基於Message實體進行標準化協議對接（橋樑）。工具鏈路垂直支持提升效能。 有以下幾個方面銜接點：

1. 開放 UI組件 和 標準化SDK能力，讓二方業務快速搭建，UI層 和 數據層之間用 標準化協議作橋樑鏈接
2. 在基礎SDK上，會透出Context上下文（內部核心對象message，session，app)讓業務去定製修改，業務方只須要去擴展插件。
3. 基於DEF腳手架體系提供相應工具鏈路支持，包括項目模板生成，項目測試，項目構建，完善可持續集成。

業務價值

在阿里作每件事情，須要明確這件事情的價值，這件事情投入產出比是多少。上文也陸續在提價值。 如圖能夠說明這件事價值

實踐方案

上面幾章介紹了項目背景，設計思路，思考模型和業務價值（PS：相似於論文前兩章在介紹背景和理論知識）。這章主要是講的項目實踐。站在前端的角度，從四個方面去實踐，並付相應代碼地址。

• 標準化協議： 因爲消息領域模型是一致的，能夠抽象出標準的 會話和 消息 格式。他是SDK和組件能力的橋樑
• SDK能力開放：提供標準化數據對接的能力，負責插件擴展能力。 業務入駐只須要開發業務相應的中間件（插件）。例如：各自業務的編解碼模塊，登陸模塊，消息處理模塊
• 組件能力開放：提供標準化的聊天能力組件。例如聊天入口接入標準化組件
• 工具鏈路支撐：基於DEF腳手架體系，開發了def-kit-tbms套件。支撐項目全鏈路開發

領域模型（標準化協議）

爲了達到消息標準化能力，須要把基本概念和接口達成一致。梳理兩個基礎概念： 會話 和 消息。

• 會話conversation: 它是指AB通信之間維持的一種關係，它是消息存儲的載體
• 消息message: 消息是一個對話的基本組成部分, 根據業務分爲兩大塊消息，會話內消息和系統通知消息。會話內消息又能夠分爲基本消息和自定義消息。

會話類型

即時通信 SDK 的核心概念「會話」，即 Conversation。咱們將單聊和羣聊（包括聊天室）的消息發送和接收都依託於 Conversation 這個統一的概念進行操做。

會話屬性	備註
id	會話ID
scene	場景
to	聊天對象，帳號或者羣ID
updateTime	會話更新時間
unread	未讀數
lastMsg	此會話的最後一條消息
custom	擴展Json字符串

消息類型

IM SDK內的消息能夠分爲兩類：會話內消息和系統通知消息。會話內消息只能出現並展現在聊天界面裏，通常是應用內的一個用戶發給另外一個用戶（或羣組/聊天室）的消息，例如文本消息、圖片消息都屬於會話內消息。：

會話內消息類型	備註
文本消息	消息內容爲普通文本
圖片消息	消息內容爲圖片URL地址、尺寸、圖片大小等信息
語音消息	消息內容爲語音URL地址、時長、大小、格式等信息
視頻消息	消息內容爲視頻文件的URL地址、時長、大小、格式等信息
文件消息	消息內容爲文件的URL地址、大小、格式等信息，格式不限
地理位置消息	消息內容爲地理位置標題、經度、緯度信息
通知消息	自定義消息能夠用於消息接入擴展。 例如卡片消息，紅包消息等。
自定義消息	**通知消息屬於會話內的一種消息，用於會話內通知和提示場景。
例如：羣名稱更新、某某某退出了羣聊等。**

會話和消息標準化格式

• 標準化協議
• 標準化會話格式
• 標準化消息格式

SDK能力開放

SDK的設計參考了Koajs的設計原理（底層微創新了下）。Koajs的中間件思路： 中間件對於一次請求來處理，context分別集成了request和response對象， 同理能夠映射成對一條收發消息的處理，面向切面的編程方式。。 在context中會集成message(消息),session(會話),app(如用戶，初始化sdk信息等其餘信息)。
整個項目經過lerna進行了包管理，用Typescript寫了SDK，並作了充分的單元測試，你們能夠放心使用。整個項目分爲了以下幾個模塊：

• @ali/tbms-compose: 函數組合模塊，用於@ali/tbms-middlware服務
• @ali/tbms-middleware: 中間件模塊
• @ali/tbms-util: 通用函數分裝：如promise同步執行隊列，mtop請求，event事件系統
• @ali/tbms-sdk: 消息標準化基礎SDK，可讓業務擴展，補充插件

測試說明：

對底層支持的SDK都作了充分的單元測試，保證穩定性。後續版本更新提供差別性修改的檢查

使用事例

組件能力開放

因爲須要多端投放，某些二方應用支持weex能力。從而選擇了RAX技術方案。再在H5表現下對單聊作性能優化，現階段完成聊天入口的統一接入組件，上層的組件在陸續完善中（完成度20%）。@ali/rax-tbms-chatwater tbms-components

工具鏈路支撐

基於DEF腳手架體系，開發了def-kit-tbms套件。提供項目全鏈路開發支撐。這個項目後續的項目搭建都採用standard-dev腳手架生成項目目錄。例如：tbms-toolkit，tbms-packages

總結

這是一次完整的一個項目從0到1，從點到面的思考過程，創建模型到付諸於實踐。從完成業務需求（需求作什麼）到幫助業務成長（我能作什麼）的思考過程。雖然只是站在前端角度在思考問題，可是方法論相信能夠通用。

後續Action

改善原來的H5旺旺，使之更加穩定和更好的體驗性。同時對聊天接入統一收口（標準化組件和標準化接入SDK）。Flag：利用業餘時間，一月中旬前初版本里程碑發佈

原文連接