全文約9000字，預(yù)計閱讀時間19分鐘

1. 困境：項目背景

愛番番溝通基于百度商橋快速完成了產(chǎn)品功能和技術(shù)架構(gòu)的從無到有，但同時也繼承了百度商橋歷史功能繁雜、技術(shù)架構(gòu)陳舊的缺點。為了能更好地服務(wù)于愛番番溝通將來的產(chǎn)品演進(jìn)，提高產(chǎn)研能效，需要從實際問題出發(fā)，聚焦主要矛盾，對產(chǎn)品架構(gòu)和業(yè)務(wù)架構(gòu)進(jìn)行重構(gòu)。

為了更好的理解本文內(nèi)容，以下是必要的名詞解釋：

名詞

解釋

訪客

瀏覽客戶網(wǎng)站的網(wǎng)民

C端

瀏覽客戶網(wǎng)站網(wǎng)民看到的咨詢圖標(biāo)、邀請框、溝通窗口、留言板

B端

客服接待網(wǎng)民咨詢的工作臺，即客服業(yè)務(wù)系統(tǒng)的客戶端、手機端、網(wǎng)頁端

進(jìn)站

網(wǎng)民打開客戶的網(wǎng)站進(jìn)行瀏覽

離站

網(wǎng)民關(guān)閉了客戶的網(wǎng)站

DDD

Domain Driven Design，領(lǐng)域驅(qū)動設(shè)計，一種旨在解決復(fù)雜系統(tǒng)的設(shè)計方法論

愛番番溝通是連接訪客和商家的在線咨詢工具。一方面訪客可以隨時隨地咨詢，縮短訪客獲取服務(wù)的途徑，另一方面商家也可以快速響應(yīng)并提供服務(wù)。同時在推廣場景中，商家還可以根據(jù)訪客的咨詢內(nèi)容反哺回上游廣告通路，優(yōu)化投放模型，提升營銷轉(zhuǎn)化效果。

1.2 為什么要重構(gòu)？

百度商橋經(jīng)歷了幾次不同的產(chǎn)品定位和多年版本迭代，產(chǎn)研團(tuán)隊也換了幾波人。客戶問題較多，架構(gòu)長期缺乏系統(tǒng)性治理。給產(chǎn)研團(tuán)隊帶來多個層面的掣肘：

團(tuán)隊內(nèi)對產(chǎn)品的主要業(yè)務(wù)邏輯沒有知識儲備。經(jīng)常需要研發(fā)去翻閱項目代碼東拼西湊出現(xiàn)有邏輯的大致模樣。

客戶反饋問題數(shù)量居高不下，典型問題如：

訪客進(jìn)站識別不及時，客服感知不到訪客已進(jìn)站。訪客離站識別不及時，容易誤導(dǎo)客服向離站的訪客繼續(xù)發(fā)起溝通，引發(fā)溝通不暢的表象；

訪客的廣告相關(guān)信息（來源、搜索詞、關(guān)鍵詞）獲取不及時、不完整；

訪客全生命周期內(nèi)的行為數(shù)據(jù)有概率性延遲和缺失；

商家歡迎語、自動回復(fù)發(fā)送順序錯亂，不觸發(fā)發(fā)送等；

服務(wù)穩(wěn)定性引起的登錄失敗，消費發(fā)送失敗、移動端消息提醒不及時等；

還有一部分客戶問題屬于新需求范疇，比如咨詢組件樣式靈活定制、支持離線溝通。

展開全文

訪客進(jìn)站識別不及時，客服感知不到訪客已進(jìn)站。訪客離站識別不及時，容易誤導(dǎo)客服向離站的訪客繼續(xù)發(fā)起溝通，引發(fā)溝通不暢的表象；

訪客的廣告相關(guān)信息（來源、搜索詞、關(guān)鍵詞）獲取不及時、不完整；

訪客全生命周期內(nèi)的行為數(shù)據(jù)有概率性延遲和缺失；

商家歡迎語、自動回復(fù)發(fā)送順序錯亂，不觸發(fā)發(fā)送等；

服務(wù)穩(wěn)定性引起的登錄失敗，消費發(fā)送失敗、移動端消息提醒不及時等；

還有一部分客戶問題屬于新需求范疇，比如咨詢組件樣式靈活定制、支持離線溝通。

團(tuán)隊士氣低落，生產(chǎn)力不高。疲于應(yīng)對救火問題，難以承接較大功能需求開發(fā)。

現(xiàn)有架構(gòu)陳舊，模塊繁雜，長期缺乏治理。模塊數(shù)量和人員規(guī)模失配，小需求可能涉及多個模塊改動。存在大量陳舊代碼，只能不停地進(jìn)行『打補丁』方式修復(fù)問題。

2. 反思：定義問題和挑戰(zhàn)

面對當(dāng)前困境，整個產(chǎn)研團(tuán)隊都意識到了需要盡快做出改變。透過現(xiàn)象找本質(zhì)，上述現(xiàn)象背后的關(guān)鍵問題是什么呢？又會面臨哪些挑戰(zhàn)呢？

2.1 定義問題

通過進(jìn)一步分析問題的根本原因，可以把問題分為以下幾類：

