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

本文主要分享整個淘寶客服平臺架構(gòu)演進(jìn)的過程，以及當(dāng)前服務(wù)如何結(jié)合 AI 賦能的實(shí)踐。

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

本次峰會以軟件開發(fā)為主題，阿里巴巴云零售事業(yè)部高級技術(shù)專家古墨在技術(shù)架構(gòu)遇到業(yè)務(wù)架構(gòu)專場帶來了主題為“淘寶智能客服架構(gòu)演進(jìn)之路”的精彩演講。

本文分為三塊跟大家分享最近三年來淘寶在商家客服方面的架構(gòu)演進(jìn)：

• 阿里電商客服業(yè)務(wù)背景介紹
• 淘寶智能客服架構(gòu)演進(jìn)之路
• 總結(jié)

阿里電商客服業(yè)務(wù)背景介紹

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

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

對于阿里電商平臺而言，每天在淘寶上會有數(shù)千萬的消費(fèi)者，他們每天的咨詢量可達(dá)上億次。相應(yīng)地在商家端，也會有幾百萬次與消費(fèi)者的互動。

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

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

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

淘寶智能客服架構(gòu)演進(jìn)之路

根據(jù)業(yè)務(wù)發(fā)展，我們的架構(gòu)演進(jìn)分為三個明確的階段：

• 分流系統(tǒng)架構(gòu)。我們實(shí)施了分流系統(tǒng)，具體分為正常的分流和分流排隊。
• 客服業(yè)務(wù)系統(tǒng)的架構(gòu)升級。隨著業(yè)務(wù)范圍擴(kuò)大，我們對整個業(yè)務(wù)架構(gòu)實(shí)施了重整，調(diào)整成為基于事件驅(qū)動方式的業(yè)務(wù)系統(tǒng)。
• 客服業(yè)務(wù)系統(tǒng)與 AI 能力的融合。當(dāng)前、乃至將來，我們在跟集團(tuán)內(nèi)部各個 AI 團(tuán)隊合作，使 AI 能力能與接待場景實(shí)現(xiàn)深度結(jié)合。

***階段：分流系統(tǒng)架構(gòu)

舉例而言：當(dāng)買家登錄手機(jī)淘寶，找到某個商家想咨詢問題時，一旦他點(diǎn)擊了旺旺頭像，系統(tǒng)便觸發(fā)了一次分流的操作。

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

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

一旦系統(tǒng)出現(xiàn)抖動或 RT 變慢，全網(wǎng)的服務(wù)都會受到影響。因此為了應(yīng)對巨大的吞吐量，我們會盡一切可能縮短 RT。

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

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

為了追求足夠巨大的吞吐量和足夠短的 RT 要求，同時還要兼顧特殊的業(yè)務(wù)規(guī)則、狀態(tài)變化和用戶設(shè)置，我們從外部將許多變量的信息同步到系統(tǒng)內(nèi)部。

而在帶有變化事件的變量進(jìn)入系統(tǒng)之后，為了保證整個系統(tǒng)的穩(wěn)定性和業(yè)務(wù)的合理性，我們搭建了一套讀寫分離的架構(gòu)。

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

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

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

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

鑒于商家能夠招聘客服的人數(shù)有限，我們提出的相應(yīng)解決方案是：以機(jī)器人和分流排隊相結(jié)合的方式，幫助商家應(yīng)對高發(fā)的流量。

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

如果買家不滿意答復(fù)，則可選擇轉(zhuǎn)到人工→轉(zhuǎn)人工后，根據(jù)分流和分組的邏輯，將其納入排隊→進(jìn)入排隊之后，后臺調(diào)度系統(tǒng)進(jìn)行買家的出隊和客服的分派→創(chuàng)建一個接待會話，由客服跟進(jìn)后續(xù)的接待。

我們之所以引入會話的概念，是因?yàn)榭头鞴芤獮榭头F(tuán)隊設(shè)定一個合理的接待上限，以控制同一時刻一次性接入的人數(shù)。

