【51CTO.com原創稿件】淘寶上每天都有上百萬的客服在線為上億的買家提供服務，客服服務平臺也從一個簡單的分流系統逐步演進到覆蓋買家、客服和客服主管三位一體的平臺解決方案。

本文主要分享整個淘寶客服平臺架構演進的過程，以及當前服務如何結合 AI 賦能的實踐。

2017 年 12 月 1 日-2 日，由 51CTO 主辦的 WOTD 全球軟件開發技術峰會在深圳中州萬豪酒店隆重舉行。

本次峰會以軟件開發為主題，阿里巴巴云零售事業部高級技術專家古墨在技術架構遇到業務架構專場帶來了主題為“淘寶智能客服架構演進之路”的精彩演講。

本文分為三塊跟大家分享最近三年來淘寶在商家客服方面的架構演進：

• 阿里電商客服業務背景介紹
• 淘寶智能客服架構演進之路
• 總結

阿里電商客服業務背景介紹

客服行業的歷史由來已久，在近五到十年的時間里面，它經歷了如下三個階段：

• 在互聯網還沒有完全興起的最早期，傳統的客服行業表現為 Callcenter、Email 和短信等方式。其主要功能是為了幫助企業做好溝通、解決問題、以及售后咨詢。
• 隨著互聯網的發展，該行業出現了基于 Web 端和 PC 終端的客服。他們通過互聯網的方式提供服務。此時，一些社交媒體和淘寶電商的客服人員開始出現。
• 近期，隨著用戶數量的劇增，整個客服行業開始轉向客服云的解決方案，實現了在不同地域為整個公司或企業提供云解決方案。

對于阿里電商平臺而言，每天在淘寶上會有數千萬的消費者，他們每天的咨詢量可達上億次。相應地在商家端，也會有幾百萬次與消費者的互動。

每逢雙十一等活動期間，該數字對于商家雖然變化不大，但是消費者的咨詢量會有至少 10 倍至 20 倍的增長量級。

因此對于整個平臺的客服工具而言，需要向著智能化和數據化的方向發展，以提高商家的能效和消費者的滿意度，同時這也是我們解決問題的重點所在。

由于淘寶的服務絕大程度上來自于商家，因此提升商家客服的服務質量就能夠提升整個平臺的滿意度。

淘寶智能客服架構演進之路

根據業務發展，我們的架構演進分為三個明確的階段：

• 分流系統架構。我們實施了分流系統，具體分為正常的分流和分流排隊。
• 客服業務系統的架構升級。隨著業務范圍擴大，我們對整個業務架構實施了重整，調整成為基于事件驅動方式的業務系統。
• 客服業務系統與 AI 能力的融合。當前、乃至將來，我們在跟集團內部各個 AI 團隊合作，使 AI 能力能與接待場景實現深度結合。

***階段：分流系統架構

舉例而言：當買家登錄手機淘寶，找到某個商家想咨詢問題時，一旦他點擊了旺旺頭像，系統便觸發了一次分流的操作。

像蘇寧或小米之類的賣家，由于后臺擁有十到上百位客戶人員，因此系統需要通過分流來選取一位合適的客服提供服務，進而建立會話。由此可見，這是 IM 聊天過程中的一個關鍵節點。

在今年的雙十一期間，整個分流系統面臨著很大的流量壓力。由于每一條聊天消息都要流經該系統，它們對于系統性能的挑戰非常巨大。

一旦系統出現抖動或 RT 變慢，全網的服務都會受到影響。因此為了應對巨大的吞吐量，我們會盡一切可能縮短 RT。

基于上述需求，我們制定了如下不同的解決方案：

• 對于蘇寧、小米之類超大型商家，我們運用了類似于負載均衡的定制化解決方案。具體包括：權重、客服分組、和基于頁面來源的分流。其中頁面來源是指我們根據咨詢的路徑，去判斷要轉發到售前分組還是售后分組。
• 對于一些全品類的商家，他們的客服根據品類已經進行了細分組，因此我們也基于品類屬性予以了個性化的需求分流。
• 對于一些類似于汽車行業的賣家，他們的客服只能服務于本地的消費者。因此我們需要根據不同的咨詢來源，基于地域的方式進行分流。
• 對于排隊式分流，我們會在后面重點討論。