【產(chǎn)品層面】產(chǎn)品方向及定位不明確，功能層級及分類不清晰

產(chǎn)品演進(jìn)方向不清晰，業(yè)務(wù)領(lǐng)域主次不清，各模塊的業(yè)務(wù)主路徑不清晰。平時開發(fā)都是堆砌功能，導(dǎo)致不少業(yè)務(wù)場景存在使用體驗的卡點；

由于歷史原因系統(tǒng)支持的角色冗余且復(fù)雜，既有平臺型角色比如支持百度顧問和商家直接溝通。又有B端其他角色比如支持銷售直接查看線索；

從PC時代到移動時代，但是產(chǎn)品還保留著一些歷史兼容的痕跡。比如常用語是按照PC和移動進(jìn)行一級分類，站點樣式類型只能設(shè)置一個端。

產(chǎn)品演進(jìn)方向不清晰，業(yè)務(wù)領(lǐng)域主次不清，各模塊的業(yè)務(wù)主路徑不清晰。平時開發(fā)都是堆砌功能，導(dǎo)致不少業(yè)務(wù)場景存在使用體驗的卡點；

由于歷史原因系統(tǒng)支持的角色冗余且復(fù)雜，既有平臺型角色比如支持百度顧問和商家直接溝通。又有B端其他角色比如支持銷售直接查看線索；

從PC時代到移動時代，但是產(chǎn)品還保留著一些歷史兼容的痕跡。比如常用語是按照PC和移動進(jìn)行一級分類，站點樣式類型只能設(shè)置一個端。

舊版客戶端界面示例

【架構(gòu)層面】客戶端架構(gòu)多年未演進(jìn)，功能迭代難以為繼

客戶端僅支持Windows系統(tǒng)且架構(gòu)一直未演進(jìn)，技術(shù)?；贑++，和團(tuán)隊主要技術(shù)棧偏離，只能艱難維護(hù)，無力承接新功能需求。迫切需要演進(jìn)為能跨平臺、主流的、前端技術(shù)棧；

訪客側(cè)前端還未做到前后端分離架構(gòu)，體驗和開發(fā)效率大打折扣。

客戶端僅支持Windows系統(tǒng)且架構(gòu)一直未演進(jìn)，技術(shù)?；贑++，和團(tuán)隊主要技術(shù)棧偏離，只能艱難維護(hù)，無力承接新功能需求。迫切需要演進(jìn)為能跨平臺、主流的、前端技術(shù)棧；

訪客側(cè)前端還未做到前后端分離架構(gòu)，體驗和開發(fā)效率大打折扣。

【架構(gòu)層面】服務(wù)端架構(gòu)的基礎(chǔ)溝通層待演進(jìn)

溝通協(xié)議層作為溝通產(chǎn)品非常重要的一環(huán)，還存在架構(gòu)方面的不足：

多種網(wǎng)絡(luò)連接協(xié)議下的穩(wěn)定性需提高；

和不同端的消息發(fā)送性能需提高。

多種網(wǎng)絡(luò)連接協(xié)議下的穩(wěn)定性需提高；

和不同端的消息發(fā)送性能需提高。

【架構(gòu)層面】服務(wù)端架構(gòu)的業(yè)務(wù)層待演進(jìn)

業(yè)務(wù)層包含 20+ 服務(wù)模塊，主要的業(yè)務(wù)邏輯采用共享庫的方式維護(hù)，導(dǎo)致模塊邊界不清，數(shù)據(jù)鏈路混亂，功能重疊耦合嚴(yán)重，迫切需要演進(jìn)為主流微服務(wù)架構(gòu)。

模塊內(nèi)職責(zé)不夠內(nèi)聚，模塊間調(diào)用關(guān)系耦合高；

同樣的數(shù)據(jù)存在多份存儲，數(shù)據(jù)一致性存在問題；

數(shù)據(jù)流的同步異步傳輸鏈路混亂。

模塊內(nèi)職責(zé)不夠內(nèi)聚，模塊間調(diào)用關(guān)系耦合高；

同樣的數(shù)據(jù)存在多份存儲，數(shù)據(jù)一致性存在問題；

數(shù)據(jù)流的同步異步傳輸鏈路混亂。

【架構(gòu)層面】整體服務(wù)端架構(gòu)自運維成本高，可維護(hù)性很低

歷史遺留系統(tǒng)中需要運維多種自運維中間件，導(dǎo)致團(tuán)隊不能聚焦業(yè)務(wù)功能開發(fā)。既降低了研發(fā)生產(chǎn)力，也給系統(tǒng)穩(wěn)定性帶來巨大挑戰(zhàn)。

自運維了反向代理 Nginx 集群、Zookeeper 集群、Storm 集群、Kafka 集群、Solr 集群、Prometheus 集群；

離部門的主服務(wù)端集群面向云原生的服務(wù)治理架構(gòu)還有不小差距。

自運維了反向代理 Nginx 集群、Zookeeper 集群、Storm 集群、Kafka 集群、Solr 集群、Prometheus 集群；

離部門的主服務(wù)端集群面向云原生的服務(wù)治理架構(gòu)還有不小差距。

【組織層面】產(chǎn)研團(tuán)隊整體對業(yè)務(wù)的理解不夠且未拉齊

