CRM系統化整合從N-1做減法實踐

1 背景

京銷易系統已經接入大網、KA以及雲倉三個條線商機，每個條線商機規則差異比較大，當前現狀是獨立實現三套系統分別做支撐。

2 目標

2022年下半年CRM目標是完成9個新條線業務接入，完成銷售過程線上化，實現銷售規則統一。

3 問題

前端實現資料儲存與邏輯程式碼耦合一起，無法複用，無法擴充套件，元件化拆分難度大。
元件拆分顆粒度較大，業務功能抽象不充分，缺乏複用性。
程式碼重複編寫，相似功能冗餘嚴重，開發和維護效率低。
程式碼版本多，介面不統一，開發、運維成本高，難擴充套件。
每個條線階段、條線內每個商機階段推進規則都是通過程式碼單獨實現，開發、維護成本高，規則調整都需要程式碼調整並上線，時效性低，同時階段規則維護在程式碼中，無法直觀呈現和規則統一收口，運維難度大。

4 實現

4.1 方案調研

方案調研階段，針對業務場景，多次組會對於底層實現方案進行充分討論，列舉每個方案優劣勢，選擇最適合當前業務場景的解決方案，最終選擇上圖的框架升級方案。

4.2 方案設計

4.2.1 設計思路

快速實現相似業務，減少相似程式碼，通過前端元件化、後端服務標準化、商機階段設定化技術手段，支援各條線快速複用和靈活擴充套件。

4.2.2 前端元件化

1.前端現狀

資料儲存與邏輯程式碼耦合在一起，無法複用，無法擴充套件，元件化拆分難度大。表現為mixins邏輯程式碼與store資料儲存耦合在一起，既降低了程式碼的可讀性，也降低了store資料讀寫的靈活性。舉個栗子，在人員資訊集合中，本來可以針對name和sex兩個欄位在各自的元件進行維護即可，可現實是兩個元件不得不呼叫同一個mixins進行維護。

元件拆分顆粒度較大，業務功能抽象不充分，缺乏複用性。元件的拆分沒有一個清晰的界限，沒有依據業務功能進行拆分，導致有一些元件不夠純粹，不符合單一職責原則，無法複用。在後期的維護過程中元件逐漸變得臃腫不堪。

程式碼重複編寫，相似功能冗餘嚴重，開發和維護效率低。由於元件無法複用，在後期維護過程中，開發人員對於類似的功能，不得不寫了很多相似的程式碼，致使整個專案程式碼冗餘、重複，慢慢的變得不可維護。

2.解決方案

針對本次商機條線接入功能，採用現有技術方案很難對後續條線依次接入，一個條線一套程式碼實現,接入週期長人力成本高，按期完成目標是一項不可能完成的挑戰。經過技術方案調研，決定搭建一套求同存異（同為各個條線共用部分，異為各個條線單獨部分）的前端元件化方案。依據業務功能，抽象出獨立業務元件模組，依據條線插拔式組裝，搭建出可維護、可延伸、靈活性高的元件積木化方案，在業務擴充套件性比較強的前端模組架構中優勢更加明顯。

元件積木化方案特點如下：

1.方案採用積木化前端元件搭建，其中任何一個元件都可以被替換（webComponent），任何一個父元件都可以擴充套件n個子元件。以上圖商機資訊元件為例，各條線商機資訊所包含的欄位存在差異，每個條線所對應的商機資訊元件不同，最終會根據條線選擇對應的元件載入。

2.資料統一管理（store），元件和資料之間為更新和依賴關係，當有元件更新資料時，其他元件也會立即更新，而不用相互傳值。以商機詳情元件為例，商機詳情中修改了商機名稱欄位，則所有用到商機名稱的元件都會得到更新。這需要提前對元件和store進行資料依賴更新的建立，通過computed與store雙向依賴和監控機制，當computed監聽store資料變化，將變化的資料更新到元件上，元件中通過store的mutaions更新資料到store上。

