01
什么是業(yè)務(wù)中間件
在說“業(yè)務(wù)中間件”之前先解釋下什么是“中間件”，通常來說中間件是特指計算機系統(tǒng)中將底層邏輯屏蔽，并收斂某些通用功能構(gòu)建出來的軟件服務(wù)。目的是用來解耦底層實現(xiàn)
細節(jié)，更簡單的進行上層業(yè)務(wù)功能開發(fā)，比如常用的redis、levelDB、kafka、rpc 本質(zhì)上都屬于技術(shù)中間件的范疇。
而業(yè)務(wù)中間件理我們也并不遠，也是類似的思想，抽離相對通用的業(yè)務(wù)功能部分并集成特定技術(shù)，解決業(yè)務(wù)開發(fā)的復(fù)雜性等痛點問題。
舉個例子來說：
我們要實現(xiàn)集中的對象存儲，每次去顯示的感知磁盤操作、內(nèi)存操作、網(wǎng)絡(luò)通信、數(shù)據(jù)結(jié)構(gòu)的處理細節(jié)，一個簡單的write就相當(dāng)費勁了，這種時候把上述公用的操作邏輯進行收斂，然后作為一個標(biāo)準(zhǔn)的產(chǎn)品形態(tài)對外開放就是我們常用的“對象存儲中間件”。
如果我們的業(yè)務(wù)場景是活動，每次都需要在存儲之上進行一些比如“庫存管理”、“分片處理”、“計數(shù)統(tǒng)計”等等操作，如果每次都去重復(fù)開發(fā)，成本是很高的，所以就抽象一些公共函數(shù)集中管理對于存儲的處理，然后增加一些易用性及通用性的處理，再進一步抽象在特定活動領(lǐng)域下，標(biāo)準(zhǔn)化成產(chǎn)品能力，就是所謂的業(yè)務(wù)中間件，比如庫存管理工具、高可用賬務(wù)工具、規(guī)則決策引擎等等。
02
痛點的發(fā)現(xiàn)及分析
業(yè)務(wù)中間件的設(shè)計是用來解決問題的，尤其是痛點問題的，比如說：維護成本、開發(fā)成本、性能風(fēng)險、數(shù)據(jù)一致性保障風(fēng)險。
所以，第一步是分析我們當(dāng)前的業(yè)務(wù)系統(tǒng)，面對當(dāng)前的業(yè)務(wù)現(xiàn)狀存在什么樣的痛點，預(yù)判未來業(yè)務(wù)的發(fā)展會出現(xiàn)什么樣的痛點，當(dāng)前的系統(tǒng)架構(gòu)是否是合適的，如果存在問題，那就需要進行重構(gòu)了，而業(yè)務(wù)中間件的設(shè)計，就是重構(gòu)過程中很重要的一步。
下面來說一下系統(tǒng)分析的套路:
2.1
系統(tǒng)評價指標(biāo)的建立
要做一件事兒，我們首先要知道什么是好，什么是不好，所以第一步要建立對于我們系統(tǒng)的評價體系。
技術(shù)方面：吞吐、日?？捎眯允亲畛Ｓ玫膬蓚€指標(biāo)，單位資源下能處理多少業(yè)務(wù)請求、處理過程中多少是有效處理。
業(yè)務(wù)方面：開發(fā)一個新功能的成本是多少、維護一個老功能的成本是多少，這里可以擺脫當(dāng)前的系統(tǒng)現(xiàn)狀，完美狀態(tài)下 分別應(yīng)該需要多少人力，內(nèi)心建立一個預(yù)期。
風(fēng)險方面：面對極端情況時系統(tǒng)是否可用、部分不可用時是否會造成全局影響、是否存在應(yīng)對方案.
2.2
梳理業(yè)務(wù)流程-整理穩(wěn)定邏輯、易變邏輯
我們需要熟知面臨的業(yè)務(wù)邏輯，首先把一團業(yè)務(wù)梳理出具體的大能力，然后梳理出能力中的具體流程，然后拆出流程中的所需的剛性功能點。然后對于我們功能點和具體流程進行分析，看哪些業(yè)務(wù)邏輯是易變的，哪些業(yè)務(wù)是穩(wěn)定的。
拿重業(yè)務(wù)的CRM系統(tǒng)舉例，一個大的CRM范疇內(nèi)按能力類型大致可以拆分成銷售管理、運營管理、營銷管理，在此之上具備整體效果、效率分析的能力。
其中銷售管理又可以細拆成“任務(wù)下發(fā)”、“客戶保護”、“合同管理”、“業(yè)績管理”等能n多能力，然后合同管理具有自己的大流程，模版管理、合同申請、簽章、審批、履約等等，申請過程具備自己的流程：選擇類型、填寫內(nèi)容、簽署、郵寄等等，然后每個功能點又具備自身的細分功能點。
其中模版管理是穩(wěn)定流程，合同審批是易變流程、清分規(guī)則是易變邏輯、財務(wù)流程是穩(wěn)定邏輯。
拿營銷活動距離也是一樣的，要做什么樣的活動，活動具體玩法是什么樣子、玩法之間的關(guān)系是什么樣子，玩法內(nèi)部具備什么樣的功能點。
2.3
由業(yè)務(wù)流程反觀功能實現(xiàn)
進行系統(tǒng)架構(gòu)的分析，對于當(dāng)前系統(tǒng)進行新增功能開發(fā)、老功能變更時的方案進行預(yù)演，看功能變更過程中是否存在困難，然后用上面的系統(tǒng)評價指標(biāo)進行評價。處理之外也需要對系統(tǒng)的功能進行技術(shù)方面的指標(biāo)分析，看一下整體的吞吐、可用性。
還是上面的例子，比如更改客戶合同部分功能，有沒有收到其他功能的阻礙，新增一種清分規(guī)則是否要編寫代碼，新增一個簽署方式簽署管理是大規(guī)模變更還是插拔式開發(fā)，履約流程新增一個節(jié)點是不是整個流程都要變動，系統(tǒng)增加了客戶保護功能對其他大功能影響是否巨大。
2.4
尋找原因
看到問題之后需要反觀下我們的系統(tǒng)到底因為什么變成了這樣：
無腦copy導(dǎo)致的重復(fù)代碼太多？
為了省事兒的不合理復(fù)用？
大量臨時代碼的技術(shù)債？
case by case的功能設(shè)計？
模型定義不合理？
功能邊界不清晰？
功能間的交互關(guān)系設(shè)計混亂？
找到具體原因之后，我們可以選擇對于模型進行重新的定義、架構(gòu)的重構(gòu)、垃圾的代碼的重構(gòu)等等操作。
在設(shè)計的過程中，就可以對于業(yè)務(wù)下的通用功能進行抽象來構(gòu)建業(yè)務(wù)中間件，結(jié)合現(xiàn)有技術(shù)或思想解決一類痛點問題來構(gòu)建業(yè)務(wù)中間件，再或者包裝一下現(xiàn)成的一些技術(shù)中間件使其具備業(yè)務(wù)屬性從而更加高效 來構(gòu)建業(yè)務(wù)中間件。通過構(gòu)建這些業(yè)務(wù)領(lǐng)域下的中間件使我們的架構(gòu)更加清晰、痛點問題得到集中解決，從而使業(yè)務(wù)功能開發(fā)和維護更加簡單。
03
避免大而全等誤區(qū)
業(yè)務(wù)中間的設(shè)計并不是架構(gòu)設(shè)計中的銀彈，它只是在復(fù)雜業(yè)務(wù)下的一種相對有效的解決思路，而且一個業(yè)務(wù)中間件往往只能解決一類問題或者某一個特定痛點，不要妄想寫一個非常強大的中間件能解決一切痛點問題，術(shù)業(yè)有專攻才是正道。
04
經(jīng)典思路
說幾個常用的設(shè)計思路，可以作為痛點的切入點來處理，整體來說就是關(guān)注變化、關(guān)注公共處理、關(guān)注聯(lián)系。
4.1
邊車模式 - 平面思想
邊車指的通常就是摩托車的“跨斗”，邊車模式正如名字那樣，給我們的功能或者系統(tǒng)上一個跨斗，這是一個經(jīng)典的平面思想，面向切面的思路去解決分布式應(yīng)用構(gòu)建過程中通用代碼活動通用流程的問題，跟代碼開發(fā)過程中的AOP的處理思想類似，只是處理的維度不同罷了。
最常見的邊車模式的使用是微服務(wù)中的服務(wù)網(wǎng)格，將監(jiān)控、流量調(diào)度、數(shù)據(jù)上報等一系列每個業(yè)務(wù)邏輯底層交互細節(jié)及公用agent收斂，給業(yè)務(wù)業(yè)務(wù)開發(fā)裝了一跨斗，我們只需要專注業(yè)務(wù)邏輯處理即可。
在業(yè)務(wù)中間件實踐上也是類似的，系統(tǒng)交互流量調(diào)度可以這么做、信息流調(diào)度 資金流調(diào)度這些理論上都是可行的，能把監(jiān)控拉出來在切面里處理，那觸達等附加邏輯也是可以同樣方式處理的，能抽離處理認證鑒權(quán) 節(jié)點中的流轉(zhuǎn)許可也是同樣的道理。
我們只開發(fā)業(yè)務(wù)處理的單元能力，將單元能力之間的串聯(lián)邏輯釋放出來，每個單元能力掛一個邊車，由邊車統(tǒng)一處理串聯(lián)邏輯、由邊車統(tǒng)一處理單元的公共觸達等等，并且邊車很大一個優(yōu)勢在于我們可以有選擇性的給我們想要的服務(wù)裝邊車。
4.2
is-a思想的放大
is-a的思想并不只是我們面向?qū)ο缶幊痰目梢杂?，在做中間件設(shè)計的時候也是一個經(jīng)典的思路，適當(dāng)?shù)膹木唧w應(yīng)用向上泛化拿到本質(zhì)。
比如我們需要多種對象存儲但是顯示的感知各類存儲引擎的操作細節(jié)太過麻煩，就可以抽象一個對象存儲的中間件，只需要操作這個中間件就可以了，具體的訪問細節(jié)、引擎的操作細節(jié)交給中間件去處理就好啦，阿里tair（集成redis、levelDB等）就是這種實現(xiàn)思路。
在業(yè)務(wù)上的抽象設(shè)計也是相似的，push、消息、私信、彈窗、toast 本質(zhì)上都屬于對于用戶的觸達或反饋，所以我們業(yè)務(wù)系統(tǒng)中只需要感知觸達就好了，具體操作細節(jié)和路由處理等等交給中間件去解決。
一些代理模式本質(zhì)上也是這種思想的放大，正向代理、反向代理不同的角度出發(fā)去隱藏實現(xiàn)細節(jié)，然后在代理中做適配工作。
4.3
穩(wěn)定層與變化層分離
穩(wěn)定層與變化層分離 有兩個維度一個是易變的業(yè)務(wù)邏輯同穩(wěn)定的業(yè)務(wù)邏輯相互分離、另一個是將代碼功能維度和具體業(yè)務(wù)處理相分離。
第一個維度相對簡單，我們可以利用策略模式等將易變邏輯變得可插拔即可，但本質(zhì)上我們存在邏輯新增或者變更時依舊是需要寫代碼（但是這種方式依舊是隔離易變邏輯的常用思路），所以這里推薦的是代碼功能維度和具體業(yè)務(wù)處理相分離。有幾種處理思路大家可以根據(jù)當(dāng)前的業(yè)務(wù)現(xiàn)狀做判斷，選擇的時候一定要注意投入產(chǎn)出比。
首先第一階段是純粹的寫代碼，新增和變更時都需要改代碼，DB + 業(yè)務(wù)代碼就是這種模式。
第二階段是固定流程 + 業(yè)務(wù)配置 + 基礎(chǔ)能力，新增處理邏輯時需要新增基礎(chǔ)能力的開發(fā)和調(diào)度配置，我們的常見業(yè)務(wù)系統(tǒng)就是這樣的事項模式。
第三階段是固定流程 + 動態(tài)規(guī)則 + 基礎(chǔ)能力，新增處理邏輯時只需要增加決策規(guī)則就可以了 無需代碼開發(fā)，但是處理流程發(fā)生變化依舊需要寫代碼，風(fēng)控決策、推薦、資金流調(diào)撥、廣告這類系統(tǒng)通常是這種處理模式，經(jīng)典的柔性控制的思路。
第四階段低碼規(guī)則 + 基礎(chǔ)能力，低碼方案生成代碼、Faas提供原子基礎(chǔ)能力，當(dāng)前低碼建站等平臺就是這種模式。
第五階段 純粹代碼生成的方案，這塊還屬于行業(yè)探索的階段，到底是AI寫碼還是如何大家可以暢想一下。
上面這么說有點抽象，舉幾個例子：
整個發(fā)展過程中善用的工具比如決策引擎、規(guī)則引擎、流程引擎 就是將業(yè)務(wù)規(guī)則同代碼處理邏輯剝離最好用的工具。
比如說：
1、營銷活動中給用戶的激勵，可以使用規(guī)則引擎來動態(tài)定價。
2、任務(wù)下發(fā)中給用戶下發(fā)任務(wù)的決策可以使用決策引擎來決定是否下發(fā)，或者直接人群的圈定。
3、B端各類處理流程，可以使用流程引擎進行進行動態(tài)流程的編排。
4、風(fēng)控系統(tǒng)中的攔截規(guī)則、推薦系統(tǒng)中match 規(guī)則、廣告系統(tǒng)中的出價規(guī)則和match規(guī)則
5、資金賬務(wù)系統(tǒng)中的資金流流轉(zhuǎn)規(guī)則
6、游戲引擎中的腳本規(guī)則插入、地圖引擎中的規(guī)則嵌入等等，都是類似的實現(xiàn)思路。
我們再利用這些能力構(gòu)建公用工具的過程本質(zhì)就是業(yè)務(wù)中間件實現(xiàn)的過程。
4.4
領(lǐng)域內(nèi)設(shè)計 - 更多的業(yè)務(wù)屬性
再就是解決一類特定的痛點問題的方案，使我們的技術(shù)中間件具備業(yè)務(wù)屬性，然后專注于某一業(yè)務(wù)領(lǐng)域的特定問題解決。
比如說：
1、我們的存儲，mysql直接支持各類賬務(wù)可以做，但是每次共同的邏輯都比較多，賬務(wù)的邏輯都是相對統(tǒng)一的，可以直接開發(fā)一個高可用的通用賬務(wù)存儲。
2、依舊是存儲，要用于支持各類營銷活動，中間涉及大量的庫存控制等邏輯，要用于應(yīng)對秒殺等場景，就直接開發(fā)一個庫存存儲即可。
3、還有事務(wù)型mq 都是結(jié)合具體的業(yè)務(wù)特點進行具像化后的設(shè)計思路。
4、對于上下文來說，就可以結(jié)合各類存儲做一個具有業(yè)務(wù)意義的上下文存儲能力。
類似的思路還有很多結(jié)合業(yè)務(wù)特點去做就可以啦。
4.5
總線思想
總線思想想必大家是一點都不陌生，當(dāng)事件種類特別多、事件之間的交互關(guān)系非常復(fù)雜的時候，總線思想是最常用的解決思路之一。
如果不清楚總線思想中的落地，可以看下操作系統(tǒng)中的三大總線：控制總線、地址總線、數(shù)據(jù)總線，也可以看下SOA中的事件總線的設(shè)計實現(xiàn)。
需要注意就是我們設(shè)計的具備業(yè)務(wù)屬性的總線，并不是常用基礎(chǔ)包中解決消息的事件總線。主要提供的事件的動態(tài)關(guān)聯(lián)分發(fā)的能力，提供了標(biāo)準(zhǔn)的協(xié)議定義，用于解決特定業(yè)務(wù)場景下的復(fù)雜事件交互關(guān)系。
這里就不再舉具體例子了，前面提到的活動事件總線就是具體的實踐落地。
4.6
總結(jié)一下
善用設(shè)計理論，比如常見的架構(gòu)設(shè)計思想、面向?qū)ο笏枷?，熟知業(yè)務(wù)及業(yè)務(wù)對應(yīng)的未來發(fā)展。
很多時候一個業(yè)務(wù)中間件的設(shè)計和落地的過程往往是多種設(shè)計思想結(jié)合的產(chǎn)物，比如之前提到的事件總線、消息總線、決策引擎、規(guī)則引擎等等，無招勝有招，只要知識儲備足夠多、對業(yè)務(wù)和系統(tǒng)足夠了解 就一定能發(fā)現(xiàn)其中的問題并能夠完成重構(gòu)優(yōu)化，以此構(gòu)成提效。
拿上述的事件總線來看：建立總線之后就可以動態(tài)的處理訂閱或者觸發(fā)關(guān)系，關(guān)系之間又可以利用決策引擎進行動態(tài)決策，流轉(zhuǎn)關(guān)系就構(gòu)成了業(yè)務(wù)流程引擎，然后利用邊車模式掛到需要的服務(wù)上去即可。
好了，這篇文章的內(nèi)容發(fā)貨聯(lián)盟就和大家分享到這里，如果大家網(wǎng)絡(luò)推廣引流創(chuàng)業(yè)感興趣，可以添加微信：80709525 備注：發(fā)貨聯(lián)盟引流學(xué)習(xí)； 我拉你進直播課程學(xué)習(xí)群，每周135晚上都是有實戰(zhàn)干貨的推廣引流技術(shù)課程免費分享！