業(yè)務(wù)架構(gòu)和研發(fā)架構(gòu)長期脫鉤，導(dǎo)致團(tuán)隊對大到溝通行業(yè)小到具體某個模塊的領(lǐng)域知識沉淀缺乏，迫切需要在產(chǎn)研層面拉齊現(xiàn)有認(rèn)知；

在團(tuán)隊達(dá)成共識的基礎(chǔ)上將來才能形成隨產(chǎn)品快速演進(jìn)從而快速迭代領(lǐng)域認(rèn)知的正向循環(huán)。

業(yè)務(wù)架構(gòu)和研發(fā)架構(gòu)長期脫鉤，導(dǎo)致團(tuán)隊對大到溝通行業(yè)小到具體某個模塊的領(lǐng)域知識沉淀缺乏，迫切需要在產(chǎn)研層面拉齊現(xiàn)有認(rèn)知；

在團(tuán)隊達(dá)成共識的基礎(chǔ)上將來才能形成隨產(chǎn)品快速演進(jìn)從而快速迭代領(lǐng)域認(rèn)知的正向循環(huán)。

2.2 認(rèn)清挑戰(zhàn)

歸因清楚問題后，重構(gòu)的方向逐漸清晰起來。但執(zhí)行落地階段也會面臨著業(yè)務(wù)演進(jìn)壓力，原架構(gòu)基礎(chǔ)薄弱，資源短缺等挑戰(zhàn)。

架構(gòu)陳舊，代碼里有不少隱蔽的『坑』

從以往經(jīng)歷看，有時候一個很小的改動，看起來很有把握的一次上線也可能造成客戶問題。一方面代碼中缺乏設(shè)計的地方多，另一方面整體回歸測試覆蓋不全。組內(nèi)自嘲這種狀態(tài)為『每一行代碼都剛剛好』，不能多也不能少。

重構(gòu)和業(yè)務(wù)演進(jìn)既要又要

這個挑戰(zhàn)是大部分團(tuán)隊都會遇到的，業(yè)務(wù)不可能停止演進(jìn)等待技術(shù)重構(gòu)。如何能在不影響已有業(yè)務(wù)且保證部分高優(yōu)業(yè)務(wù)需求正常迭代的情況下進(jìn)行重構(gòu)是必須要回答的問題。

不能僅僅是重構(gòu)，客戶可感知的體驗要更好

涉及客戶端架構(gòu)升級，必然會帶來一些新的用戶體驗，需要管理好存量用戶的預(yù)期。本次重構(gòu)范圍大，產(chǎn)品質(zhì)量不下降既是要求也是挑戰(zhàn)。

產(chǎn)研團(tuán)隊較新，對原有業(yè)務(wù)功能缺乏足夠了解

業(yè)務(wù)研發(fā)團(tuán)隊很依賴領(lǐng)域?qū)＜业臉I(yè)務(wù)知識指導(dǎo)，子領(lǐng)域間和模塊間的職責(zé)和邊界劃分，數(shù)據(jù)歸屬等理解需要建立在業(yè)務(wù)理解的基礎(chǔ)上。這些對現(xiàn)有團(tuán)隊是個不小的挑戰(zhàn)。

因此，抓主要矛盾，分階段小步快跑是本次重構(gòu)的基調(diào)。

3. 紓困：解決問題

僅僅從技術(shù)層面做重構(gòu)只能解決眼前的技術(shù)問題，隨著業(yè)務(wù)快速迭代，純技術(shù)重構(gòu)的成果很容易消失殆盡?？紤]到需要對業(yè)務(wù)和技術(shù)層面雙管齊下做出改變，在現(xiàn)有復(fù)雜業(yè)務(wù)基礎(chǔ)上仍能保持高效的產(chǎn)研交付效率，加上隔壁兄弟團(tuán)隊之前在線索管家產(chǎn)品已經(jīng)收獲了 DDD 改造的收益，因此本次技術(shù)重構(gòu)決定結(jié)合 DDD 來做，從產(chǎn)品到技術(shù)來一次認(rèn)知升級、架構(gòu)升級。

3.1 定位：確定產(chǎn)品方向及核心痛點

產(chǎn)品定位及差異價值

產(chǎn)品定位：選擇『不做什么』更加重要

聚焦在售前接待場景，幫助商家獲取聯(lián)系方式，不做售后服務(wù)場景；

聚焦在廣告營銷場景，幫助廣告主接待推廣流量并優(yōu)化效果；

由于是 ToB SaaS 模式，所以暫時聚焦企業(yè)客戶需求，不做平臺型針對企業(yè)的上層需求。

聚焦在售前接待場景，幫助商家獲取聯(lián)系方式，不做售后服務(wù)場景；

聚焦在廣告營銷場景，幫助廣告主接待推廣流量并優(yōu)化效果；

由于是 ToB SaaS 模式，所以暫時聚焦企業(yè)客戶需求，不做平臺型針對企業(yè)的上層需求。

產(chǎn)品使用角色：誰是我們的用戶？

聚焦在B端客服角色。剝離其他角色相關(guān)功能，比如跟進(jìn)線索的名片功能歸到線索管家模塊（銷售角色），反哺功能歸到 oCPC 反哺模塊（SEM角色）。

