簡介：?我們在很多場景下需要規則引擎將規則運算和業務解耦，但規則引擎不是銀彈。如果規則很簡單，或者變化頻次非常低那么使用 if-else 可能是最行之有效的實現方式，引入規則引擎反而增加維護成本。需要根據具體的業務形態選擇是否使用規則引擎，以及要是什么樣的規則引擎。

作者| 阿里文娛高級開發工程師 王士欣

一、規則引擎介紹

1. 為什么需要規則引擎

在很多企業的業務系統中，經常會有大量的業務規則配置，而且隨著企業管理者的決策變 化，這些業務規則也會隨之發生更改。例如，通信運營商的優惠活動：
1）用戶的每月使用總額比上月提高 1 成，超出部分可以享受 6 折優惠；
2）長途話費超出 200 的，超出部分可以享受八折優惠。
如果用代碼實現，if-else 可以很容易的實現上面的判斷邏輯。當規則變化時我們需要修改 這個 if-else 判斷邏輯。如果只是這樣的邏輯改起來也簡單。那么如果再添加新的規則呢？比如：
1）用戶的每月使用總額比上月提高 1 成，超出部分可以享受 6 折優惠；
2）長途話費超出 200 的，超出部分享受八折優惠；
3）網費超出 200 的，市話可以享受 5 折優惠，但有一個最高上限，即最多優惠 50 元；
4）使用增值服務的用戶，每月月租減少 10 元；
5）對于月消費不確定的用戶可以簽訂保底合同，即每月必須要消費到一定的額度，如果不 足將以保底額度來進行計算，超出的費用可以給予半價優惠。
雖然規則就這五條，編程得話會有很多的 if 語句，并且有很多嵌套的 if-else 語句，而且很 難實現且難維護。當規則需要變更時，為避免牽一發動全身，需要投入很多精力對改動進行測試。
這時就需要規則引擎將規則計算邏輯和業務系統解耦。

2. 什么是規則引擎

規則引擎是一種推理引擎，它是根據已有的事實，從規則知識庫中匹配規則，并處理存在 沖突的規則，執行最后篩選通過的規則。因此，規則引擎是人工智能（AI）研究領域的一部分， 具有一定的選擇判斷性、人工智能性和富含知識性。目前，比較流行的規則引擎有商業規則引 擎 iLog 和開源規則引擎 drools。

3. drools 規則引擎簡介

Drools 具有一個易于訪問企業策略、易于調整以及易于管理的開源業務 規則引擎，符合 業內標準，速度快、效率高。業務分析師或審核人員可以利用它輕松查看業務規則，從而檢驗 已編碼的規則是否執行了所需的業務規則。其前身是 Codehaus 的一個開源項目叫 Drools，最 近被納入 JBoss 門下，更名為 JBoss Rules，成為了 JBoss 應用服務器的規則引擎。
簡而言之，drools 是一個被廣泛應用的、高效的開源規則引擎。使用 drools 有一定的學習 成本，初次接觸時各種名詞：kie、fact、rete、Agenda、rules 等讓人眼花繚亂。最常見的 drools 架構：

上圖中，rules 即人工設置的規則文件，facts 為業務參數，inference engine 即推理引擎，即 做具體的規則匹配運算。
使用 drools 步驟：
1）準備規則文件，Drools 支持四種規則描述文件，分別是：drl 文件、xls 文件、brl 文 件和 dsl 文件，其中，常用的描述文件是 drl 文件和 xls 文件，而 xls 文件更易于維護，更直觀，更為被業務人員所理解；
2）系統啟動時，使用 drools 的 sdk 加載規則文件并編譯成字節碼。這需要我們封裝 drools的 jar 包，讀取規則文件并完成編譯動作。編譯完成后規則文件將作為字節碼存儲在內存中；
3）業務系統調用規則引擎進行規則匹配。調用規則引擎同樣是使用 drools 的 jar 包提供的api。業務系統需要將當前場景下的業務參數傳到規則引擎。

4. 優酷播放控制系統規則引擎簡介

上面簡述了規則引擎，以及使用廣泛的 drools，此處沒有做深入介紹，drools 是基于 rete算法實現的，這也是 drools 規則引擎的精髓所在，感興趣的同學深入研究 drools 以及 rete 算法。
在優酷播放控制場景下，我們并沒有使用 drools 這樣的開源規則引擎，而是自研了更加輕 量級的規則引擎。這是從開發的效率，運營的靈活性，以及實際場景出發來考慮。比如一組 drools 規則是解決一個場景下的規則計算問題，比如優惠券發放，產品積分計算等，都可以根據需要 編寫一組規則來實現。而對于播放控制場景，由于各個視頻版權方的要求等原因，每個視頻的 播放控制策略都可能不同，即對于不同的視頻來說，對應的播放策略都是不一樣的。這就沒辦 法使用確定的多組 drools 規則來 cover 所有視頻的播放控制策略。
此外，播控自研規則引擎，在性能、可視化、開發運營效率方面都有很大優勢。 下面會來介紹播放控制系統的規則引擎的實現思路。

