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

阿里云云棲社群發表於2018-12-19

前端框架

本文由淘寶前端工程師羅嗣分享，主要講述了作者在星巴克訊息開放專案中的總結和思考，希望對大家有幫助，讓業務分享更加有價值。

摘要

從滿足星巴克專案需求單點出發，發散到從點到面的思考。從而總結了自己思考的基本流程（方法論）。從如下四個遞進方面思考。

業務擴充：擴充自有業務的邊界，和其他業務合作共建，形成標準的能力透出, 合力共建。
業務趨勢：業務的特點和趨勢是如何。技術可以如何儲備來應對未來業務的變化。
技術趨勢：技術命題，技術趨勢。選擇適合的技術來解決現在的問題。保持技術對未來的彈性。
需求問題：客觀存在的事實，現在需求存在哪些問題，我們如何去幫助業務更加穩定，更加高效。

本文提綱

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

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

需求介紹

專案背景

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

設計思路

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

點到面的思考

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

原有H5旺旺由於歷史原因有穩定性和體驗的問題，這套方案能不能提供替換成原來的H5旺旺，同時對聊天接入統一收口（標準化元件）。從而達到更加穩定，更加的體驗性。
H5旺旺聊天可以投放到阿里系的其他端上（優酷，餓了嘛，拍賣等），甚至現在很多外投的廣告業務。把H5聊天能力做強對淘寶的引流及成交都有很大的意義。
同時集團裡面還有小蜜作為客服聊天能力。能不能站在前端的角度思考整合輸出。
針對集團二方業務。需要定製個性化訊息和UI能力，需要把SDK能力提供給他們去進行上層業務擴充套件，
1. 為保證他們低成本的接入需要提供基礎能力，二方去擴充套件外掛。
2. 同時工具鏈路上需要保證提高效率。生成閉環的開發環境，接入業務方只要關係自己的業務需求

思考模型

基於之前的背景和訴求，整體設計思路: 抽離UI層和資料層（模組），UI層和資料層基於Message實體進行標準化協議對接（橋樑）。工具鏈路垂直支援提高效能。 有如下幾個方面銜接點：

開放 UI元件 和 標準化SDK能力，讓二方業務快速搭建，UI層 和 資料層之間用 標準化協議做橋樑連線
在基礎SDK上，會透出Context上下文（內部核心物件message，session，app)讓業務去定製修改，業務方只需要去擴充套件外掛。
基於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，可以讓業務擴充套件，補充外掛