業務中介軟體設計方法論經驗總結

01、什麼是業務中介軟體

在說“業務中介軟體”之前先解釋下什麼是“中介軟體”，通常來說中介軟體是特指計算機系統中將底層邏輯遮蔽，並收斂某些通用功能構建出來的軟體服務。目的是用來解耦底層實現

細節，更簡單的進行上層業務功能開發，比如常用的redis、levelDB、kafka、rpc 本質上都屬於技術中介軟體的範疇。

而業務中介軟體理我們也並不遠，也是類似的思想，抽離相對通用的業務功能部分並整合特定技術，解決業務開發的複雜性等痛點問題。

舉個例子來說：

我們要實現集中的物件儲存，每次去顯示的感知磁碟操作、記憶體操作、網路通訊、資料結構的處理細節，一個簡單的write就相當費勁了，這種時候把上述公用的操作邏輯進行收斂，然後作為一個標準的產品形態對外開放就是我們常用的“物件儲存中介軟體”。

如果我們的業務場景是活動，每次都需要在儲存之上進行一些比如“庫存管理”、“分片處理”、“計數統計”等等操作，如果每次都去重複開發，成本是很高的，所以就抽象一些公共函式集中管理對於儲存的處理，然後增加一些易用性及通用性的處理，再進一步抽象在特定活動領域下，標準化成產品能力，就是所謂的業務中介軟體，比如庫存管理工具、高可用賬務工具、規則決策引擎等等。

02、痛點的發現及分析

業務中介軟體的設計是用來解決問題的，尤其是痛點問題的，比如說：維護成本、開發成本、效能風險、資料一致性保障風險。

所以，第一步是分析我們當前的業務系統，面對當前的業務現狀存在什麼樣的痛點，預判未來業務的發展會出現什麼樣的痛點，當前的系統架構是否是合適的，如果存在問題，那就需要進行重構了，而業務中介軟體的設計，就是重構過程中很重要的一步。

下面來說一下系統分析的套路:

2.1 系統評價指標的建立

要做一件事兒，我們首先要知道什麼是好，什麼是不好，所以第一步要建立對於我們系統的評價體系。

技術方面：吞吐、日常可用性是最常用的兩個指標，單位資源下能處理多少業務請求、處理過程中多少是有效處理。

業務方面：開發一個新功能的成本是多少、維護一個老功能的成本是多少，這裡可以擺脫當前的系統現狀，完美狀態下 分別應該需要多少人力，內心建立一個預期。

風險方面：面對極端情況時系統是否可用、部分不可用時是否會造成全域性影響、是否存在應對方案.

2.2 梳理業務流程-整理穩定邏輯、易變邏輯

我們需要熟知面臨的業務邏輯，首先把一團業務梳理出具體的大能力，然後梳理出能力中的具體流程，然後拆出流程中的所需的剛性功能點。然後對於我們功能點和具體流程進行分析，看哪些業務邏輯是易變的，哪些業務是穩定的。

拿重業務的CRM系統舉例，一個大的CRM範疇內按能力型別大致可以拆分成銷售管理、運營管理、營銷管理，在此之上具備整體效果、效率分析的能力。

其中銷售管理又可以細拆成“任務下發”、“客戶保護”、“合同管理”、“業績管理”等能n多能力，然後合同管理具有自己的大流程，模版管理、合同申請、簽章、審批、履約等等，申請過程具備自己的流程：選擇型別、填寫內容、簽署、郵寄等等，然後每個功能點又具備自身的細分功能點。

其中模版管理是穩定流程，合同審批是易變流程、清分規則是易變邏輯、財務流程是穩定邏輯。

拿營銷活動距離也是一樣的，要做什麼樣的活動，活動具體玩法是什麼樣子、玩法之間的關係是什麼樣子，玩法內部具備什麼樣的功能點。

2.3 由業務流程反觀功能實現

進行系統架構的分析，對於當前系統進行新增功能開發、老功能變更時的方案進行預演，看功能變更過程中是否存在困難，然後用上面的系統評價指標進行評價。處理之外也需要對系統的功能進行技術方面的指標分析，看一下整體的吞吐、可用性。

還是上面的例子，比如更改客戶合同部分功能，有沒有收到其他功能的阻礙，新增一種清分規則是否要編寫程式碼，新增一個簽署方式簽署管理是大規模變更還是插拔式開發，履約流程新增一個節點是不是整個流程都要變動，系統增加了客戶保護功能對其他大功能影響是否巨大。