例如：耐克的淘寶網(wǎng)店，就嚴(yán)格地認(rèn)為一個客服人員一次性最多只能同時接待 5 個顧客，倘若超過則會造成服務(wù)質(zhì)量的下降。

另外，我們對整個鏈路還設(shè)置了一個完整數(shù)據(jù)的埋點(diǎn)，通過實(shí)時統(tǒng)計，來幫助各個商家完整地觀察到當(dāng)前店鋪的接待情況。

其中包括：有多少人在被機(jī)器人服務(wù)、有多少人在排隊等待、有多少人在被人工接待、每個人工接待的時長情況、以及響應(yīng)的速度等?？头鞴苣軌蛲ㄟ^觀察后臺情況，來衡量整體的服務(wù)狀態(tài)。

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

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

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

其次，由于我們的旺旺、千牛等處于不同的系統(tǒng)之中，而阿里這個大型平臺已將每個業(yè)務(wù)系統(tǒng)拆分得非常細(xì)。

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

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

• 我們決定采用服務(wù)端集中式會話狀態(tài)管理。完全不依賴于客戶端的能力去做任何事情，所有的方案都由服務(wù)端來完成。
• 由于無法實(shí)現(xiàn)分布式事務(wù)，我們通過業(yè)務(wù)補(bǔ)償?shù)姆绞絹肀ＷC整個排隊中的狀態(tài)和數(shù)據(jù)最終的一致性。

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

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

由于在 Java 中我們通常傾向于用無狀態(tài)的方式實(shí)現(xiàn)每一個應(yīng)用，而各個客服卻分布于不同的機(jī)器之上，因此我們設(shè)置了一個類分布式鎖來進(jìn)行實(shí)時查詢，如果發(fā)現(xiàn)客服應(yīng)對的人數(shù)超過上限，就停止服務(wù)。

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

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

此類帶狀態(tài)的分布式處理機(jī)制，帶來的***問題是 failover。即：由于每個用戶只存在于單臺機(jī)器上，而無任何備份，如果機(jī)器因大流量或其他問題而宕機(jī)時，我們?nèi)绾尾拍茏龅皆诓粊G失狀態(tài)的情況下，快速地恢復(fù)這些用戶呢？

我們采用了一種強(qiáng)壯的 failover 機(jī)制，保證在機(jī)器或隊列出現(xiàn)問題時，能夠在大約一至兩分鐘之內(nèi)重新啟動該設(shè)備，恢復(fù)整體狀態(tài)。

隊列存儲的處理：由于商家的促銷活動時間不一致，我們不可能做到全網(wǎng)調(diào)度，因此必須做成“開關(guān)”讓商家自行設(shè)置。

同時在經(jīng)常創(chuàng)建不同的隊列時，由于我們的排隊機(jī)制完全依賴于分組，而分組的力度和數(shù)量是不可控的。

因此我們采用了 MySQL 的方案，來設(shè)置這種開關(guān)，從而可以隨時動態(tài)地大量創(chuàng)建或銷毀分組。

關(guān)于“快入隊，慢出隊”的現(xiàn)象，由于買家的數(shù)量和咨詢量會在活動高峰期出現(xiàn)驟增，客服則會因?yàn)槟芰τ邢?，?ldquo;消化”速度緩慢。

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

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

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

當(dāng)然我們也遇到了一些新的瓶頸，為了能夠繼續(xù)支撐下一輪雙十一大促，我們正在考慮對性能進(jìn)行進(jìn)一步的優(yōu)化。

第二階段：客服業(yè)務(wù)系統(tǒng)架構(gòu)升級

前面提到的是最為基礎(chǔ)的、最為核心的服務(wù)分流與排隊。但是隨著業(yè)務(wù)的發(fā)展，我們發(fā)現(xiàn)客服接待可以從整體上分為三個角色：消費(fèi)者、客服和主管。