商機詳情元件化抽象示意圖如下：

4.2.3 後端標準化後端現狀

由於前期未對條線的領域模型和功能模組進行抽象，導致煙囪程式碼林立；每個條線接入都要重複開發多套程式碼，各端（PC、行動端）介面不統一，前後端聯調對接介面都需要區分多套；各條線獨立開發部署，隨著系統功能的豐富以及產品線持續增加，個性化需求和缺陷修復極大的消耗了研發資源和精力。同時，無法滿足各條線商機階段推進可客製化的業務訴求，大致狀態如下圖。

2.解決方案

通過梳理商機流程與功能可以發現，商機中各條線既有相同的功能模組，也有各自獨有的功能，例如商機建立、關閉、啟用等流程每個條線差異不大，但是有些相似的功能模組各條線也存在差異，例如大宗的關閉商機與服務+中的關閉商機各自的關閉條件就不一樣；那麼基於此種業務場景，首先我們需要將主流程抽象出標準服務能力；例如，商機建立流程，我們將其定義為許可權校驗、引數校驗、額外特殊校驗、補充資訊、模型轉換、儲存資料、跨區校驗、後續額外處理等標準模板服務；每一個步驟方法都是抽象的，後續每個條線都將繼承它，可以重寫自己的邏輯；這樣一個建立商機流程就標準化了。

上述我們是根據業務特性進行的模板抽象固化，但是如何將整個架構按照條線來走呢，這就需要我們將每個條線的流程進行抽象，例如，幾乎每個條線都有建立商機、關閉商機、啟用商機、修改商機等相同的動作，我們需要將這些抽象成固定的介面；然後各自條線都實現該介面並宣告成策略，根據入參的識別自動分流至不同條線策略處理；也就形成了按條線為策略錨點的模式。

所以總體上是利用策略模式 + 模板模式支援各條線快速複用和靈活擴充套件，整體服務抽象複用及擴充套件思路形成大致的核心類圖如下圖：

整個商機的後端架構經過單條線多套介面處理的方式調整為適配所有條線統一介面接入；後端整體架構大致分5層，在核心層其實還會細分邏輯層，代理層以及Mapper 層。

首先我們在這次改造過程中統一了介面層，不在區分PC端介面，JME 端介面，統一以JSF介面形式提供出去；然後藉助物流閘道器設定PC認證以及JME認證並一致以Http協定對接出去，保證了介面層面的統一。在適配層我們是定義了一個策略介面卡，它會掃描所有宣告了註解@LineType的策略處理器並快取，然後根據解析入參中的條線進行自動匹配處理器進行分配處理，從而達到請求的自動分配處理。在核心層中其實更多的是模板方法的抽象與封裝，將商機的基本查詢、基礎CMD操作、以及商機相關聯資訊操作進行分類抽象。將商機的推進機制建立在規則引擎中，將每個條線的推進規則提前設定在規則引擎的規則表中，並在後端服務中統一提供一個推進入口，所有條線都將基於該入口進行推進，達到推進規則明確，入口統一，階段可設定等可靈活擴充套件的方式。

通過整體架構的優化和調整後，目前已經可以適配所有條統一接入、商機階段可設定，推進規則可定義、介面統一等優點，大大節省了研發的接入成本。

4.2.4 商機階段設定化

1.場景現狀

每個銷售條線的商機流程階段及相應規則都存在差異，甚至同一個銷售條線也存在多種業務，對應的商機流程階段也不同，為支援多銷售條線的差異化商機業務；要求必須實現每個條線的商機階段個數是可設定的，並且每個階段的規則也是可設定。

2.方案選型

如下圖中所示，列舉了幾個條線的商機階段生命週期，幾乎每個條線的商機生命週期都不一樣，這裡需要說明一下階段與階段之間的推進條件是允許不一樣的，所以會存在不同條線存在相同的階段，但其實到達該階段的前置條件是有可能不一樣的，這就要求階段的規則是可設定的，這也會造成可複用的可能性小。如果通過編碼方式去實現每個條線的階段生命週期會是一個非常複雜的過程，並且也難以維護。