為了追求足夠巨大的吞吐量和足夠短的 RT 要求，同時還要兼顧特殊的業務規則、狀態變化和用戶設置，我們從外部將許多變量的信息同步到系統內部。

而在帶有變化事件的變量進入系統之后，為了保證整個系統的穩定性和業務的合理性，我們搭建了一套讀寫分離的架構。

我們將整個查詢的邏輯放置在一個系統之中，而將所有更新狀態的變化放置在另一個系統里。兩套系統之間通過緩存的方式進行對話。

因此對于讀數據而言，我們能夠利用緩存這種***的實時性技術，***限度地提升 QPS、并降低 RT。

另外，為了進一步縮短 RT，我們將復雜的計算也放到了后面的更新操作中。通過提前預判下一次分流時應當分派給哪一位客服，我們就可以直接進行更新操作，從而簡化了查詢和整個計算的復雜度。

上圖的右上方展示的是商家的接待端在雙十一大促時的咨詢狀態。雖然系統實現了分流、并具有很快的 RT 和吞吐量，但是由于并行接入的咨詢請求過多，就算系統能夠承受，具體服務的客戶人員也應接不暇。

鑒于商家能夠招聘客服的人數有限，我們提出的相應解決方案是：以機器人和分流排隊相結合的方式，幫助商家應對高發的流量。

上圖的下方是排隊功能的流程展示：所有進入服務咨詢的買家會被分配一個虛擬賬號→該虛擬賬號對接后端阿里店小秘的服務機器人→機器人通過 AI 來對接買家，并對簡單問題予以回答。

如果買家不滿意答復，則可選擇轉到人工→轉人工后，根據分流和分組的邏輯，將其納入排隊→進入排隊之后，后臺調度系統進行買家的出隊和客服的分派→創建一個接待會話，由客服跟進后續的接待。

我們之所以引入會話的概念，是因為客服主管要為客服團隊設定一個合理的接待上限，以控制同一時刻一次性接入的人數。

例如：耐克的淘寶網店，就嚴格地認為一個客服人員一次性最多只能同時接待 5 個顧客，倘若超過則會造成服務質量的下降。

另外，我們對整個鏈路還設置了一個完整數據的埋點，通過實時統計，來幫助各個商家完整地觀察到當前店鋪的接待情況。

其中包括：有多少人在被機器人服務、有多少人在排隊等待、有多少人在被人工接待、每個人工接待的時長情況、以及響應的速度等。客服主管能夠通過觀察后臺情況，來衡量整體的服務狀態。

由于業務條件的限制，我們設計和采用的排隊技術框架與業界不盡相同。

首先，由于旺旺集成在手淘的各個版本之中，且可以被直接用于聊天，因此在用戶端上就會出現橫跨多端、多版本的可能。

而我們的排隊邏輯是做在前端頁面里的，因此我們很難保證在老版本的客戶端上能夠具備新的能力。

其次，由于我們的旺旺、千牛等處于不同的系統之中，而阿里這個大型平臺已將每個業務系統拆分得非常細。

因此要保證跨多個客戶端、多個服務器的數據、規劃和隊列的一致性，我們所付出的成本會非常高。

所以我們需要做到如下方面：

• 我們決定采用服務端集中式會話狀態管理。完全不依賴于客戶端的能力去做任何事情，所有的方案都由服務端來完成。
• 由于無法實現分布式事務，我們通過業務補償的方式來保證整個排隊中的狀態和數據最終的一致性。

在將買家的請求分配給合適的隊列，并通過排隊調度來管理客服時，我們曾對如下問題進行了不同嘗試：

集中式會話管理的高并發處理：使每個客服的接待分發數不超過設定的上限。

