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