經過調研發現，我們的這種場景模型就是通過多個入參條件決定流程走向（通過、不通過）的一種簡單形式，相對於多入多出的模式還簡單一些，而這種模式正好現在已經有比較好的解決方案（規則引擎），在現有的流程引擎（Flowable、Activity）都有對規則引擎的實現，包括強大的Drools 規則引擎。對比幾款規則引擎幾乎都可以很好的滿足我們的需求，那就要考慮成本問題，畢竟引入一款中介軟體對系統的維護成本也是比較大的。經過了解部門內部已經對Flowable 已經進行二次封裝對外賦能了，所以在這邊我們採用了基於Flowable 流程引擎中的DMN來實現，從模型上來說就是輸入多個入參，然後根據規則設定進行判斷走向，沒有多分支相關聯，所以選擇Flowable 的規則引擎也比較合適。

解決方案：通過規則引擎，設定商機階段和階段推進規則，解決各條線商機階段差異化問題，將變化流程用設定化方式融入到整體流程中。

3.實現效果

在規則引擎中，提供決策表的表示式，決策表分為輸入表示式與輸出表示式兩個主要區域。在輸入表示式中，可以定義變數，用於規則輸入項(input entries)的表示式。可以通過選擇Add Input(新增輸入)，定義多個輸入表示式。在輸出表示式中，可以定義選擇表執行結果要建立的變數（變數的值將用於輸出項表示式，在下面解釋）。可以通過選擇Add Output(新增輸出)，定義多個輸出表示式。

規則設定如下圖：（以服務+條線舉例）

服務+ 權授權業務商機推進規則:jd-rule-crm_fwj_chance_authorized_business

服務+ B線上業務商機推進規則:jd-rule-crm_fwj_chance_b_online_business

優勢：

規則統一收口，每個條線商機階段推進規則可以直觀呈現，規則演化軌跡可以追蹤，避免問題排查時，通過程式碼排查方式核對規則，提升運維效率。
規則調整可以實時生效，避免程式碼維護和系統上線，提升研發效率。
一套程式碼實現所有條線階段推進，只需要根據條線新增不同的輸入即可。

5 效果

5.1 提升效率

消滅煙囪系統，一套系統完成所有條線支撐，實現各條線、各端介面統一。

開發成本低，易擴充套件，提升研發效率，降低運維成本；

按照領域對商機進行拆分解耦，實現商機領域獨立部署，在商機領域內，通過前端元件化、後端服務標準化、商機階段設定化技術手段，支援各條線快速複用和靈活擴充套件。接入對比結果來看，研發效率提升顯著，同時也降低運維成本。隨著標準流程不斷抽象，底層基礎服務不斷完善，後續條線接入的效率在進一步提升，從後續接入的雲倉生態、物流科技、價值供應鏈，供應鏈金融，新業務-新業務、金融、供應商7個條線來看，平均接入工時維持在30人日左右。

條線接入工時如下：

標準流程和通用基礎服務，提升研測過程效率，其中：服務+條線接入測試工時從最初評估的30人日到實際的23人日，測試階段效率提升23.3%:

大宗條線接入測試評估工時及實際工時，基於服務+接入商機專案的測試經驗，大宗商機接入專案測試階段從原計劃30人日降低到10人日，效率提升66.7%：

5.2 提升質量

服務+較原計劃提前4工作日交付，大宗較原計劃提前11工作日交付，交付演示過程中均未出現任何問題，驗收全程未出現影響整體進度的阻塞性問題。

大宗UAT過程中共提出6個問題，其中5個為頁面調優等優化項，1個為環境引起的無法勾選問題，未出現任何bug類問題，整體驗收過程順暢無阻。

作者：京東物流姚再毅孔祥東樊平安楊攀田雷雷

來源：京東雲開發者社群自猿其說Tech