本文首先介紹了規(guī)則引擎的使用場(chǎng)景，引出貼吧規(guī)則引擎。從組件、變量、規(guī)則、處置四個(gè)模塊介紹了規(guī)則引擎的組成部分，同時(shí)對(duì)最終規(guī)則文件的編譯過(guò)程做了詳細(xì)介紹。為了做到低代碼，在規(guī)則配置上做到平臺(tái)化，非研發(fā)同學(xué)即可完成。增加新的變量也只需要在變量平臺(tái)進(jìn)行簡(jiǎn)單操作，無(wú)需額外的代碼提交。另外框架層面支持并行和異步的封裝，在服務(wù)調(diào)用上也盡量做到減少代碼，提高研發(fā)同學(xué)的效率。最后文章對(duì)貼吧規(guī)則引擎做了總結(jié)，也提供了一些常見(jiàn)的使用場(chǎng)景和思路。

01

背景

百度貼吧是一個(gè)擁有10多年歷史的UGC產(chǎn)品，在業(yè)務(wù)迭代中難免會(huì)有很多業(yè)務(wù)邏輯的代碼，其中一部分業(yè)務(wù)邏輯用if-else等硬編碼的形式開(kāi)發(fā)，一部分引入了配置文件，通過(guò)配置文件的規(guī)則去執(zhí)行不同的業(yè)務(wù)邏輯。在某些運(yùn)營(yíng)活動(dòng)或權(quán)益規(guī)則中，需要頻繁增加或者更改一些規(guī)則，這部分規(guī)則經(jīng)常變動(dòng)的部分就需要規(guī)則引擎來(lái)統(tǒng)一管理。

規(guī)則引擎是一種專注于業(yè)務(wù)規(guī)則的服務(wù)，它可以將業(yè)務(wù)規(guī)則從代碼中剝離出來(lái)，使用預(yù)先定義好的語(yǔ)義規(guī)范來(lái)實(shí)現(xiàn)這些剝離出來(lái)的業(yè)務(wù)規(guī)則。規(guī)則引擎通過(guò)接受輸入的數(shù)據(jù)，進(jìn)行業(yè)務(wù)規(guī)則的評(píng)估，并做出業(yè)務(wù)決策。

因?yàn)橐?guī)則引擎將復(fù)雜的業(yè)務(wù)邏輯從業(yè)務(wù)代碼中剝離出來(lái)，所以可以顯著降低業(yè)務(wù)邏輯實(shí)現(xiàn)難度；同時(shí)，剝離的業(yè)務(wù)規(guī)則使用規(guī)則引擎實(shí)現(xiàn)，這樣可以使多變的業(yè)務(wù)規(guī)則變的可維護(hù)，配合規(guī)則引擎提供的良好的業(yè)務(wù)規(guī)則設(shè)計(jì)器，不用編碼就可以快速實(shí)現(xiàn)復(fù)雜的業(yè)務(wù)規(guī)則，同樣，即使是完全不懂編程的運(yùn)營(yíng)或者產(chǎn)品人員，也可以使用圖形化的界面來(lái)自定義規(guī)則，實(shí)現(xiàn)代碼一樣的效果。

下面對(duì)一些需要使用規(guī)則引擎的場(chǎng)景進(jìn)行舉例：

1、單規(guī)則迭代

用戶標(biāo)簽->包含A關(guān)鍵詞->權(quán)益A

用戶標(biāo)簽->包含A關(guān)鍵詞->權(quán)益A

->包含B關(guān)鍵詞->權(quán)益B

用戶標(biāo)簽->身份豁免策略/機(jī)器賬號(hào)->包含A關(guān)鍵詞->權(quán)益A

->包含B關(guān)鍵詞->權(quán)益B

用戶標(biāo)簽->A模型結(jié)果大于1 ->豁C類用戶->包含A關(guān)鍵詞->權(quán)益C

