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? 總結一下

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

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

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