由于在 Java 中我們通常傾向于用無狀態的方式實現每一個應用，而各個客服卻分布于不同的機器之上，因此我們設置了一個類分布式鎖來進行實時查詢，如果發現客服應對的人數超過上限，就停止服務。

對于由于機器無狀態的競爭所引發的分布式鎖的開銷，我們通過采用 ZK（zookeeper）來管理商家的分片，并用單線程的機制予以處理。

我們讓處于同一臺機器上、同一個分片的所有商家都使用同一個線程來進行處理，從而避免了與競爭有關的鎖問題。

此類帶狀態的分布式處理機制，帶來的***問題是 failover。即：由于每個用戶只存在于單臺機器上，而無任何備份，如果機器因大流量或其他問題而宕機時，我們如何才能做到在不丟失狀態的情況下，快速地恢復這些用戶呢？

我們采用了一種強壯的 failover 機制，保證在機器或隊列出現問題時，能夠在大約一至兩分鐘之內重新啟動該設備，恢復整體狀態。

隊列存儲的處理：由于商家的促銷活動時間不一致，我們不可能做到全網調度，因此必須做成“開關”讓商家自行設置。

同時在經常創建不同的隊列時，由于我們的排隊機制完全依賴于分組，而分組的力度和數量是不可控的。

因此我們采用了 MySQL 的方案，來設置這種開關，從而可以隨時動態地大量創建或銷毀分組。

關于“快入隊，慢出隊”的現象，由于買家的數量和咨詢量會在活動高峰期出現驟增，客服則會因為能力有限，而“消化”速度緩慢。

因此我們采用了一種 pull 的方式，在保證流量能夠快速進入的基礎上，客服憑借分組、并依據自身能力的狀況，不停地從同一個隊列里面進行拉取。

排隊數據的上帝視角：動態創建副本的能力、需要支持各個維度的查詢、以及排隊優先級和固定分組等方面因素，都會給 MySQL 的調度能力以及吞吐性能提出非常高的要求。

在雙十一大促時，為了讓 MySQL 具備支持 top1000 商家的能力，我們以分布分表的方式對 MySQL 進行了整體容量的規劃，并且通過 MySQL 的復雜能力來快速地支撐業務。

當然我們也遇到了一些新的瓶頸，為了能夠繼續支撐下一輪雙十一大促，我們正在考慮對性能進行進一步的優化。

第二階段：客服業務系統架構升級

前面提到的是最為基礎的、最為核心的服務分流與排隊。但是隨著業務的發展，我們發現客服接待可以從整體上分為三個角色：消費者、客服和主管。

只有這三種角色實現了互動或聯動，才能形成最為合理的體驗關系。根據統計，在我們的平臺上約有近百萬名職業的客服人員。

如果按照人均三千或五千元的月收入來計算的話，客服行業的一年總支出成本高達數百億。因此我們亟待通過工具或自動化的方式，幫助他們節省此類成本的支出。

在產品能力上：

• 我們為買家端設計了智能服務窗，買家可以自助地去領取各類商家的優惠券和活動物品。我們增加了輸入聯想功能，例如：您在使用手淘對某個店鋪進行咨詢時，它會直接提示你一些常用的話術。
• 我們在接待面板上啟用了千牛。通過相對復雜的界面，客服能夠看到整個商家和買家的相關信息、接待中出現的問題，它同時也能提供語音轉文字的功能。
• 客服主管的后臺主要提供的是監控與調度。它能夠通過服務助手店小秘和 AI 機器人顯示整個店鋪和客服的接待情況、轉化率，從而實現對于店鋪的精細化管理。

有過業務開發經驗的程序員都知道：功能需求往往是一股腦被提出的，而留給我們開發的時間通常比較緊迫。

如上圖右側所示，為了能讓業務“跑起來”，系統在整體上會呈現出“垂直”的基礎架構：