只有這三種角色實(shí)現(xiàn)了互動或聯(lián)動，才能形成最為合理的體驗(yàn)關(guān)系。根據(jù)統(tǒng)計，在我們的平臺上約有近百萬名職業(yè)的客服人員。

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

在產(chǎn)品能力上：

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

有過業(yè)務(wù)開發(fā)經(jīng)驗(yàn)的程序員都知道：功能需求往往是一股腦被提出的，而留給我們開發(fā)的時間通常比較緊迫。

如上圖右側(cè)所示，為了能讓業(yè)務(wù)“跑起來”，系統(tǒng)在整體上會呈現(xiàn)出“垂直”的基礎(chǔ)架構(gòu)：

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

因此如果對業(yè)務(wù)拆分得不合理的話，就會造成 C 端的業(yè)務(wù)和 B 端的業(yè)務(wù)共同被放置在同一模塊里。那么只要出現(xiàn)過大的流量，商家的系統(tǒng)就可能會出現(xiàn)較大的風(fēng)險。

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

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

而對于客服則涉及到各種淘系業(yè)務(wù)的操作，并能與自己內(nèi)部的 ERP、MS 以及后臺自建系統(tǒng)相連接，最終實(shí)現(xiàn)各個場景的互通與聯(lián)動。

我們在此提出了新想法：以場景作為切面，將消費(fèi)者、客服和業(yè)務(wù)系統(tǒng)有機(jī)地結(jié)合起來。

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

下面我們將上述過程抽象為一個業(yè)務(wù)描述：

• 從事件驅(qū)動的角度出發(fā)，將聊天消息、交易消息、評價等與平臺相關(guān)的所有事件統(tǒng)一采集起來，然后對這些事件進(jìn)行解析、標(biāo)準(zhǔn)化、存儲，并定義到場景之中。

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

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

而前面提到的“商品推薦”，則需要推薦團(tuán)隊的服務(wù)能力，實(shí)現(xiàn)基于內(nèi)容的商品推薦。

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

在具體實(shí)現(xiàn)中：

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

基于上述場景，我們對業(yè)務(wù)平臺進(jìn)行了重新搭建。

首先將業(yè)務(wù)動態(tài)地進(jìn)行了縱向連接，然后在此基礎(chǔ)上對核心功能予以了抽取，并以卡片的形式在通道上進(jìn)行交互。此外，通過對復(fù)雜場景的實(shí)時計算，我們也定義了各類事件。

對于前端，我們通過訂閱系統(tǒng)來實(shí)現(xiàn)各種服務(wù)的注冊、發(fā)布與訂閱，而通過插件框架來負(fù)責(zé)第三方服務(wù)的接入。

消息通道的控制實(shí)現(xiàn)了前端框架與底層以及服務(wù)窗的交互。如前所述，通過事件將各個服務(wù)流程進(jìn)行串聯(lián)，我們形成了如上圖所展示的核心業(yè)務(wù)架構(gòu)。

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

由上可見，在轉(zhuǎn)變?yōu)榛谑录Ｊ街?，好處就在于：只需要按照我們所定義的標(biāo)準(zhǔn)對新進(jìn)的服務(wù)人員予以接入，訂閱其所關(guān)心的事件和處理的機(jī)制。通過識別出所涉及到的場景和與之對應(yīng)的調(diào)用服務(wù)，最終實(shí)現(xiàn)標(biāo)準(zhǔn)化。

客服業(yè)務(wù)系統(tǒng)與 AI 能力的融合

由于我的團(tuán)隊是做平臺的，而 AI 場景則是由另外一個算法團(tuán)隊來實(shí)現(xiàn)的，因此雙方需要進(jìn)行算法相關(guān)的對接。

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

