全文約9000字，預計閱讀時間19分鐘

1. 困境：項目背景

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

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

名詞

解釋

訪客

瀏覽客戶網站的網民

C端

瀏覽客戶網站網民看到的咨詢圖標、邀請框、溝通窗口、留言板

B端

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

進站

網民打開客戶的網站進行瀏覽

離站

網民關閉了客戶的網站

DDD

Domain Driven Design，領域驅動設計，一種旨在解決復雜系統(tǒng)的設計方法論

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

1.2 為什么要重構？

百度商橋經歷了幾次不同的產品定位和多年版本迭代，產研團隊也換了幾波人?？蛻魡栴}較多，架構長期缺乏系統(tǒng)性治理。給產研團隊帶來多個層面的掣肘：

團隊內對產品的主要業(yè)務邏輯沒有知識儲備。經常需要研發(fā)去翻閱項目代碼東拼西湊出現有邏輯的大致模樣。

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

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

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

訪客全生命周期內的行為數據有概率性延遲和缺失；

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

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

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

展開全文

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

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

訪客全生命周期內的行為數據有概率性延遲和缺失；

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

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

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

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

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

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

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

2.1 定義問題

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

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

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

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

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

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

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

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

舊版客戶端界面示例

【架構層面】客戶端架構多年未演進，功能迭代難以為繼

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

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

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

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

【架構層面】服務端架構的基礎溝通層待演進

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

多種網絡連接協議下的穩(wěn)定性需提高；

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

多種網絡連接協議下的穩(wěn)定性需提高；

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

【架構層面】服務端架構的業(yè)務層待演進

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

模塊內職責不夠內聚，模塊間調用關系耦合高；

同樣的數據存在多份存儲，數據一致性存在問題；

數據流的同步異步傳輸鏈路混亂。

模塊內職責不夠內聚，模塊間調用關系耦合高；

同樣的數據存在多份存儲，數據一致性存在問題；

數據流的同步異步傳輸鏈路混亂。

【架構層面】整體服務端架構自運維成本高，可維護性很低

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

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

離部門的主服務端集群面向云原生的服務治理架構還有不小差距。

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

離部門的主服務端集群面向云原生的服務治理架構還有不小差距。

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

業(yè)務架構和研發(fā)架構長期脫鉤，導致團隊對大到溝通行業(yè)小到具體某個模塊的領域知識沉淀缺乏，迫切需要在產研層面拉齊現有認知；

在團隊達成共識的基礎上將來才能形成隨產品快速演進從而快速迭代領域認知的正向循環(huán)。

業(yè)務架構和研發(fā)架構長期脫鉤，導致團隊對大到溝通行業(yè)小到具體某個模塊的領域知識沉淀缺乏，迫切需要在產研層面拉齊現有認知；

在團隊達成共識的基礎上將來才能形成隨產品快速演進從而快速迭代領域認知的正向循環(huán)。

2.2 認清挑戰(zhàn)

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

架構陳舊，代碼里有不少隱蔽的『坑』

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

重構和業(yè)務演進既要又要

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

不能僅僅是重構，客戶可感知的體驗要更好

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

產研團隊較新，對原有業(yè)務功能缺乏足夠了解

業(yè)務研發(fā)團隊很依賴領域專家的業(yè)務知識指導，子領域間和模塊間的職責和邊界劃分，數據歸屬等理解需要建立在業(yè)務理解的基礎上。這些對現有團隊是個不小的挑戰(zhàn)。

因此，抓主要矛盾，分階段小步快跑是本次重構的基調。

3. 紓困：解決問題

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

3.1 定位：確定產品方向及核心痛點

產品定位及差異價值

產品定位：選擇『不做什么』更加重要

聚焦在售前接待場景，幫助商家獲取聯系方式，不做售后服務場景；

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

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

聚焦在售前接待場景，幫助商家獲取聯系方式，不做售后服務場景；

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

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

產品使用角色：誰是我們的用戶？

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

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

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

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

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

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

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

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

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

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

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

3.2.1 事件風暴：剖析流程和對齊認知的好幫手

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

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

根據產品定位及產品價值分析，結合梳理好的業(yè)務流程，需要劃分子領域，相應配比合適的資源投入。

【核心域】

