一、前言
風控系統是雪球社群風控的壁壘，高效穩定運作關系到社群内容安全合法合規的底線，是以系統在應變能力上要有更高的要求，随着業務發展和外部環境變化，原有系統不能很好的提供支援甚至造成“靈活”障礙，如面對水軍、黑産、羊毛黨等風險時，系統的處置能力滞後，業務與研發需要緊急制定應對這些臨時突發事件的處理措施。規則沒有統一的分類整理，風險識别與處置邏輯都是以寫死的方式混雜在一起，scala與java混雜，長期的累進式代碼疊代，開發維護測試成本很高。沒有統一的日志和快照資料輸出，不支援離線分析。定位問題效率低下，線上排查問題使用遠端debug等一系列痛點。原系統在資料、系統、工具層面相對薄弱的能力已經跟不上風控需要。
對業務和原系統了解加深後 ，開始梳理原系統内外部的關聯關系和其内部規則實作邏輯，規劃新系統要達到的目标，其應該有應對需求快速變化的響應能力，降低業務人員學習門檻、縮短産研同學介入周期的能力，安全調控規則與政策的能力，全面的資料回溯能力等，鑒于此開啟了規則引擎的建設之路。
什麼是規則引擎?風控系統中的核心是規則引擎，我們了解的規則引擎是現有業務場景下資料驅動的内容風險決策工具，使用可視化的DSL子產品編寫決策政策，把繁雜的決策邏輯從對業務人員不友好的程式代碼中剝離，并在政策調整的時效性、準确性、安全性上具備保障能力，且能夠支援具有學習能力的算法模型接入，為此我們總結規則引擎應具有的特性如下:
- 邏輯與資料的分離，對外隻暴露特征(fact)和動作，解耦政策與執行邏輯。
- 引擎在規則執行方面支援高并發低延時，在使用者體驗上做到無感覺。
- 政策配置靈活、高效、簡單。向業務人員提供直覺易用的圖形化配置工具，可以在秒或分鐘級别内完成配置調整，保證處置風險的時效。
- 完善的快照資料存儲能力，為業務分析和實時監控提供支援。
- 知識集中化，平台将流程、規則、特征、政策等納入到管理體系内，建構平台知識庫，提供全面了解系統能力的途徑。
- 各功能元件職能單一化。松散标準的元件化設計有着很強的擴充能力，便于任意組合實作不同場景下的需求，尤其是算法模型快速接入。
二、系統建設
1 系統架構
什麼是規則?規則是由一系列特征和具有動作觸發能力的政策構成的職能元件。什麼是引擎？系統内組織了衆多規則，引擎将他們納入自身的管理體系中，承擔起排程的職責，根據排程規則配置設定和協調資源之間依賴性，在什麼情況下做出什麼樣的反應。下圖就是簡化後的引擎驅動模型，預設的規則和外部特征輸入通過規則引擎的推理，按照編排資訊觸發規則，最終引擎将政策的結果輸出。
下圖是系統建設的架構圖，在編碼之前我們已經做了很多準備工作，對原系統規則進行分析，有拆分的安全性驗證、有判斷條件的準确性核對、有對外接口依賴情況的梳理，能否本地替換或做成标準的接口特征等方面做的調查，這些工作讓我們更加清晰了解原系統，給我們對建設規則引擎可行性上增強信心，也預留規則引擎的設計時間，提供從原系統平滑過渡和遷移的依據，後續就是開始了自下而上好幾個階段的系統建設，對于每類系統元件的職能、适用範圍，接下來開始分别介紹。
- 排程引擎是系統運轉的核心，負責元件編排，對其靈活性、性能、可維護性的要求很高，同時要貼合我們的業務場景。
- 逐漸“翻譯”原系統中的“規則”，适配成規則引擎中的特征與動作，政策條件我們手工錄入到系統，從生産環境引流接入到規則引擎進行初期實驗以及修複改進，這部分工作占據整個建設周期1/3的時間，其目的就是確定原系統規則“翻譯”後在引擎内也有一緻的表現。
- 釋出平台與資源同步器建設。原線下的部分流程處理工作轉為線上操作，解決原系統規則編排能力弱的問題，同時業務人員也會被邀請參與進來，縮短系統的傳遞時間，提升人效，将部分天級别的需求縮短到小時級别。
- 政策編輯器，這是面向業務人員的核心功能，我們了解到業務人員會寫sql和邏輯表達式，推廣編輯器會變得相對容易點，業務人員甚至可以在研發不參與的情況下編寫複雜的政策。
- 日志引擎，系統傳遞後的的核心功能，用于收集引擎運作時資料，風控的核心是資料，多元度資料能夠幫助我們發現一些未知風險，同時也能提高識别的準确率。系統各元件在一次請求過程中會産生大量中間資料，其體量規模會依據流程的複雜性被放大10倍甚至更大，這就要求日志引擎在不影響服務能力的情況下，提供安全靜默的資料收集能力，另外快照資料的留存解決我們隻有終态資料缺失過程資料的問題。在資料使用次元上規劃了長期和短期(3天)兩種方式，規則引擎在接收請求時會生成全局唯一的上下文ID，資料異步寫入hbase并使用上下文ID作為Rowkey，這樣在排查問題或者跟蹤資料時通過它可以一鍵帶出，另外監控也是基于短期的實時資料，長期全量的資料異步推送至數倉，用于離線場景的資料分析。
2基本元件與概念
2.1 特征與特征集
特征為系統運轉提供資料來源，作為政策執行的輸入(fact對象)，比如使用者資料對象，文章資料對象，模型輸出，也會有對輸入進行加工形成的新特征。在底層建設一段時間後開始對原系統規則進行梳理和拆解，其被拆分成特征、條件和動作三部分，動作與特征拆解時首先遇到的問題就是Scala文法差異性，在“翻譯”成Java後要保證結果的一緻性、準确性，為此編寫了大量的測試用例來覆寫各種場景，對于無資料寫入能力的特征，從生産環境引流灌入到引擎，分析其性能和準确性。
特征集是一系列特征集合。對于一些複雜場景的政策，觸發時需要不同的資料源，規則排程器會将其所關聯的所有特征資料填充至流程上下文中。針對特征集内會有多個特征的情況做了串/并行執行模式的适配，對執行時序方面有要求的場景使用串行模式，高優先級的特征會優先被加載，為了縮短服務的響應時間和提高系統性能及吞吐，多個無依賴關系的特征我們通常會采用并行模式去觸發。
2.2政策，政策集，動作
政策在系統定義上包含兩部分，即條件(LHS)和動作(RHS)，這也是建設規則引擎的理論和建構基礎，條件屬于動态變化的部分，用于政策邏輯判定，當邏輯輸出為true時才會觸發動作。動作具有單一職能特性屬于固化的部分，動态變化的政策條件會抽象出來交由業務人員管理。
政策集即一系列相同使用場景下政策的集合，政策集也具有串/并行執行模式，在串行模式上引入了中斷概念，支援集合内某個政策條件輸出為true後不會再觸發其他政策，并行模式下有所不同，所有政策都會觸發，待所有政策執行完成後引擎自動合并結果。
政策條件即邏輯表達式，在過往的項目中我們有使用mvel2的經驗，它的特性完全符合我們的需求，涵蓋了衆多的算術、邏輯運算符，還有清單、map等複雜資料類型的支援，在編譯模式下有着不錯的性能，另外支援static method方式擴充函數可以滿足95%以上的需求，比如可以增加求和，字元串截取，日期轉換等函數。
動作，政策條件幹預下觸發的行為，也是輸出執行結果的元件，在定制動作時通常将其應用範圍收縮到最小，盡可能做到職能單一，通過多個動作組合的形式實作複雜的邏輯，如當使用者釋出的内容被模型檢測出來涉黃，将觸發删帖與使用者降級動作。以下是一段政策的僞碼實作。
/** 政策1.1 */
rule "1.1"
if
${date}>"2021-07-02" && funA(funB(${text})) && ${type}==1 //政策條件
then
action( "1.1 matched" ); //動作
action( "1.2 matched" ); //動作
end
/** 政策1.2 */
rule "1.2"
if
${date}>"2021-07-01" && ${type}==2 && ${list}.contain("rule")
then
action( "1.3 matched" ); //動作
end
/** 政策2.1 */
rule "2.1"
if
${date}>"2021-07-03" && ${type}==4
then
action( "2.1 matched" ); //動作
end
2.3 規則
一系列特征的集合與具有相同輸入資料源要求的政策集共同組成的最小檢測單元，原系統中的規則在概念上被拆解擴充，賦予了更多的職能，它能組織和排程特征集進行資料提取，特征資料加載完成後轉移排程控制權交由政策集排程器，在拿到政策結果後收回排程權轉移給下一個規則。我們利用流程上下文的傳遞特性賦予規則空挂載的特性增加其不同場景下的适應能力，前置特征資料已經存在的情況下則可以隻挂載政策，當隻挂載特征集時相當于為後續規則制備資料。
2.4 流程
流程是服務于特定場景下的規則集合通過編排形成的規則流，在釋出平台内支援流程内規則增删、順序調整，政策調整等操作，這些都可以讓業務在研發不用參與的情況下由業務自行幹預，幹預的實時性從原系統以天為機關縮短到分鐘級别。如下所示我們其中一個場景下串聯編排成的流程。流程化的好處是規則引擎不再局限在内容管理場景，通過組合編排有需要風險決策的場景都可以接進來。釋出平台内建構的結構化知識庫，流程内各元件使用情況一目了然，依賴關系清晰明了。
3 排程引擎
上述内容對規則引擎内各個基礎元件的作用與承擔的角色做了描述，元件的運轉和驅動是依賴排程引擎完成的，相對獨立化的元件設計給未來擴充系統提供便利，解除強耦合性後，一些輔助控制器可以輕松內建到引擎内。下圖是某個場景下引擎工作時序示意圖。
3.1 排程器
3.1.1 流程排程器
流程在系統中有版本的概念，通過複制已釋出的流程建立新版本，基于版本管理賦予了流程排程器使用分流和并行模式的實驗能力，另外在處置各類風險事件的過程中，也可基于版本定制出應對不同風險場景的流程實作自由切換，做到面對黑産、水軍分别一個版本。在流程執行過程中引入上下文，上下文内的特征資料和政策結果會在流程中由前到後單向傳遞，這種方式的好處在于前面已經存在特征後續規則可以複用，縮短流程的執行時間。
- 分流模式
這種模式下流程排程器路由按預設的比例随機從多個版本中選擇一個排程，同一時刻隻有一個版本被觸發。這在一些需要參數微調的場景下比較有用，通過縮放比例實驗各版本的效果。
- 并行模式
此模式下，通常是流程版本差異過大，需要大量的資料進行驗證。流程排程器的路由會同時觸發所有的版本，每個版本的流程都有獨立的上下文，與分流模式的差異在于隻有已釋出狀态的版本流程中的動作會被觸發，其他版本内的動作永遠不會被執行。
在實際操作中業務人員通常克隆之前的版本來建立流程縮短配置時間，在克隆好的流程上進行規則上下線、政策調整，當驗證通過後才上線指定的版本并同時将舊版本下線，解決實時調整流程(政策)的周期過長的問題，同時提高了流程（政策）上線的安全性，自此流程管理可以不用研發參與。
3.1.2 規則排程器
從上面引擎排程時序圖我們看到，它負責特征集内特征的排程，當然規則也可以不需要特征，前面我們說到引入了流程上下文，規則排程器會将特征集内所有特征資料挂載到流程上下文中，待特征資料加載完成後向政策集排程器轉移控制權，也會将特征資料一并移交，與政策集類似在流程中也引入中斷機制，流程排程器會依據規則合并的政策結果決定是否中斷流程或繼續後續規則，可以應用到某些場景下命中一個規則後續規則無需再被觸發的需求。
3.1.3 政策集排程器
政策集主要是管理其内部的政策以及版本，有着和流程一樣分流與并行執行模式，是解決政策安全變更和上下線的第二個途徑，其作用就是提供多版本實驗能力并向政策排程器轉移控制權并移交特征資料。在引擎内有個約定就是隻能在上下文内追加特征資料和政策結果，不可有更新和删除行為，防止資料污染和失效，在編寫特征和動作時會依據此約定。
3.1.4 政策排程器
政策排程器職能是“翻譯”前文僞碼表達的政策，即執行政策條件并根據條件結果決定是否觸發動作，動作結果是流程排程器決定是否執行後續規則的結果來源。前面也說到表達式引擎是用mvel2作為動态/靜态可嵌入的表達式解析器，mvel2引擎功能強大，覆寫了很多應用場景的表達式需求。為了保證政策執行的安全性，我們又增加了政策預上線控制，處于此狀态的政策不會觸發動作，至此可以看到在引擎處理過程中提供了多種政策安全上下線途徑。
3.1.5 資源加載同步器
每一種排程器都預留擴充位置，這其中就包含了資源同步器，釋出平台内的同步器會推送元件配置變更事件至規則引擎，同步器會在排程器初始化和接收到變更事件時，啟動更新動作。
3.2 模型特征一體化
原風控系統使用單獨的子系統對接模型，每次新增模型都得重新開發接口去接入，模型疊代意味着接入工作會重複。梳理後我們發現與算法模型對接的接口所需參數都在引擎内，于是提出模型特征一體化方案，标準化模型特征輸入輸出，統一後的模型輸出是一個Map，其輸出key可以在釋出平台上設定，mvel2腳本引擎根據這些key從上下文内擷取模型的輸出，這一系列改動後，基于模型的規則與原系統規則整合在一個流程上，分散的模型識别資料聚合在一個平台内，接口接入被平台的能力接管，将研發從繁瑣的接口對接工作中解放出來，業務人員熟悉後也可自主完成模型對接。在配置上模型特征生成後其配置更新過程和其他組是一緻的，都是由資源同步器完成。
三、政策編輯
政策編輯器面向的是業務人員，他們平常會接觸sql和一些簡單的邏輯表達式，在設計編輯器時站在了使用者角度上，目的就是降低他們使用門檻，為此我們疊代了兩個版，從最初隻能編輯簡單的一維表達式向擁有任意複雜表達式編輯能力轉變。在編輯器内所有關聯元件都會被羅列在操作面闆上，并使用不同的顔色以示區分，常用的基本運算符是引擎預設支援的，使用者隻需要通過單擊、輕按兩下、拖拽即可完成任意表達式的建立，這種可視化DSL對業務人員十分友好，稍加教育訓練就能上手。如下圖建立一個簡單的政策表達式。
1 互動式Schema
政策編輯器Schema檔案被引擎解釋後交由前端完成表達式渲染，以及内置邏輯的初始化，也可以被解釋成引擎能識别的邏輯表達式。Schema的定義成了編輯器的重點，Schema定義好後引擎開發完畢，就很難重新設計Schema，甚至少許結構上的調整都是不允許的，邏輯上要準确自然，它的設計将直接影響引擎的性能或者直接影響引擎的實作方式。在開始設計時參考了antlr，想用它解釋翻譯定義好的可視化DSL與标準Schema，在實踐過程中發現改造麻煩，影響項目周期。
後來重新設計以json這種寬松的文檔結構為載體，實作了一套可視化DSL與标準Schema文檔轉換引擎，解決前端展示以及後端解釋、編譯問題，同時json擴充性強，在引擎翻譯和解釋時嚴格既定的字段屬性解釋，新增或者變化的屬性名不予處理。性能和安全我們也會考慮的方面，schema解釋後形成的邏輯表達式會在儲存時進行基本文法上的校驗，最後送出到規則引擎的虛拟環境進行驗證，由表達式引擎負責編譯，異常會給出提醒。當新增的預上線政策挂載到流程中後，業務人員會根據運作資料跟蹤其運作情況，系統層面也有政策監控或者異常報警，再者預上線的政策不會觸發動作，對生産系統上的業務不會有影響。
使用者層面的互動上，前端通過可視化DSL解決了渲染問題，業務人員調整政策後DSL随之發生變化，變更後的DSL會重新進入到DSL到Schema，Schema到引擎内政策位元組碼的變化流程中，對使用者無感覺，将在分析實時資料時展現變化結果。下圖即是編輯器到引擎表達式的轉換過程。
2 函數與常量
函數解決複雜場景中的邏輯計算問題，比如日期格式轉換等，如果要在表達式内實作這些複雜計算會使DSL設計難度增大，生成的邏輯表達式會包含大量冗長不便閱讀的代碼，這違背了我們的設計初衷，也給業務人員增加了編寫難度。基于mvel2提供的static method擴充能力，我們搜集業務常用的小功能和函數，在系統層面就內建進來，另外我們增加了一項應急的腳本函數功能，解決了mvel2内置的腳本函數不支援建立同名函數的問題，實作了對腳本函數的線上修改、釋出與測試。最重要的一點就是我們自定義的schema實作了編輯器内函數嵌套，更加複雜的邏輯計算不再是問題。
常量是另類的變量或者說是特征，對參數進行固化後形成的标準“特征”，常用的資料類型都會被覆寫到，如數值類型、字元串、清單(list)、Map等，引擎初始化時它們被自動加載，當政策被觸發時腳本引擎會從常量池内取值。它解決了不同人員在編輯表達式時對一些固化的配置重複定義、變更時需要修改多處的問題。
3 場景實踐
3.1 流程适配
每天社群都會生産出大量内容，快速甄别出違規内容是首要目标，首先是遷移原系統識别風險的35個有效規則，以下是原系統的一個風控串行流程示意圖，串行模式下規則未命中時下一個規則開始執行，這樣的過程會一直重複下去，這種模式最大的好處是結構簡單，有規則命中時終止流程運作，不足就是無任何政策命中時執行過程非常的長。接下來就是依據引擎特性挖掘潛力盡可能去平衡，為此會從如下方向上進行适配優化：
- 特征複用，減少接口調用次數。
- 特征的擷取由串行改并行。
- 政策執行模式由串行改并行
引擎在設計時就考慮了特征重複使用的需求，像使用者資訊、使用者發帖内容詳情這類資料對象會優先挂載到流程中，後續政策改從上下文内擷取這些資料，另外特征資料對象擷取方式改并行模式，這兩項優化下來不再有重複的特征，生成的資料對象減少至26個，接口調用從34次減少到14次，整體耗時從原來750ms縮短至500ms。
政策的接入稍微複雜點，原規則内隻會判斷是否命中，部分判斷邏輯在動作裡面也有嵌入需要剝離拆分，在資料源不變的情況下原來一個政策将會細分出更多政策，這些新增的政策将會在政策集内并行方式觸發。在實驗中發現并沒有因政策數量和排程次數增多對系統産生負面影響，依然維持在500ms左右，結果符合預期。下圖即優化後新的流程示意圖，虛線框内特征集與政策集都是并行模式觸發。
截止目前對該流程做了簡單彙總，用到的資料對象覆寫了涉黃、涉毒、新手規則、廣告、非法薦股等衆多類别，内容風險類别越來越多，系統覆寫的場景會同步增多，引擎便捷的擴充能力為内容管理提供高效服務。
規則特征資料對象政策數量50(其中10個未挂載特征)4862
3.2 安全政策接入
我們就以引入算法模型甄别高危内容這個場景為例，介紹業務人員做政策調整的過程，算法模型有不斷疊代修正、長期實驗的特性，這就要求系統有快速應變能力。在原Access模式下從研發接到需求開始到上線結束需要多方介入，當遇到複雜需求時整個周期可能是以天為機關，如果有調整流程參數或政策判斷條件之類的快速變更需求整個流程會重新輪回，周期變得越來越長。
引擎完成度的增加，其完善的接入、處置以及釋出機制的介入，規避了參與主體過多産生的部分人為因素風險，簡化了風控需求接入流程，通常情況下研發幹預的環節是建立模版，業務人員在研發的協助下生成模闆特征、虛拟環境内調試特征和政策，需求的參與主體将隻有業務人員，在平台安全機制保障下輔助業務人員平穩調整政策，接入過程變成如下示意圖所描述的那樣。
- 特征模版機制。模型特征一體化後接入模型變的非常容易，通過模闆生成特征。
- 虛拟環境。生成的特征、政策可線上實驗。
- 流程、規則、政策的可視化配置。
- 政策預上線機制。
參與主體隻有業務人員後，其自身就可以實作需求閉環，可在數分鐘内完成配置，極大的提高效率，安全性也有保證，最後通過離線資料分析政策命中情況，政策的上線與否是由業務人員通過分析結果做決策。如下圖薦股模型先審政策條件的調整，業務人員編輯完成釋出後機會立即生效。
四、虛拟環境與實驗
規則引擎在設計之初就将安全上線做為重點，任何業務類需求或者改動都需要在虛拟環境内檢驗通過後，方能配置到流程中，虛拟環境具有支援流程、特征和政策的驗證，形成配置化和模闆化的測試接入能力。
規則引擎經過幾個版本疊代後，釋出平台接入實驗接口，業務人員填充好待測元件所需的輸入參數，送出到運作容器使用引擎傳回的上下文ID即可在數倉擷取相應的關聯資料，因虛拟環境的安全特性所有送出的實驗都不會觸發動作。
在前面說到了模型特征一體化，模型特征和普通的特征差異化展現在建立上，模型特征基于模型特征模闆建構，建立好的模型特征不具備配置政策的能力，必須在虛拟環境内實驗通過，結果符合預期才能釋出，使用時其和普通的特征沒有任何差别。
政策虛拟環境，面向的對象主要是業務和研發人員，在本地或者測試環境無法支援的條件下，生産上進行無害化的實驗變得十分必要，容器内內建了日志引擎，具有資料收集能力，運作時資料會被日志引擎推送到數倉和Hbase叢集作為後續分析的資料源。
五、總結
以上總結了我們在建設規則引擎過程中的探索和實踐過程，推出對業務人員非常友好的可視化的政策編排功能，在使用上接近sql條件的編寫，在研發方面，縮短了開發時間，隻需要關注動作與特征開發。目前的規則引擎經過多個版本疊代，在政策編排上的難度做到了極大的簡化，業務效率和應對風險的能力提升非常明顯，後續我們會在系統層面完善精細化的權限控制，完善安全使用制度，增加上線審批，專人建立，專人維護等方面的權限校驗，增強平台安全使用方面的控制能力，支援線下或者線上政策分析的全流程回放、規則運作時并行化和特征資料之間的依賴分析等。在業務層面延伸使用場景，依據系統已經内置的大量特征，涉及決策的業務場景都可以進行快速接入，目前規則引擎已經應用到内容管理，搜尋業務内。
作者:雪球後端團隊
來源:微信公衆号:雪球工程師團隊
出處:https://mp.weixin.qq.com/s/dty9G51WDF9Lfelw7blDKg