聚焦在B端客服角色。剝離其他角色相關(guān)功能，比如跟進(jìn)線索的名片功能歸到線索管家模塊（銷售角色），反哺功能歸到 oCPC 反哺模塊（SEM角色）。

差異化價值：客戶為什么會選擇我們？

全鏈路閉環(huán)：從推廣開始到訪客進(jìn)站、對話、留資，直至標(biāo)記會話反饋oCPC目標(biāo)，全程無縫銜接；

與線索管家結(jié)合：智能識別會話和留言板中的線索信息，自動沉淀至線索管家，有效節(jié)省線索梳理工作；

智能營銷：訪客意圖智能分析識別，千人千話引導(dǎo)訪客開口留資；

多端共用：支持 Web、App、PC 端同時使用，隨時隨地實現(xiàn)溝通。

全鏈路閉環(huán)：從推廣開始到訪客進(jìn)站、對話、留資，直至標(biāo)記會話反饋oCPC目標(biāo)，全程無縫銜接；

與線索管家結(jié)合：智能識別會話和留言板中的線索信息，自動沉淀至線索管家，有效節(jié)省線索梳理工作；

智能營銷：訪客意圖智能分析識別，千人千話引導(dǎo)訪客開口留資；

多端共用：支持 Web、App、PC 端同時使用，隨時隨地實現(xiàn)溝通。

3.2.1 事件風(fēng)暴：剖析流程和對齊認(rèn)知的好幫手

針對主要業(yè)務(wù)流程，產(chǎn)研團(tuán)隊通過事件風(fēng)暴的方式梳理了事件流，定義了每個事件相關(guān)的角色、動作、規(guī)則條件和事件結(jié)果。最重要的是對齊了團(tuán)隊的業(yè)務(wù)認(rèn)知，靠集體智慧剖析了整體業(yè)務(wù)細(xì)節(jié)。

3.2.2 邊界是合作的基礎(chǔ)：劃分領(lǐng)域和模塊，形成統(tǒng)一語言

根據(jù)產(chǎn)品定位及產(chǎn)品價值分析，結(jié)合梳理好的業(yè)務(wù)流程，需要劃分子領(lǐng)域，相應(yīng)配比合適的資源投入。

【核心域】

訪客域和客服域?qū)儆诤诵挠虮容^自然，同時作為底層的基礎(chǔ)能力，協(xié)議連接域包括tcp、websocket、http、long polling協(xié)議，協(xié)議報文格式，連接狀態(tài)維護(hù)等也應(yīng)該是核心域。其次會話域也是核心域，互發(fā)消息才算進(jìn)入真正溝通，會話內(nèi)容里的意圖表達(dá)和留資才是溝通的主要目的；

核心域的策略是圍繞產(chǎn)品價值，重點投入資源。盡可能把非核心功能從核心域剝離，警惕容易引起團(tuán)隊失焦的投入。

訪客域和客服域?qū)儆诤诵挠虮容^自然，同時作為底層的基礎(chǔ)能力，協(xié)議連接域包括tcp、websocket、http、long polling協(xié)議，協(xié)議報文格式，連接狀態(tài)維護(hù)等也應(yīng)該是核心域。其次會話域也是核心域，互發(fā)消息才算進(jìn)入真正溝通，會話內(nèi)容里的意圖表達(dá)和留資才是溝通的主要目的；

核心域的策略是圍繞產(chǎn)品價值，重點投入資源。盡可能把非核心功能從核心域剝離，警惕容易引起團(tuán)隊失焦的投入。

【支撐域】

數(shù)據(jù)分析域是必要的功能但目前還不是重點，線索域?qū)贤▉碚f是后鏈路必經(jīng)環(huán)節(jié)，但應(yīng)該更多利用愛番番線索管家的能力。廣告域包含訪客推廣信息解析，會話效果反哺，照理是核心能力。但這里劃為支持域是因為關(guān)鍵的能力在搜索團(tuán)隊已提供，溝通團(tuán)隊做好數(shù)據(jù)接入和數(shù)據(jù)供給工作；

支撐域的策略是盡可能以較少資源建設(shè)必要能力。當(dāng)然，隨著業(yè)務(wù)的發(fā)展支撐域也可能在未來變成核心域。

數(shù)據(jù)分析域是必要的功能但目前還不是重點，線索域?qū)贤▉碚f是后鏈路必經(jīng)環(huán)節(jié)，但應(yīng)該更多利用愛番番線索管家的能力。廣告域包含訪客推廣信息解析，會話效果反哺，照理是核心能力。但這里劃為支持域是因為關(guān)鍵的能力在搜索團(tuán)隊已提供，溝通團(tuán)隊做好數(shù)據(jù)接入和數(shù)據(jù)供給工作；

支撐域的策略是盡可能以較少資源建設(shè)必要能力。當(dāng)然，隨著業(yè)務(wù)的發(fā)展支撐域也可能在未來變成核心域。

【通用域】

賬號權(quán)限功能是大多數(shù)系統(tǒng)的通用能力。訪客場景屬于ToC場景，會遇到黑產(chǎn)流量攻擊，包括訪客進(jìn)站和訪客發(fā)送消息需要引入風(fēng)控反作弊能力。愛番番溝通主要借助了愛番番策略團(tuán)隊和廠內(nèi)安全部的能力；