當(dāng)前我們主要運(yùn)用的還是基于規(guī)則路由的機(jī)制，但是隨著服務(wù)場景和服務(wù)提供者的增多，我們會更多地融入基于 AI 的決策機(jī)制。

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

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

過去的單輪交互是：有一個請求進(jìn)來，就給出一個答案。而如今 AI 所應(yīng)對的復(fù)雜業(yè)務(wù)一般需要進(jìn)行多輪交互。

如前面提到的航旅推薦的例子：在交互了是否要旅行之后；需要進(jìn)一步詢問是國內(nèi)還是國外游；如果是國外游的話，還需詢問目標(biāo)地區(qū)?？梢姸噍喗换バ枰?AI 具有語意匹配和意圖識別等較強(qiáng)的交互能力。

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

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

由于我們本質(zhì)上是通過基于消息驅(qū)動的邏輯來實(shí)現(xiàn)的，如上圖從左至右所示：事件源接入→標(biāo)準(zhǔn)化→安全脫敏→事件中心與調(diào)度中心的控制。與此同時，外面的 AI 服務(wù)接入于此→注冊授權(quán)→開放接口→整體監(jiān)控。

我們之所以將 AI 的服務(wù)能力單獨(dú)劃分出來，是因?yàn)樾枰ㄟ^與其他團(tuán)隊合作，來實(shí)現(xiàn)外部的搜索、意圖識別、知識庫、多輪交互、情感分析等能力。

我們的 Bot 不僅可以與買家端交互，也可以與客服進(jìn)行交互。類似于店小秘，作為認(rèn)知服務(wù)的 API 可供各個業(yè)務(wù)方去調(diào)用。

對于用戶的聊天數(shù)據(jù)、客服的績效、其當(dāng)天的狀態(tài)、每個客戶角色的數(shù)據(jù)、以及店鋪的商品數(shù)據(jù)，我們通過底層數(shù)據(jù)的沉淀功能，可供不同場景進(jìn)行調(diào)用，從而實(shí)現(xiàn)了快速開發(fā)和輕量級的服務(wù)提供。

總結(jié)

結(jié)合場景抽象出業(yè)務(wù)本質(zhì)的模型來指導(dǎo)設(shè)計：根據(jù)前面所提及的基于事件驅(qū)動的概念，大量的事件都是由商品交易或聊天互動所觸發(fā)產(chǎn)生，并形成了聯(lián)動場景。

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

跟隨著業(yè)務(wù)的復(fù)雜性不斷的調(diào)整和優(yōu)化架構(gòu)設(shè)計：我們沒有必要一定采用所謂“最牛”的中間件方案。只有最適合自己的業(yè)務(wù)場景才是***的架構(gòu)設(shè)計。

團(tuán)隊成員統(tǒng)一架構(gòu)上的認(rèn)知：我常在團(tuán)隊里說，“架構(gòu)只有適合與否，沒有好壞之分。使用一個好的架構(gòu)，你當(dāng)然能夠?qū)崿F(xiàn)某個業(yè)務(wù)需求；而使用一個差的架構(gòu)，你同樣也能最終實(shí)現(xiàn)該業(yè)務(wù)需求。”

因此全部團(tuán)隊成員都應(yīng)當(dāng)有一致的架構(gòu)認(rèn)知。只有這樣每個人才能在編寫業(yè)務(wù)代碼時，主動思考自己所實(shí)現(xiàn)的功能應(yīng)該如何在整個架構(gòu)體系里達(dá)到平衡與和諧處理，以及放置在何處才最為合適。

相反，如果團(tuán)隊成員對于架構(gòu)的認(rèn)知不一致，那么就有可能會導(dǎo)致組織內(nèi)部的代碼風(fēng)格和運(yùn)行方式出現(xiàn)不一致的情況。因此統(tǒng)一認(rèn)識對于帶領(lǐng)團(tuán)隊去滿足需求和實(shí)現(xiàn)業(yè)務(wù)都是至關(guān)重要的。

[[229332]]

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

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】