可見(jiàn)隨著業(yè)務(wù)的發(fā)展，需要不斷的調(diào)整權(quán)益規(guī)則，這部分如果硬編碼寫(xiě)死在代碼中，需要頻繁上線，增加了工作量，并且隨著業(yè)務(wù)邏輯的增多，后期維護(hù)成本增高。 2、持續(xù)接入新的能力除了目前的字符串比較能力，一般的規(guī)則引擎還會(huì)接入各種各樣的模型能力，一般通過(guò)RPC的形式請(qǐng)求不同的服務(wù)，隨著接入的服務(wù)越來(lái)越多，可以組合的規(guī)則也是成倍的增長(zhǎng)；

比如新接入圖片模型識(shí)別后，所有圖片識(shí)別的結(jié)果會(huì)過(guò)其他相關(guān)的模型，相關(guān)的模型調(diào)用邏輯就增加了一倍；

又如接入了某些模型，要根據(jù)模型的分?jǐn)?shù)做相應(yīng)的處理調(diào)整，需要頻繁的改動(dòng)分值對(duì)應(yīng)的處置手段，同時(shí)為了應(yīng)對(duì)突發(fā)的場(chǎng)景，也需要頻繁的更改規(guī)則。

這些操作如果沒(méi)有一個(gè)自動(dòng)化的規(guī)則引擎，就需要把大量的規(guī)則邏輯寫(xiě)在代碼里，經(jīng)過(guò)長(zhǎng)時(shí)間的迭代，規(guī)則變得非常臃腫，無(wú)論對(duì)后續(xù)的開(kāi)發(fā)還是定位問(wèn)題的效率都會(huì)帶來(lái)問(wèn)題。

02

貼吧規(guī)則引擎組成部分

貼吧規(guī)則引擎要做到規(guī)則靈活可配，無(wú)需研發(fā)介入，就需要盡可能的把包含判斷邏輯的部分全部下放到平臺(tái)，通過(guò)平臺(tái)的勾選對(duì)規(guī)則進(jìn)行實(shí)現(xiàn)。

上圖為規(guī)則引擎整體的模塊劃分，主要分為四部分：

組件服務(wù)：組件服務(wù)是對(duì)第三方服務(wù)的封裝，比如調(diào)用圖片模型服務(wù)、調(diào)用帖子屬性等內(nèi)容服務(wù)，一般是RPC調(diào)用；組件需要RD開(kāi)發(fā)代碼，但是貼吧規(guī)則引擎的組件調(diào)用不摻雜業(yè) 務(wù)邏輯，僅僅是定義一個(gè)函數(shù)function，通過(guò)函數(shù)的入?yún)⒄{(diào)用第三方服務(wù)返回結(jié)果；

變量平臺(tái)：變量又稱算子，是配置規(guī)則的參數(shù)；變量分為業(yè)務(wù)調(diào)用時(shí)傳的入?yún)ⅰ⑹褂媒M件返回的結(jié)果等。貼吧規(guī)則引擎通過(guò)專用平臺(tái)管理變量，RD和PM均可以在平臺(tái)上配置變量；

規(guī)則引擎：規(guī)則引擎平臺(tái)涉及到了具體每一條規(guī)則，通過(guò)圖形化的界面生成規(guī)則，該平臺(tái)不需要RD介入，通過(guò)平臺(tái)化的操作生成具體的規(guī)則。

處置方法：該處置為RD定制化開(kāi)發(fā)，針對(duì)帖子、用戶或其他場(chǎng)景的召回處置處理。一般定義一個(gè)rpc請(qǐng)求回調(diào)相關(guān)業(yè)務(wù)，處置方法因?yàn)槭菆?chǎng)景定制化的，所以這部分需要研發(fā)介入開(kāi)發(fā)，但是處置方法更新的頻率非常低，一般都是復(fù)用已有的能力。

2.1組件服務(wù)

規(guī)則引擎所有配置的數(shù)據(jù)不可能都是上游參數(shù)傳遞，很多是通過(guò)調(diào)用第三方服務(wù)獲??；比如通過(guò)帖子id獲取的帖子詳情數(shù)據(jù)，通過(guò)用戶uid獲取用戶的擴(kuò)展屬性，這里都需要調(diào)用第三方服務(wù)；