• 為了降低錯誤率，會出現許多重復建設。由于沒有充分考慮到底層的通用性，各種接口的適用性比較差，復用率較低。
• 各個業務模塊的依賴關系也較為混亂。
• 系統的處理能力也不均衡。一般面向 C 端的業務體量特別大；而面向 B 端的業務雖然體量相對不大，但是復雜度特別高。

因此如果對業務拆分得不合理的話，就會造成 C 端的業務和 B 端的業務共同被放置在同一模塊里。那么只要出現過大的流量，商家的系統就可能會出現較大的風險。

面對上述情況，我們通過細致的梳理，圍繞著交易關系這一核心本質，對整個接待過程進行了較為合理的拆分，在 IM 通道上面沿著用戶的互動行為，可分為：買家端行為→千牛→商家端行為。

如上圖所示，對于每一端的每一種角色，又可分為售前、售中和售后三種場景。

而對于客服則涉及到各種淘系業務的操作，并能與自己內部的 ERP、MS 以及后臺自建系統相連接，最終實現各個場景的互通與聯動。

我們在此提出了新想法：以場景作為切面，將消費者、客服和業務系統有機地結合起來。

如果在通道兩端有行為發生時，我們可以將交易事件或是用戶行為事件，加上 IM 聊天事件作為輸入源，最終推動整個業務場景不斷前行。

下面我們將上述過程抽象為一個業務描述：

• 從事件驅動的角度出發，將聊天消息、交易消息、評價等與平臺相關的所有事件統一采集起來，然后對這些事件進行解析、標準化、存儲，并定義到場景之中。

例如：買家進來咨詢了一種商品，商家給予推薦；在買家下單之后，商家要提醒買家盡快付款；或者在買家付款后修改送貨地址。

• 在全部梳理清楚之后，我們將這些事件源、流程、定義、選擇、以及執行拼裝成一系列的信息流，進而變成各種預定義的場景。
• 通過場景的輸出，我需要找到其對應的可選服務，如上例中的“修改地址”，其實就應該調到后臺的交易流程去完成地址相關服務。

而前面提到的“商品推薦”，則需要推薦團隊的服務能力，實現基于內容的商品推薦。

• ***，我們需要將服務能力輸出到聊天通道上。

在具體實現中：

• 對于買家端而言，只需在 IM 通道里面突出類似于卡片、文本消息、圖文或視頻即可。
• 對于客服而言，我們通過與現有插件的互通，只需在界面的右側顯示買家的行為特點、各種事件提醒、以及需要執行的操作，因此不必放入通道之中。
• 對于主管而言，主要是各種監控和對數據模型的預計。例如：在接待過程中，如果捕獲到買家的抱怨信息，主管就能判定買家當時的情緒或分析出是否由于接待時間超長而造成的耐心不夠，進而轉給客服執行特殊的安撫。

基于上述場景，我們對業務平臺進行了重新搭建。

首先將業務動態地進行了縱向連接，然后在此基礎上對核心功能予以了抽取，并以卡片的形式在通道上進行交互。此外，通過對復雜場景的實時計算，我們也定義了各類事件。

對于前端，我們通過訂閱系統來實現各種服務的注冊、發布與訂閱，而通過插件框架來負責第三方服務的接入。

消息通道的控制實現了前端框架與底層以及服務窗的交互。如前所述，通過事件將各個服務流程進行串聯，我們形成了如上圖所展示的核心業務架構。

對于前端遺留的一些需要寫入核心系統的業務代碼，我們將它們拆分成了買家端自助服務、分流服務、面向客服的工具和面向客服主管的工具四個業務層系統。而圖中的下方是我們的后臺底層大平臺。

由上可見，在轉變為基于事件模式之后，好處就在于：只需要按照我們所定義的標準對新進的服務人員予以接入，訂閱其所關心的事件和處理的機制。通過識別出所涉及到的場景和與之對應的調用服務，最終實現標準化。

客服業務系統與 AI 能力的融合

由于我的團隊是做平臺的，而 AI 場景則是由另外一個算法團隊來實現的，因此雙方需要進行算法相關的對接。