通用域的策略是盡可能不親自建設(shè)系統(tǒng)，借助外部能力快速完成能力建設(shè)。

3.3架構(gòu)：搭建整體技術(shù)架構(gòu)

架構(gòu)目標(biāo)及設(shè)計要點

3.4 突破：架構(gòu)設(shè)計的關(guān)鍵技術(shù)

3.4.1 落地真正的微服務(wù)架構(gòu)

隨著子領(lǐng)域和模塊的劃分確定后，需要調(diào)整對應(yīng)的模塊職責(zé)及模塊間協(xié)作關(guān)系進(jìn)行改造，重點改造點包括：

合并老模塊

改造前服務(wù)端有45+服務(wù)模塊，服務(wù)職責(zé)劃分不當(dāng)，服務(wù)粒度不合適。具體表現(xiàn)為：

經(jīng)過合并下線改造后，服務(wù)數(shù)量減少了 15+。

拆分新模塊

有些功能很重要，需要形成獨立的模塊重點建設(shè)。比如：

模塊間不共享業(yè)務(wù)邏輯

改造前的后端業(yè)務(wù)服務(wù)不是真正的微服務(wù)，雖然都是獨立部署，各自暴露接口，但服務(wù)實現(xiàn)層耦合嚴(yán)重：

改造原則：不共享包括業(yè)務(wù)邏輯的公共庫，讓微服務(wù)垂直劃分，相關(guān)業(yè)務(wù)數(shù)據(jù)（包括緩存數(shù)據(jù)）歸服務(wù)私有，通過 API 接口提供能力，或者通過領(lǐng)域事件推動下游流程。

最終一致性前提下的高可用性

可用性的關(guān)鍵手段是數(shù)據(jù)復(fù)制?？梢越柚煌臄?shù)據(jù)同步方法，結(jié)合不同特點的存儲類型完成多樣化業(yè)務(wù)場景的高可用性。常用的數(shù)據(jù)復(fù)制/同步手段有：

當(dāng)然，這種可用性往往會犧牲一定時效性內(nèi)的數(shù)據(jù)一致性，需要根據(jù)實際業(yè)務(wù)場景做出權(quán)衡。根據(jù)經(jīng)驗判斷在馬上得到答案和得到正確答案之間，大多數(shù)人更想要的其實是馬上得到答案。

3.4.2 數(shù)據(jù)鏈路治理

storm 拓?fù)湓O(shè)計不合理，拓?fù)涔?jié)點職責(zé)不清；

拓?fù)涔?jié)點中存在大量的業(yè)務(wù)邏輯，普遍利用 redis 傳遞數(shù)據(jù)，redis 鍵設(shè)計混亂，可維護(hù)性很差；

storm 集群是幾年前引入的，版本低，一直沒升級。

經(jīng)過分析業(yè)務(wù)需求，只升級 storm 集群版本不會解決實際問題，另外實時計算框架在現(xiàn)階段不是必須項，因此得出了以下改造思路：

去除這個集中式的計算集群，按業(yè)務(wù)場景梳理各自數(shù)據(jù)流，避免互相干擾。讓對應(yīng)業(yè)務(wù)服務(wù)模塊承接業(yè)務(wù)邏輯，如需提高業(yè)務(wù)響應(yīng)可通過緩存集群加速；

訪客一段時間不說話需要自動回復(fù)等延時場景通過延時任務(wù)的方案解決；

redis key 重新梳理，優(yōu)化大 key（ 一個 key 承載的內(nèi)容特別大，比如一個key 就包含全系統(tǒng)訪客的部分信息，這樣的 key 設(shè)計顯然太大 ），盡量不跨服務(wù)模塊直接操作 redis。

業(yè)務(wù)程序的靈魂是數(shù)據(jù)，技術(shù)架構(gòu)時要多花時間考慮數(shù)據(jù)存儲和讀取的方方面面。比如用什么存儲系統(tǒng)（ 存儲系統(tǒng)不可能讀也最快，寫也最快，需要權(quán)衡 ）、什么時候用緩存，整個業(yè)務(wù)流程的數(shù)據(jù)傳輸鏈路應(yīng)該怎么樣，溝通系統(tǒng)涉及到很多寫放大還是讀放大的權(quán)衡等等。本次重構(gòu)也涉及到了這些方面的梳理和改造，在此不一一介紹。

3.4.3 溝通協(xié)議優(yōu)化為什么要做協(xié)議優(yōu)化？

針對 1.2 章節(jié)中提到的客戶端上經(jīng)常出現(xiàn)丟訪客，消息不上屏等問題，簡單的打補丁方式已經(jīng)難以將問題徹底解決，因此必須從協(xié)議層進(jìn)行徹底的改造優(yōu)化。詳細(xì)痛點如下：

1、上面提到分布式鎖控制并發(fā)，會因鎖競爭而增加請求處理時間嗎？

答：鎖粒度為單個訪客粒度，粒度足夠小，而且同一個訪客在快速操作（ 如頻繁快速打開頁面、發(fā)起溝通 ）時，才會出現(xiàn)鎖競爭的情況，對單訪客來說，常規(guī)的操作并發(fā)不大。