組件的開(kāi)發(fā)非常簡(jiǎn)單，只需要聲明一個(gè)函數(shù)，并實(shí)現(xiàn)其靜態(tài)方法。為了后續(xù)的性能考慮，函數(shù)聲明時(shí)可以指定sync（串行）、async（異步）、parallel（并行）三種執(zhí)行方式，貼吧規(guī)則引擎會(huì)在調(diào)度的時(shí)候按照類型，使用更高效的方式執(zhí)行對(duì)應(yīng)的方法。

圖中給出了一個(gè)demo組件，可以看出組件是不關(guān)注業(yè)務(wù)的，可以自定義入?yún)⒑头祷刂?，具體調(diào)用函數(shù)的入口及參數(shù)也不需要額外關(guān)注，更符合lib庫(kù)或者util方法的實(shí)現(xiàn)方式，這種組件的好處是開(kāi)發(fā)簡(jiǎn)單，解耦業(yè)務(wù)邏輯，增加組件的復(fù)用性，同時(shí)也降低了研發(fā)同學(xué)的工作量。

另外對(duì)于mode的工作模式，分為以下三類，具體的實(shí)現(xiàn)都是框架實(shí)現(xiàn)，組件的開(kāi)發(fā)方不需要關(guān)注：

sync：同步調(diào)用，使用的時(shí)候串行執(zhí)行，函數(shù)間是阻塞的；

async：異步調(diào)用，定義function的時(shí)候分為before、after兩組方法。Before階段為發(fā)起rpc請(qǐng)求，等待第三方服務(wù)回調(diào)后執(zhí)行after方法，可以應(yīng)對(duì)好耗時(shí)的服務(wù)接入。

parallel：并行模式，屬于同一層級(jí)的parallel 函數(shù)并行執(zhí)行，類似于多線程或者golang的goroutine模式，目前貼吧的規(guī)則引擎采用php開(kāi)發(fā)，不具備多線程的相關(guān)能力，所以這里并行是在before組裝rpc參數(shù)，通過(guò)curl_multi統(tǒng)一發(fā)起并行請(qǐng)求，在after函數(shù)取到結(jié)果。

以上能力在規(guī)則引擎框架上已經(jīng)封裝，組件的研發(fā)RD只需要關(guān)注PRC的實(shí)現(xiàn)即可，根據(jù)函數(shù)的定義框架實(shí)現(xiàn)并行或者異步的調(diào)用。

2.2 變量平臺(tái)

變量或者算子就是規(guī)則引擎中做規(guī)則判斷使用的參數(shù)，比如用戶名、帖子id、用戶等級(jí)、帖子內(nèi)容、模型識(shí)別的結(jié)果等，這部分的內(nèi)容越多，規(guī)則引擎可以創(chuàng)建規(guī)則的『素材』越多；

變量的來(lái)源分為三個(gè)部分：

（1）平臺(tái)預(yù)定義的變量：比如一些常量數(shù)字或者特定字符串，這部分內(nèi)容比較固定，變動(dòng)較少。

（2）業(yè)務(wù)入?yún)ⅲ簶I(yè)務(wù)在請(qǐng)求規(guī)則引擎的時(shí)候可以把盡可能多的參數(shù)變量傳遞過(guò)來(lái)，除了帖子、用戶、吧相關(guān)的數(shù)據(jù)，還可以把用戶ip、ua等各種數(shù)據(jù)一并傳遞，這些數(shù)據(jù)在變量的平臺(tái)化界面上可以做簡(jiǎn)單的篩選或者摘取，生成新的變量。

如圖舉例：input是一個(gè)完成的業(yè)務(wù)請(qǐng)求的變量，取input中的title生成testTitle變量，這樣就可以單獨(dú)使用testTitle做一些規(guī)則上的判斷。

（3）組件調(diào)用：在組件的部分已經(jīng)定義了具體的方法，該方法類似于lib庫(kù)或者util，具體的請(qǐng)求的入口在變量平臺(tái)實(shí)現(xiàn)，入?yún)⒕褪瞧渌兞俊?/p>

如圖舉例：testRPC是定義的組件，其中入?yún)⑹莟estTitle變量，返回的大結(jié)果作為一個(gè)testRPC變量。

后面可以對(duì)testRPC變量做具體的拆分，比如testRPC中的data.score作為一個(gè)單獨(dú)的變量，用score這個(gè)變量做后面的規(guī)則定義。