二、優酷播控規則引擎技術實現

優酷播放控制系統是在點播和直播場景下對視頻的投放做精細化的控制，包括在搜索、首頁、頻道、推薦、直播，等各個場景下，均需要依賴播放控制系統的投放許可。此外，播放控 制系統還會對版權保護做精細化控制，根據端的細分情況，對端上的 drm 版權保護（Digital Rights Management, 數字版權管理），清晰度進行控制。

1. 技術挑戰

1）性能挑戰
播控系統調用規則引擎的 qps 為百萬級別。所以對規則引擎的性能要求很高。在計算過程 中每多產生一些負荷，就會被無限的放大。系統要求接口 rt 在毫秒級別。
2）投放的精細化控制 上文提到，優酷的各個場景都需要依賴播控的播放許可，由于版權方要求以及支持靈活的
運營策略，播放控制系統需要支持維度高達數十種，并且在不斷的擴充中。這需要規則引擎支持可靈活擴展的維度支持。

2. 規則引擎技術實現

自研規則引擎只關注規則匹配運算，與業務無關。即規則引擎會返回當前的參數與策略是 否匹配，業務系統根據規則引擎返回的匹配結果來判斷匹配規則后的處理邏輯。架構如下：

1）相對于 drools 的規則存儲在規則文件中，播控自研規則引擎的規則存儲在數據庫中，定 義規則表用于存儲于業務無關的規則。添加策略的頁面示例如下圖所示，將原因分類即一個規 則維度，內容分類為開一個規則維度。落庫時以 key-value 的形式存儲在數據庫。比如下圖中的 原因分類，在 db 中的 key=reasonType，value=H。

上文中提到過，每個視頻的投放規則都可能不同，所以需要針對各個視頻配置專屬的投放 規則。即定義視頻和投放規則的關聯表。用于存儲視頻和規則的關聯關系。
2）當系統啟動時，規則引擎讀取規則表中的全部規則，解析后存儲在規則引擎持有的容器中。
3）當業務系統接收到接口請求查詢投放規則時，首先會根據視頻查詢所屬于當前視頻的規則。
4）查詢到所屬視頻的規則后，將規則 id 以及當前用戶的環境參數傳遞給規則引擎進行規 則運算。規則引擎將計算規則是否匹配，返回結果后業務系統再封裝具體的接口返回結果。

3. 規則引擎計算流程

播控規則引擎支持分層運算，即對一組規則，劃分多個層次，每一層有一個優先級。這個 效果和 drools 的 salience 一樣，drools 中的 salience 表示權重，權重越大優先級越高。劃分好層 次之后，每一層會有多條規則，每一條規則中又包含多個維度。

假設圖 4 作為一個規則，那么在數據庫中的存儲為：{"reasonType":"H", "contentCategory":" 電視劇;電影;綜藝;少兒"}。規則引擎解析規則后存儲在規則容器中的數據結構非常簡單，即 Map>。

圖 5 中的單個維度計算也就變的非常的簡單，假設當前業務參數 contentCategory=綜藝，判 斷當前維度是否匹配，只需一行代碼：

4. 自研規則引擎優勢

1）高性能
從上面的介紹可以看到，規則的匹配只用到的set.contains 操作，過程中無需額外創建對象， 操作非常的高效。我們在使用這種計算方式之前，是采用了另一種計算方式，需要在計算過程 解析規則的expression（即規則表達式），這導致計算過程中會產生一些中間對象，對 gc 產生壓 力。在文章開頭有提到過，規則引擎的計算 qps 在百萬級別，每次計算產生的 gc 壓力會被放大 到影響系統性能。如下圖，在使用新的計算方式后 gc 次數降低了一半之多，并且接口 rt 同樣降低了有一半，效果非常明顯。

2）可視化
相對于 drools 的規則是使用 drl 文件或者 excel 管理，播控的規則是可以界面可視化操作的（如圖 4）。這對規則變更是高頻操作的場景較為關鍵。
3）規則可調試
使用過 drools 的人應該有這個苦惱，drools 規則是編寫好規則文件，然后將文件編譯成 java 字節碼存儲在drools 容器中。在運行過程中無法調試，只能通過引擎的返回結果判斷規則是否正確，當不符合預期時定位問題比較麻煩。播控自研的規則引擎如上所述直接 java 代碼運行支 持 debug，有助于提高開發效率。

三、總結

我們在很多場景下需要規則引擎將規則運算和業務解耦，但規則引擎不是銀彈。如果規則很簡單，或者變化頻次非常低那么使用 if-else 可能是最行之有效的實現方式，引入規則引擎反而增加維護成本。需要根據具體的業務形態選擇是否使用規則引擎，以及要是什么樣的規則引擎。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的优酷播控实践：基于规则引擎的投放管控模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。