1 什么是業(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ī)則決策引擎等等。
2 痛點的發(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ā)和維護更加簡單呢铆。
3 避免大而全等誤區(qū)
業(yè)務(wù)中間的設(shè)計并不是架構(gòu)設(shè)計中的銀彈,它只是在復(fù)雜業(yè)務(wù)下的一種相對有效的解決思路蹲缠,而且一個業(yè)務(wù)中間件往往只能解決一類問題或者某一個特定痛點棺克,不要妄想寫一個非常強大的中間件能解決一切痛點問題,術(shù)業(yè)有專攻才是正道线定。
4 經(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)控拉出來在切面里處理蛆橡,那觸達等附加邏輯也是可以同樣方式處理的舌界,能抽離處理認(rè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ū)ο缶幊痰目梢杂美埃谧鲋虚g件設(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ū)ο笏枷耄熘獦I(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ù)上去即可断傲。
5.舉幾個例子
前面提到了n多例子,下面再重復(fù)的看下:
1智政、規(guī)則決策引擎該怎么設(shè)計认罩?
2、業(yè)務(wù)事件總線該怎么設(shè)計续捂?
3垦垂、高可用賬務(wù)中間件該怎么設(shè)計宦搬?
4、動態(tài)激勵定價中間件該怎么設(shè)計乔外?
5床三、效果數(shù)據(jù)反哺該怎么設(shè)計?