2.4 尋找原因

看到問題之後需要反觀下我們的系統到底因為什麼變成了這樣：

無腦copy導致的重複程式碼太多?

為了省事兒的不合理複用?

大量臨時程式碼的技術債?

case by case的功能設計?

模型定義不合理?

功能邊界不清晰?

功能間的互動關係設計混亂?

找到具體原因之後，我們可以選擇對於模型進行重新的定義、架構的重構、垃圾的程式碼的重構等等操作。

在設計的過程中，就可以對於業務下的通用功能進行抽象來構建業務中介軟體，結合現有技術或思想解決一類痛點問題來構建業務中介軟體，再或者包裝一下現成的一些技術中介軟體使其具備業務屬性從而更加高效 來構建業務中介軟體。透過構建這些業務領域下的中介軟體使我們的架構更加清晰、痛點問題得到集中解決，從而使業務功能開發和維護更加簡單。

03、避免大而全等誤區

業務中間的設計並不是架構設計中的銀彈，它只是在複雜業務下的一種相對有效的解決思路，而且一個業務中介軟體往往只能解決一類問題或者某一個特定痛點，不要妄想寫一個非常強大的中介軟體能解決一切痛點問題，術業有專攻才是正道。

04、經典思路

說幾個常用的設計思路，可以作為痛點的切入點來處理，整體來說就是關注變化、關注公共處理、關注聯絡。

4.1 邊車模式 - 平面思想

邊車指的通常就是摩托車的“跨鬥”，邊車模式正如名字那樣，給我們的功能或者系統上一個跨鬥，這是一個經典的平面思想，面向切面的思路去解決分散式應用構建過程中通用程式碼活動通用流程的問題，跟程式碼開發過程中的AOP的處理思想類似，只是處理的維度不同罷了。

最常見的邊車模式的使用是微服務中的服務網格，將監控、流量排程、資料上報等一系列每個業務邏輯底層互動細節及公用agent收斂，給業務業務開發裝了一跨鬥，我們只需要專注業務邏輯處理即可。

在業務中介軟體實踐上也是類似的，系統互動流量排程可以這麼做、資訊流排程 資金流排程這些理論上都是可行的，能把監控拉出來在切面裡處理，那觸達等附加邏輯也是可以同樣方式處理的，能抽離處理認證鑑權 節點中的流轉許可也是同樣的道理。

我們只開發業務處理的單元能力，將單元能力之間的串聯邏輯釋放出來，每個單元能力掛一個邊車，由邊車統一處理串聯邏輯、由邊車統一處理單元的公共觸達等等，並且邊車很大一個優勢在於我們可以有選擇性的給我們想要的服務裝邊車。

4.2 is-a思想的放大

is-a的思想並不只是我們物件導向程式設計的可以用，在做中介軟體設計的時候也是一個經典的思路，適當的從具體應用向上泛化拿到本質。

比如我們需要多種物件儲存但是顯示的感知各類儲存引擎的操作細節太過麻煩，就可以抽象一個物件儲存的中介軟體，只需要操作這個中介軟體就可以了，具體的訪問細節、引擎的操作細節交給中介軟體去處理就好啦，阿里tair(整合redis、levelDB等)就是這種實現思路。

在業務上的抽象設計也是相似的，push、訊息、私信、彈窗、toast 本質上都屬於對於使用者的觸達或反饋，所以我們業務系統中只需要感知觸達就好了，具體操作細節和路由處理等等交給中介軟體去解決。

一些代理模式本質上也是這種思想的放大，正向代理、反向代理不同的角度出發去隱藏實現細節，然後在代理中做適配工作。

4.3 穩定層與變化層分離

穩定層與變化層分離 有兩個維度一個是易變的業務邏輯同穩定的業務邏輯相互分離、另一個是將程式碼功能維度和具體業務處理相分離。

第一個維度相對簡單，我們可以利用策略模式等將易變邏輯變得可插拔即可，但本質上我們存在邏輯新增或者變更時依舊是需要寫程式碼(但是這種方式依舊是隔離易變邏輯的常用思路)，所以這裡推薦的是程式碼功能維度和具體業務處理相分離。有幾種處理思路大家可以根據當前的業務現狀做判斷，選擇的時候一定要注意投入產出比。

首先第一階段是純粹的寫程式碼，新增和變更時都需要改程式碼，DB + 業務程式碼就是這種模式。