我們提供了一整套服務注冊、發現和訂閱的關系。雖然同為商品推薦，但是應用于“航旅”方面的推薦算法會與帶有圖片和搜索功能的“女裝”推薦模式截然不同。

當前我們主要運用的還是基于規則路由的機制，但是隨著服務場景和服務提供者的增多，我們會更多地融入基于 AI 的決策機制。

在將 AI 與各個 IM 通道相結合的方面，我們基于會話的框架設計，完全可以對標 Facebook 的 Messenger 和微軟做的 Bot Framework。所有接入的聊天場景，不管是機器人還是解決方案，都具有會話完成的機制。

系統籍此可以獲悉某個傳遞過來的消息或請求，是由哪個用戶在何種場景下觸發的。

過去的單輪交互是：有一個請求進來，就給出一個答案。而如今 AI 所應對的復雜業務一般需要進行多輪交互。

如前面提到的航旅推薦的例子：在交互了是否要旅行之后；需要進一步詢問是國內還是國外游；如果是國外游的話，還需詢問目標地區。可見多輪交互需要 AI 具有語意匹配和意圖識別等較強的交互能力。

為了讓買家在使用 AI 時有更好的體驗，我們在給出算法接入時，允許對方自定義菜單。他們通過溝通，將期望買家輸入的答案設置到菜單中。

如此交互式的提醒，不但省去了買家的打字輸入，又能固化其反饋的結果。這種友好的交互也提升了平臺的整體處理能力。

由于我們本質上是通過基于消息驅動的邏輯來實現的，如上圖從左至右所示：事件源接入→標準化→安全脫敏→事件中心與調度中心的控制。與此同時，外面的 AI 服務接入于此→注冊授權→開放接口→整體監控。

我們之所以將 AI 的服務能力單獨劃分出來，是因為需要通過與其他團隊合作，來實現外部的搜索、意圖識別、知識庫、多輪交互、情感分析等能力。

我們的 Bot 不僅可以與買家端交互，也可以與客服進行交互。類似于店小秘，作為認知服務的 API 可供各個業務方去調用。

對于用戶的聊天數據、客服的績效、其當天的狀態、每個客戶角色的數據、以及店鋪的商品數據，我們通過底層數據的沉淀功能，可供不同場景進行調用，從而實現了快速開發和輕量級的服務提供。

總結

結合場景抽象出業務本質的模型來指導設計：根據前面所提及的基于事件驅動的概念，大量的事件都是由商品交易或聊天互動所觸發產生，并形成了聯動場景。

我們可以通過一層層的切片來構建一個個具象的場景。而從整體的角度來說，不同事件的組合又能形成不同的驅動模型。

跟隨著業務的復雜性不斷的調整和優化架構設計：我們沒有必要一定采用所謂“最牛”的中間件方案。只有最適合自己的業務場景才是***的架構設計。

團隊成員統一架構上的認知：我常在團隊里說，“架構只有適合與否，沒有好壞之分。使用一個好的架構，你當然能夠實現某個業務需求；而使用一個差的架構，你同樣也能最終實現該業務需求。”

因此全部團隊成員都應當有一致的架構認知。只有這樣每個人才能在編寫業務代碼時，主動思考自己所實現的功能應該如何在整個架構體系里達到平衡與和諧處理，以及放置在何處才最為合適。

相反，如果團隊成員對于架構的認知不一致，那么就有可能會導致組織內部的代碼風格和運行方式出現不一致的情況。因此統一認識對于帶領團隊去滿足需求和實現業務都是至關重要的。

[[229332]]

淘寶技術部-媒體技術與消費連接平臺-消費連接平臺-平臺業務-自運營，高級技術專家。2010 年加入阿里，2015 年開始負責阿里商家客戶服務平臺的搭建，推動平臺架構升級，為阿里全域（天貓、淘寶、1688、航旅等）商家提供客服整體解決方案。專注于高并發、高性能、高可用的分布式系統研究和實踐。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】