整體來(lái)說(shuō)，input是上游傳過(guò)來(lái)的基礎(chǔ)變量。對(duì)入?yún)⒆兞康恼砗瓦^(guò)濾可以生成額外的基礎(chǔ)變量；使用基礎(chǔ)參數(shù)（比如帖子id），通過(guò)rpc調(diào)用，可以生成擴(kuò)展的結(jié)果；對(duì)結(jié)果的提取可以生成額外的第二級(jí)變量；進(jìn)一步對(duì)二級(jí)變量繼續(xù)調(diào)用服務(wù)，可以生成更多的變量：比如通過(guò)圖片模型結(jié)果過(guò)一些文本模型，但是隨著層級(jí)的變深，整體服務(wù)呈現(xiàn)多級(jí)依賴關(guān)系，這也增加了整體的系統(tǒng)耗時(shí)。

對(duì)于入?yún)⒒蛘逺PC請(qǐng)求結(jié)果的處理，全部可以在變量平臺(tái)上進(jìn)行操作，變量平臺(tái)定義了規(guī)則引擎可以使用的變量及具體的實(shí)現(xiàn)方式。因?yàn)樽兞科脚_(tái)支持編輯代碼，所以一般的變量都可以直接在變量平臺(tái)編輯完成，而對(duì)相對(duì)復(fù)雜的模型調(diào)用，則可以封裝通用的util方法，之后在變量平臺(tái)直接使用這些方法。

2.3 規(guī)則引擎平臺(tái)

組件是一個(gè)個(gè)簡(jiǎn)單的util靜態(tài)方法，通過(guò)入?yún)⒓罢{(diào)用組件生成擴(kuò)展的變量；自此進(jìn)行規(guī)則判斷的『素材』準(zhǔn)備好了，接下來(lái)需要使用這些變量配置規(guī)則，而核心的規(guī)則引擎平臺(tái)就是使用這些變量，生成規(guī)則。

規(guī)則引擎目前支持的運(yùn)算規(guī)則：

規(guī)則運(yùn)算符：目前支持變量值與常量的比較，包含基本的>,<,>=,<=,==,!=多種比較方式；另外不僅可以直接使用變量，對(duì)于數(shù)組類型的變量，還可以直接使用了變量的計(jì)數(shù)count，對(duì)于string類型，可以使用變量的長(zhǎng)度len做參數(shù)直接進(jìn)行判斷。

詞表比較：判斷某個(gè)詞是否在詞表中是一個(gè)比較常用的規(guī)則；規(guī)則引擎平臺(tái)支持本地詞表與遠(yuǎn)程詞表；遠(yuǎn)程詞表為了解決詞表量級(jí)太大的問(wèn)題。

字符與詞表的比較包括精確匹配，包含、不包含、前綴匹配及后綴匹配幾種方式，基本覆蓋了常見(jiàn)的使用方式。

粒度控制判斷：為了判斷某個(gè)調(diào)整在一段時(shí)間內(nèi)的出現(xiàn)次數(shù)，平臺(tái)支持配置變量的出現(xiàn)次數(shù)統(tǒng)計(jì)。

對(duì)于某些使用頻次較少的運(yùn)算規(guī)則，平臺(tái)不在功能上進(jìn)行統(tǒng)一支持，但是可以通過(guò)修改變量來(lái)支持。比如想判斷變量A的sin值大于Z，可以在變量平臺(tái)新配置一個(gè)變量B，它的定位為sin（A），然后在規(guī)則引擎上使用B這個(gè)變量做判斷，就解決了某些特殊的計(jì)算方式。

對(duì)于判斷邏輯，目前支持if條件判斷，switch多分支判斷，確定召回，確定豁免四種方式，基本囊括了常用的判斷邏輯。

△簡(jiǎn)單的策略配置demo

2.4處置方法

處置方法是針對(duì)不同的業(yè)務(wù)場(chǎng)景召回的個(gè)性化處置邏輯，這部分需要RD開(kāi)發(fā)代碼，做個(gè)性化的處理；比如命中召回后返回true or false或者命中的規(guī)則號(hào)或者回調(diào)特殊標(biāo)記。

處置方法添加的頻率不會(huì)很高，基本固定對(duì)帖子、用戶或者各個(gè)場(chǎng)景有1-2個(gè)處置方法即可，后續(xù)的多個(gè)規(guī)則直接復(fù)用處置方法。

GEEK TALK

03

規(guī)則引擎實(shí)現(xiàn)原理

規(guī)則引擎最終生成是一個(gè)包含所有規(guī)則邏輯的代碼塊，代碼塊在規(guī)則引擎框架中運(yùn)行；生成的代碼塊類似研發(fā)開(kāi)發(fā)的代碼：代碼的邏輯依舊是定義變量、使用變量做條件判斷（規(guī)則）、命中召回的處置。

1. 變量

這部分比較容易理解，就是2.2部分；將所有定義的變量取出來(lái)，當(dāng)然因?yàn)樽兞恐g是遞歸依賴的，所以當(dāng)變量中需要其他變量時(shí)，會(huì)遞歸獲取內(nèi)容，直到獲取常量或沒(méi)有依賴為止，最后倒序輸出為代碼片段。