第二階段是固定流程 + 業務配置 + 基礎能力，新增處理邏輯時需要新增基礎能力的開發和排程配置，我們的常見業務系統就是這樣的事項模式。

第三階段是固定流程 + 動態規則 + 基礎能力，新增處理邏輯時只需要增加決策規則就可以了 無需程式碼開發，但是處理流程發生變化依舊需要寫程式碼，風控決策、推薦、資金流調撥、廣告這類系統通常是這種處理模式，經典的柔性控制的思路。

第四階段低碼規則 + 基礎能力，低碼方案生成程式碼、Faas提供原子基礎能力，當前低碼建站等平臺就是這種模式。

第五階段 純粹程式碼生成的方案，這塊還屬於行業探索的階段，到底是AI寫碼還是如何大家可以暢想一下。

上面這麼說有點抽象，舉幾個例子：

整個發展過程中善用的工具比如決策引擎、規則引擎、流程引擎 就是將業務規則同程式碼處理邏輯剝離最好用的工具。

比如說：

1、營銷活動中給使用者的激勵，可以使用規則引擎來動態定價。

2、任務下發中給使用者下發任務的決策可以使用決策引擎來決定是否下發，或者直接人群的圈定。

3、B端各類處理流程，可以使用流程引擎進行進行動態流程的編排。

4、風控系統中的攔截規則、推薦系統中match 規則、廣告系統中的出價規則和match規則

5、資金賬務系統中的資金流流轉規則

6、遊戲引擎中的指令碼規則插入、地圖引擎中的規則嵌入等等，都是類似的實現思路。

我們再利用這些能力構建公用工具的過程本質就是業務中介軟體實現的過程。

4.4 領域內設計 - 更多的業務屬性

再就是解決一類特定的痛點問題的方案，使我們的技術中介軟體具備業務屬性，然後專注於某一業務領域的特定問題解決。

比如說：

1、我們的儲存，mysql直接支援各類賬務可以做，但是每次共同的邏輯都比較多，賬務的邏輯都是相對統一的，可以直接開發一個高可用的通用賬務儲存。

2、依舊是儲存，要用於支援各類營銷活動，中間涉及大量的庫存控制等邏輯，要用於應對秒殺等場景，就直接開發一個庫存儲存即可。

3、還有事務型mq 都是結合具體的業務特點進行具像化後的設計思路。

4、對於上下文來說，就可以結合各類儲存做一個具有業務意義的上下文儲存能力。

類似的思路還有很多結合業務特點去做就可以啦。

4.5 匯流排思想

匯流排思想想必大家是一點都不陌生，當事件種類特別多、事件之間的互動關係非常複雜的時候，匯流排思想是最常用的解決思路之一。

如果不清楚匯流排思想中的落地，可以看下作業系統中的三大匯流排：控制匯流排、地址匯流排、資料匯流排，也可以看下SOA中的事件匯流排的設計實現。

需要注意就是我們設計的具備業務屬性的匯流排，並不是常用基礎包中解決訊息的事件匯流排。主要提供的事件的動態關聯分發的能力，提供了標準的協議定義，用於解決特定業務場景下的複雜事件互動關係。

這裡就不再舉具體例子了，前面提到的活動事件匯流排就是具體的實踐落地。

4.6 總結一下

善用設計理論，比如常見的架構設計思想、物件導向思想，熟知業務及業務對應的未來發展。

很多時候一個業務中介軟體的設計和落地的過程往往是多種設計思想結合的產物，比如之前提到的事件匯流排、訊息匯流排、決策引擎、規則引擎等等，無招勝有招，只要知識儲備足夠多、對業務和系統足夠了解 就一定能發現其中的問題並能夠完成重構最佳化，以此構成提效。

拿上述的事件匯流排來看：建立匯流排之後就可以動態的處理訂閱或者觸發關係，關係之間又可以利用決策引擎進行動態決策，流轉關係就構成了業務流程引擎，然後利用邊車模式掛到需要的服務上去即可。

05、舉幾個例子

前面提到了n多例子，下面再重複的看下：

1、規則決策引擎該怎麼設計?

2、業務事件匯流排該怎麼設計?

3、高可用賬務中介軟體該怎麼設計?

4、動態激勵定價中介軟體該怎麼設計?

5、效果資料反哺該怎麼設計?

作者介紹：@知乎 鄒志全；專注營銷系統提效;自動化營銷精細運營的長期實踐者;做有效編碼;“資料人創作者聯盟”成員。