訪客域和客服域屬于核心域比較自然，同時作為底層的基礎能力，協議連接域包括tcp、websocket、http、long polling協議，協議報文格式，連接狀態(tài)維護等也應該是核心域。其次會話域也是核心域，互發(fā)消息才算進入真正溝通，會話內容里的意圖表達和留資才是溝通的主要目的；

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

訪客域和客服域屬于核心域比較自然，同時作為底層的基礎能力，協議連接域包括tcp、websocket、http、long polling協議，協議報文格式，連接狀態(tài)維護等也應該是核心域。其次會話域也是核心域，互發(fā)消息才算進入真正溝通，會話內容里的意圖表達和留資才是溝通的主要目的；

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

【支撐域】

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

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

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

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

【通用域】

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

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

3.3架構：搭建整體技術架構

架構目標及設計要點

3.4 突破：架構設計的關鍵技術

3.4.1 落地真正的微服務架構

隨著子領域和模塊的劃分確定后，需要調整對應的模塊職責及模塊間協作關系進行改造，重點改造點包括：

合并老模塊

改造前服務端有45+服務模塊，服務職責劃分不當，服務粒度不合適。具體表現為：

經過合并下線改造后，服務數量減少了 15+。

拆分新模塊

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

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

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

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

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

可用性的關鍵手段是數據復制。可以借助不同的數據同步方法，結合不同特點的存儲類型完成多樣化業(yè)務場景的高可用性。常用的數據復制/同步手段有：

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

3.4.2 數據鏈路治理

storm 拓撲設計不合理，拓撲節(jié)點職責不清；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小結

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

集群改造下線

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

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

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

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

此部分集群雖然不能下線，但團隊內不另行維護，轉而遷移至部門集群。包括Kafka 和 Prometheus 集群。

3.5 擴展：客戶端架構實踐

3.5.1 客戶端跨平臺架構

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

為什么選擇 Electron ？

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

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

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

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

方便拓展，可以直接嵌入現有 web 頁面。

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

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

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

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

1、性能優(yōu)化

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

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

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

3、其他問題

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

3.5.2 微內核/插件化架構

什么是插件化架構

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

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

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

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

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

愛番番插件化現狀

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

4. 歡喜：解決效果

4.1 產品架構升級

新客戶端設計原則：

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

結構對比老版層級更加清晰，功能擴展性更強；

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

三端（ Mac + Win + Web ）合一，共用一套產品設計，操作靈活便捷。

4.2 客戶體驗提升

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

客戶

回訪回復

客服A

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

客服B

有客人來聊天，留電話直接就能轉線索，我再聯系跟進，還挺方便的。

客服C

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

客服D

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

4.3 產研效能大幅提升

技術為產品服務，產研共同創(chuàng)造業(yè)務價值。產研效能是技術重構的首要目標?？梢酝ㄟ^兩方面衡量效果。

需求的整體交付速度

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

技術研發(fā)效率

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

間接體現是代碼維護成本大大降低，服務模塊數量和團隊人數比例協調，模塊職責和協作關系明確，接口設計質量高，代碼規(guī)范度高，新人上手速度快。

4.4 產研效能大幅提升

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

4.4.2 可維護性

代碼維護成本大大降低，架構在不同層面更具維護性：

服務模塊數量和團隊人數比例協調；

模塊職責和協作關系明確；

業(yè)務數據流流轉鏈路清晰；

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

接口文檔在線化。

4.4.3 可演進性

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

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

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

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

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

5. 成長：經驗總結

通過這次重構團隊經歷了從困境到反思的痛苦過程，相應地也獲得了組織、技術、人等層面的成長。

組織

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

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

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

技術

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

經過重構的架構能適配當前業(yè)務發(fā)展，研發(fā)能把絕大部分精力放在業(yè)務實現上，屏蔽了日常開發(fā)的很多噪音。

人

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

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

6. 星辰：未來展望

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

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

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

7. 作者介紹

本篇系愛番番溝通產研團隊多位同學共同編寫。

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

堅果：產品經理，擅長 ToB SaaS 及廣告產品；

甯甯：一個和商橋、在線溝通有不解之緣的產品經理；

小麥：資深前端工程師，在光速演進的前端領域內苦苦掙扎的 FE；

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