2. 規(guī)則文件生成

每一條規(guī)則在存儲(chǔ)上都是一個(gè)json串，存儲(chǔ)形式為一個(gè)nodeTree。其中一個(gè)node節(jié)點(diǎn)存儲(chǔ)了類型：判斷節(jié)點(diǎn)、召回節(jié)點(diǎn)、豁免節(jié)點(diǎn)以及多組(switch)判斷節(jié)點(diǎn)。其中召回節(jié)點(diǎn)和豁免節(jié)點(diǎn)是程序判斷的終止位置，當(dāng)執(zhí)行到召回節(jié)點(diǎn)時(shí)會(huì)加載規(guī)則引擎對(duì)應(yīng)的處置方法。判斷節(jié)點(diǎn)是整個(gè)規(guī)則引擎的核心，包含對(duì)應(yīng)的變量與比較方式。其中比較方式有數(shù)字比較、字符串比較及詞表比較。比如內(nèi)容中是否包含關(guān)鍵詞“AB”,則在判斷節(jié)點(diǎn)上選取內(nèi)容變量，比較方式為詞表包含，詞表內(nèi)容為“AB”。

在規(guī)則文件的設(shè)計(jì)上，采用nodeTree的方式，既能方便后續(xù)擴(kuò)展node的屬性和類型，又通過(guò)父子節(jié)點(diǎn)樹(shù)的方式多層級(jí)的表示復(fù)雜的if、switch邏輯，層級(jí)可以無(wú)限深。

在新的規(guī)則上線時(shí)，將nodeTree文件從數(shù)據(jù)庫(kù)中全部導(dǎo)出，生成全部的規(guī)則文件。規(guī)則文件依賴的變量已經(jīng)在變量文件中全部定義好，剩下的工作就是將變量與規(guī)則進(jìn)行組裝，生成最終的可執(zhí)行代碼。

另外對(duì)于某些特殊的需求，需要對(duì)白名單中的uid或者類型進(jìn)行全部策略豁免。對(duì)于此類需求可以修改所有的規(guī)則，增加前置判斷邏輯，但是此操作需要對(duì)現(xiàn)有的全部規(guī)則及增量規(guī)則都修改，且在規(guī)則執(zhí)行中會(huì)增加額外的判斷邏輯，增加整體規(guī)則引擎的執(zhí)行耗時(shí)，所以除了普通的規(guī)則外，貼吧規(guī)則引擎增加了全局規(guī)則區(qū)。全局規(guī)則區(qū)相當(dāng)于所有規(guī)則的前置條件，具體配置的規(guī)則為普通的node判斷節(jié)點(diǎn)，當(dāng)全局的所有規(guī)則判斷均為true時(shí)才會(huì)依次執(zhí)行具體的普通規(guī)則，這樣對(duì)于想全局豁免的需求，只需要簡(jiǎn)單配置全局規(guī)則即可，不需要修改具體的詳細(xì)規(guī)則。

3. 生成可執(zhí)行規(guī)則文件