2、既然協(xié)議優(yōu)化收益這么搞，為什么不早點做協(xié)議優(yōu)化呢？

答：之前受限于業(yè)務(wù)邊界劃分不清晰，訪客狀態(tài)變更散落在業(yè)務(wù)前臺、業(yè)務(wù)后臺、原 storm 集群多個地方，無法做統(tǒng)一管控。只有在完成了前期建構(gòu)優(yōu)化、數(shù)據(jù)鏈路治理完成之后，站在原有的工作成果至上，才能做協(xié)議優(yōu)化。

3、客戶端的推拉結(jié)合為什么不早點做呢？

答：如前文 2.1 中第 2 條所說，客戶端技術(shù)?；?C++，只能艱難維護(hù)，無力承接新功能需求。因此想改動客戶端的協(xié)議，可謂異常艱難，這也是下文 3.5 章節(jié)客戶端架構(gòu)升級的一大原因。

小結(jié)

如前面所述由于歷史技術(shù)棧原因愛番番溝通團(tuán)隊內(nèi)部運維了好幾種中間件，先不說引入這些中間件的正確與否，現(xiàn)狀是沒有足夠知識儲備，既給系統(tǒng)帶來了很多不穩(wěn)定因素，也降低了團(tuán)隊的研發(fā)效率。因此本次重構(gòu)在這個方面的改造原則是優(yōu)先考慮下線架構(gòu)中不必要的中間件，必要的中間件也不另行維護(hù)，遷移到部門基礎(chǔ)技術(shù)團(tuán)隊運維。

集群改造下線

Zookeeper 集群：改造前主要用來做業(yè)務(wù)配置中心，遷移到 k8s 更友好的ConfigMap（ 由基礎(chǔ)技術(shù)團(tuán)隊運維 ）；

Nginx 集群：改造前有好幾套反向代理集群，其中既有路由轉(zhuǎn)發(fā)邏輯，也有業(yè)務(wù)邏輯。業(yè)務(wù)邏輯下沉至對應(yīng)的 gateway 服務(wù)，由團(tuán)隊維護(hù)。路由轉(zhuǎn)發(fā)邏輯遷移至 bfe 集群，由基礎(chǔ)技術(shù)團(tuán)隊統(tǒng)一運維；

Storm 集群：邏輯改造，下線。細(xì)節(jié)上面已交代；

Solr 集群：下線，相應(yīng)查詢邏輯改造遷移至 ES 集群。

此部分集群雖然不能下線，但團(tuán)隊內(nèi)不另行維護(hù)，轉(zhuǎn)而遷移至部門集群。包括Kafka 和 Prometheus 集群。

3.5 擴展：客戶端架構(gòu)實踐

3.5.1 客戶端跨平臺架構(gòu)

隨著原客戶端維護(hù)代價越來越大，結(jié)合客戶對 mac 端的訴求，因此選擇了跨平臺的 Electron 框架。

為什么選擇 Electron ？

開源的核心擴展比較容易。

界面定制性強，原則上只要是 Web 能做的它都能做。

是目前最廉價的跨平臺技術(shù)方案，HTML + JS 的技術(shù)儲備，而且有海量的現(xiàn)存 UI 庫。

相對其他跨平臺方案（ 如 QT GTK+ 等 ），更穩(wěn)定，bug 少， 只要瀏覽器跑起來了，問題不會太多 。

方便拓展，可以直接嵌入現(xiàn)有 web 頁面。

愛番番前端團(tuán)隊的技術(shù)棧是 Vue，所以我們選擇使用 Electron-Vue 來搭建項目。Electron 有兩個進(jìn)程，分別為主進(jìn)程（ main ）和渲染進(jìn)程（ renderer ）。主進(jìn)程中包含了客戶端自動更新、插件核心、系統(tǒng) API 等。渲染進(jìn)程是 vue + webpack 的架構(gòu)，兩個進(jìn)程間通過 ipc 進(jìn)行通信。

愛番番溝通考慮到今后能更靈活地接入更多業(yè)務(wù)垂類并且支持第三方自主開發(fā)個性化功能。同時需要兼顧平臺代碼的穩(wěn)定性和易用性，我們采用了插件化架構(gòu)的方式來實現(xiàn)客戶端。

開發(fā)中遇到的問題

Electron 帶來很大便利的同時，其本身也有很多硬傷。如常被人吐槽的內(nèi)存占用高、和原生客戶端性能差異、API 系統(tǒng)兼容性問題等。這些問題在開發(fā)過程中需要提前考慮到。下面是開發(fā)過程中必然會遇到的幾個問題。

1、性能優(yōu)化

性能優(yōu)化是在開發(fā)完需求功能后經(jīng)常需要考慮的。在 Electron 中，最好的分析工具就是 Chrome 開發(fā)者工具的 Performance ，通過火焰圖，JS 執(zhí)行過程的任何問題都可以直觀的看到。

2、Window7 系統(tǒng)下白屏問題

因為在測試過程中 QA 同學(xué)使用的一直都是 Win10 的系統(tǒng)，所以白屏問題一直沒有被發(fā)現(xiàn)。直到客戶端正式上線，白屏問題被集中反饋，至此我們開始重視白屏問題并積極解決。

3、其他問題

在 Electron 開發(fā)過程中還要注意一些常見問題。如讀寫文件的編碼問題，客戶端安全問題存在 rce，可被任意執(zhí)行命令，內(nèi)存使用率過高問題等。

3.5.2 微內(nèi)核/插件化架構(gòu)

什么是插件化架構(gòu)

插件化架構(gòu)就是軟件本身只提供插件運行時的核心（ pluginCore ），并為插件運行時提供訪問的接口（ pluginAPI ），通過插件平臺下載插件（ plugin ）后可以在軟件上完美運行。

最基本的例子就是 webpack，作為主流的構(gòu)建工具，webpack 只抽象了一個軟件運行時的環(huán)境，在不關(guān)心和改動這個系統(tǒng)已有的代碼前提下，卻能獨立開發(fā)新的插件來充實整個系統(tǒng)的能力。

pluginCore: 插件運行時核心；pluginAPI：為插件運行提供訪問接口；plugin：實現(xiàn)具體功能的插件。

插件化架構(gòu)優(yōu)勢

插件化架構(gòu)是開閉原則在跨系統(tǒng)級別的最佳實踐。在插件核心和接口不變情況下，系統(tǒng)可以持續(xù)接入新插件，來豐富系統(tǒng)的功能。在一個非插件化的系統(tǒng)中，隨著功能模塊的增多，代碼量激增，在引入新功能和修復(fù)BUG都會越來越困難和低效。但插件化架構(gòu)不管已有系統(tǒng)功能多復(fù)雜，開發(fā)新的功能的復(fù)雜度始終一樣。而且隨著系統(tǒng)的平臺化，第三方接入差異化功能也不會影響系統(tǒng)的穩(wěn)定性。

愛番番插件化現(xiàn)狀

為了滿足其他第三方平臺的定制化需求，如電商平臺的商品及訂單模塊，CRM平臺的客戶模塊，售后場景中的評價模塊，愛番番客戶端的插件化架構(gòu)的設(shè)計要點：

4. 歡喜：解決效果

4.1 產(chǎn)品架構(gòu)升級

新客戶端設(shè)計原則：

按照 DDD 原則，來定義菜單模塊并抽象功能層級；

結(jié)構(gòu)對比老版層級更加清晰，功能擴展性更強；

容器變更并重新定義，釋放核心會話功能的區(qū)域；

三端（ Mac + Win + Web ）合一，共用一套產(chǎn)品設(shè)計，操作靈活便捷。

4.2 客戶體驗提升

遷移后，我們對新客戶端的使用客戶進(jìn)行了回訪，除了需求的反饋，也收到了一些肯定：

客戶

回訪回復(fù)

客服A

愛番番溝通改版后，開始很不習(xí)慣，但是用了一段時間后，感覺操作比之前方便，尤其是訪客多的時候，可以更有針對性的接待訪客，不錯。

客服B

有客人來聊天，留電話直接就能轉(zhuǎn)線索，我再聯(lián)系跟進(jìn)，還挺方便的。

客服C

挺好的，現(xiàn)在功能一目了然，訪客備注以及線索也是很方便了。

客服D

新客戶端我看都改成速度快的這種direct UI了，以前的客戶端感覺比較老嘛，不是很新潮的UI風(fēng)格，現(xiàn)在的這個UI風(fēng)格我感覺挺好的。

4.3 產(chǎn)研效能大幅提升

技術(shù)為產(chǎn)品服務(wù)，產(chǎn)研共同創(chuàng)造業(yè)務(wù)價值。產(chǎn)研效能是技術(shù)重構(gòu)的首要目標(biāo)?？梢酝ㄟ^兩方面衡量效果。

需求的整體交付速度

就像敏捷迭代的精髓不是看交付過程的單點效率，而是看發(fā)現(xiàn)需求到需求上線的整體效率。這也是通過 DDD 帶給這次技術(shù)重構(gòu)的最大價值。經(jīng)過需求和業(yè)務(wù)的分析、設(shè)計、實現(xiàn)等環(huán)節(jié)，讓產(chǎn)品、設(shè)計、研發(fā)整個團(tuán)隊的磨合和對業(yè)務(wù)的理解提升到新的高度，輔助以合理的技術(shù)架構(gòu)，能整體提升需求交付效率。

技術(shù)研發(fā)效率

直接體現(xiàn)是更少的人支撐更大的產(chǎn)品范圍。以前技術(shù)研發(fā) 12 人，現(xiàn)在 7人；

間接體現(xiàn)是代碼維護(hù)成本大大降低，服務(wù)模塊數(shù)量和團(tuán)隊人數(shù)比例協(xié)調(diào)，模塊職責(zé)和協(xié)作關(guān)系明確，接口設(shè)計質(zhì)量高，代碼規(guī)范度高，新人上手速度快。

4.4 產(chǎn)研效能大幅提升

4.4.1 系統(tǒng)穩(wěn)定性

4.4.2 可維護(hù)性

代碼維護(hù)成本大大降低，架構(gòu)在不同層面更具維護(hù)性：