規(guī)則引擎的前期編譯工作需要生成可以執(zhí)行的代碼，這部分就是將圖形化配置的規(guī)則與變量進(jìn)行組合，優(yōu)化整體的代碼執(zhí)行邏輯，生成可執(zhí)行的代碼，將文件下發(fā)到所有的線上機(jī)器。

其中變量文件是可以執(zhí)行的php語(yǔ)法，規(guī)則為導(dǎo)出的json文件，需要將不同類型的文件進(jìn)行組合，這里需要將不同文件源轉(zhuǎn)為同一種結(jié)構(gòu)化數(shù)據(jù)。

對(duì)于原本是php語(yǔ)法的文件，貼吧規(guī)則引擎采用ply和yacc進(jìn)行詞法和語(yǔ)法的解析，對(duì)php語(yǔ)法中array、函數(shù)、賦值、條件判斷、運(yùn)算符等進(jìn)行提取，轉(zhuǎn)為結(jié)構(gòu)化的數(shù)據(jù)。

對(duì)于規(guī)則文件，因?yàn)槭穷A(yù)先定義好的json nodeTree，包含的格式是有限可枚舉的，只要將每種類型與規(guī)則映射為結(jié)構(gòu)化的字段，就可以將規(guī)則文件轉(zhuǎn)位目標(biāo)結(jié)構(gòu)化數(shù)據(jù)。

之后就是可執(zhí)行文件的生成過(guò)程，具體需要以下步驟：

語(yǔ)法樹(shù)展開(kāi)：通過(guò)遞歸調(diào)用，將函數(shù)嵌套展開(kāi)。比如res = funA(funB($params))展開(kāi)為 tmp1 = funB($params)；res = funA(tmp1)；展開(kāi)后將高階函數(shù)展開(kāi)成普通函數(shù)，方便后續(xù)的優(yōu)化處理。

接下來(lái)就是語(yǔ)句優(yōu)化部分：

將不同變量重名的部分自動(dòng)增加_n后綴，避免變量的相互覆蓋；遍歷整體規(guī)則中使用的變量，如果存在變量從未使用過(guò)，從整體代碼中去除；對(duì)于定義了多遍重復(fù)的函數(shù)調(diào)用，整體去重只保留一份；對(duì)并行或者異步方法的函數(shù)組拆分成真正可執(zhí)行的靜態(tài)方法。經(jīng)過(guò)以上步驟，對(duì)將要生成的最終規(guī)則文件進(jìn)行了初步的整理及優(yōu)化。

在組件服務(wù)中提到了異步函數(shù)async；對(duì)于某些耗時(shí)非常高的模型服務(wù)，異步函數(shù)的作用是觸發(fā)調(diào)用后結(jié)束，等待第三方服務(wù)回調(diào)。

對(duì)于使用異步函數(shù)的情況，至少拆分成兩步，第一步發(fā)起觸發(fā)，第二步收到模型回調(diào)，取到該步驟的結(jié)果作為變量，所有依賴該變量的規(guī)則只能放到第二步執(zhí)行。如果有函數(shù)依賴第二步的結(jié)果，則步驟會(huì)繼續(xù)增加，該函數(shù)取某變量的異步結(jié)果，發(fā)起服務(wù)請(qǐng)求，第三步回調(diào)收到結(jié)果；異步函數(shù)展開(kāi)的作用是將所有無(wú)依賴的異步函數(shù)請(qǐng)求方法統(tǒng)一放在一起，并行請(qǐng)求，通過(guò)回調(diào)觸發(fā)執(zhí)行第二步的規(guī)則邏輯。這樣貼吧規(guī)則引擎可以很方便的接入高耗時(shí)的模型服務(wù)。

除了異步函數(shù)，還存在一種parallel并行調(diào)用的方式。由于規(guī)則引擎采用php的語(yǔ)言選型，沒(méi)有其他語(yǔ)言方便的多線程或者協(xié)程調(diào)用方式，對(duì)于無(wú)依賴的函數(shù)不能支持并行調(diào)用，所以在規(guī)則引擎的設(shè)計(jì)上通過(guò)curl_multil并行rpc調(diào)用服務(wù)的形式來(lái)減少耗時(shí)。