服務(wù)模塊數(shù)量和團(tuán)隊人數(shù)比例協(xié)調(diào)；

模塊職責(zé)和協(xié)作關(guān)系明確；

業(yè)務(wù)數(shù)據(jù)流流轉(zhuǎn)鏈路清晰；

項目代碼 結(jié)構(gòu) 規(guī)范、易懂。 新人上手速度快；

接口文檔在線化。

4.4.3 可演進(jìn)性

愛番番溝通系統(tǒng)的潛在可演進(jìn)方向很多，有些方面已做好設(shè)計預(yù)留，比如：

更多溝通格式：已和業(yè)務(wù)系統(tǒng)解耦，很容易增加溝通內(nèi)容格式如視頻、語音等；

更多連接形式：目前已支持包括 http、tcp、websocket、long polling 等推拉形式協(xié)議，幾乎滿足了絕大部分場景；

；更多業(yè)務(wù)類型接入：基礎(chǔ)溝通能力已有開放能力，可利用 api 方式低成本接入

溝通功能的持續(xù)演進(jìn)：比如更智能化、和線索管家更無縫集成、更強的風(fēng)控能力，這些需求可按需建設(shè)相應(yīng)業(yè)務(wù)模塊，獨立演進(jìn)。

5. 成長：經(jīng)驗總結(jié)

通過這次重構(gòu)團(tuán)隊經(jīng)歷了從困境到反思的痛苦過程，相應(yīng)地也獲得了組織、技術(shù)、人等層面的成長。

組織

產(chǎn)研團(tuán)隊聚焦到創(chuàng)造業(yè)務(wù)價值，從能解決客戶問題視角開展日常工作；

產(chǎn)研協(xié)作效率更順暢，基于統(tǒng)一語言溝通需求和設(shè)計；

在業(yè)務(wù)迭代過程中沉淀了領(lǐng)域知識。

技術(shù)

技術(shù)問題的答案往往要從業(yè)務(wù)中尋找答案，理解業(yè)務(wù)是開展技術(shù)的前提。不同業(yè)務(wù)帶來不同的技術(shù)訴求，適配的技術(shù)才是最好的，也是先進(jìn)的；

經(jīng)過重構(gòu)的架構(gòu)能適配當(dāng)前業(yè)務(wù)發(fā)展，研發(fā)能把絕大部分精力放在業(yè)務(wù)實現(xiàn)上，屏蔽了日常開發(fā)的很多噪音。

人

通過本次重構(gòu)提高了每個成員對溝通業(yè)務(wù)的全方位熟悉。既有自身業(yè)務(wù)的全貌，也有行業(yè)友商的演進(jìn)現(xiàn)狀，對未來演進(jìn)方向有了對齊；

在了解技術(shù)架構(gòu)的來龍去脈和全貌基礎(chǔ)上，讓每個業(yè)務(wù)研發(fā)能聚焦建設(shè)自己負(fù)責(zé)的模塊。通過 DDD 實踐提升自己的應(yīng)用架構(gòu)水平，提供了技術(shù)進(jìn)階的新方向，發(fā)揮出模塊負(fù)責(zé)人的主觀能動性。

6. 星辰：未來展望

目前的愛番番溝通由于進(jìn)行了重新定位，方向更加聚焦，但同時也面臨著很多方向性的選擇。如：面對不同的上游場景以及不同的推廣平臺，后續(xù)的接入能力是否需要更加強大。智能機器人有些場景下的策略模型沒有保持持續(xù)迭代更新，是否需要往智能化方面更進(jìn)一步。

技術(shù)架構(gòu)的規(guī)劃首先應(yīng)該圍繞業(yè)務(wù)訴求展開，除此之外會繼續(xù)向云原生演進(jìn)，增加容量評估、全鏈路壓測、流量治理等能力。比如近期計劃把底層基座從 K8s 式微服務(wù)治理升級成服務(wù)網(wǎng)格，對齊愛番番主集群能力，便于以后能更好地復(fù)用基礎(chǔ)技術(shù)平臺的能力。同時進(jìn)一步降低多開發(fā)語言下的統(tǒng)一服務(wù)治理成本（ 接入層和協(xié)議連接層的服務(wù)是 golang，業(yè)務(wù)服務(wù)是 java ）。

在未來，如何做到「既要好，又要不同」愛番番溝通產(chǎn)研團(tuán)隊依然還有很長的路要走。

7. 作者介紹

本篇系愛番番溝通產(chǎn)研團(tuán)隊多位同學(xué)共同編寫。

飛邪：架構(gòu)師，擅長通過微服務(wù)架構(gòu)和 DDD 落地復(fù)雜系統(tǒng)；

堅果：產(chǎn)品經(jīng)理，擅長 ToB SaaS 及廣告產(chǎn)品；

甯甯：一個和商橋、在線溝通有不解之緣的產(chǎn)品經(jīng)理；

小麥：資深前端工程師，在光速演進(jìn)的前端領(lǐng)域內(nèi)苦苦掙扎的 FE；

flyme: 資深研發(fā)工程師，擅長通過改進(jìn)技術(shù)方案來應(yīng)對復(fù)雜多變的業(yè)務(wù)場景。