目前比較耗時(shí)的函數(shù)一般是請(qǐng)求數(shù)據(jù)庫(kù)服務(wù)或者第三方服務(wù)，這里將數(shù)據(jù)庫(kù)及第三方的調(diào)用全部封裝為http協(xié)議的形式，在策略文件調(diào)用上通過(guò)before方法整理入?yún)?，通過(guò)類似curl_multil的方法并行調(diào)用服務(wù)，取到結(jié)果后執(zhí)行各自函數(shù)的after方法，整理函數(shù)對(duì)應(yīng)的變量，這樣就將無(wú)依賴關(guān)系的調(diào)用進(jìn)行了并行處理，整體降低了耗時(shí)。并行函數(shù)合并就是框架層面做的自動(dòng)化合并，規(guī)則引擎的研發(fā)同學(xué)只需要簡(jiǎn)單定義before和after方法，編譯階段就會(huì)自動(dòng)將所有無(wú)依賴的函數(shù)before方法執(zhí)行，組裝rpc請(qǐng)求。如果某些函數(shù)在before階段依賴其他服務(wù)的結(jié)果，那么這批函數(shù)將在第二次發(fā)起請(qǐng)求，即無(wú)任何依賴的函數(shù)先發(fā)起并行請(qǐng)求，依賴第一批結(jié)果的函數(shù)再發(fā)起第二次并行請(qǐng)求，以此類推，最大限度的使用并行調(diào)用的方式。

最終生成的可執(zhí)行的文件，基本的最小單元為name、func、param、cond四組字段組成。如果cond判斷條件為真，則name通過(guò)函數(shù)和入?yún)?shù)執(zhí)行對(duì)應(yīng)方法，產(chǎn)出值；該值又是其他單元的條件變量或者函數(shù)入?yún)ⅲ@樣由上到下依次執(zhí)行，完成了所有規(guī)則的執(zhí)行。 仍然以上述demo策略為例：

最終生成了四組單元，基本格式如下：

如圖所示，基于上述的規(guī)則，只需要四組基本單元，每一組通過(guò)函數(shù)計(jì)算結(jié)果，下一組的條件依賴結(jié)果的值，如果走到“召回”邏輯，則進(jìn)行表示規(guī)則命中，返回對(duì)應(yīng)的規(guī)則號(hào)及其處置方法，框架中根據(jù)處置方法執(zhí)行對(duì)應(yīng)的邏輯。

每一個(gè)規(guī)則都是上述基本單元組成，最終將nodeTree中的全部規(guī)則生成基本單元，文件下發(fā)到所有運(yùn)行的機(jī)器上，至此完成了規(guī)則文件的產(chǎn)出與規(guī)則上線。

04

總結(jié)

貼吧規(guī)則引擎搭配圖形化的界面，非常方便非技術(shù)同學(xué)配置業(yè)務(wù)規(guī)則，將冗余的業(yè)務(wù)邏輯全部托管在規(guī)則引擎平臺(tái)上，無(wú)需代碼開(kāi)發(fā)，即可上線或者修改規(guī)則。 另外框架層面將異步、并行等復(fù)雜邏輯進(jìn)行了封裝，研發(fā)同學(xué)調(diào)用新的模型只需要按照模版修改簡(jiǎn)單的參數(shù)整理及返回?cái)?shù)據(jù)整理，即可完成并行或者異步的操作，減少規(guī)則引擎的執(zhí)行耗時(shí)。對(duì)于變量結(jié)果的轉(zhuǎn)換，也可以通過(guò)變量管理平臺(tái)，在平臺(tái)上簡(jiǎn)單的修改即可完成一些基本的整理邏輯，大大減少代碼的開(kāi)發(fā)量。 通過(guò)規(guī)則引擎，可以靈活配置運(yùn)營(yíng)活動(dòng)中的抽獎(jiǎng)規(guī)則、用戶身份權(quán)益配置、商品價(jià)格等包含復(fù)雜業(yè)務(wù)邏輯判斷的部分，將規(guī)則抽象出來(lái)，解放研發(fā)同學(xué)的人力，同時(shí)規(guī)則在平臺(tái)上可以方便查找和定位，方便后續(xù)的維護(hù)。

審核編輯 ：李倩