2016 年 7 月恰逢美團(tuán)點(diǎn)評(píng)的業(yè)務(wù)進(jìn)入“下半場(chǎng)”，需要在各個(gè)環(huán)節(jié)優(yōu)化體驗(yàn)、提升效率、降低成本。技術(shù)團(tuán)隊(duì)需要怎么做來(lái)適應(yīng)這個(gè)變化?這個(gè)問(wèn)題直接影響著之后的工作思路。

美團(tuán)外賣的 CRM 業(yè)務(wù)步入成熟期，規(guī)則類需求幾乎撐起了這個(gè)業(yè)務(wù)所有需求的半邊天。

[[199586]]

一方面規(guī)則唯一不變的是“多變”，另一方面開(kāi)發(fā)團(tuán)隊(duì)對(duì)“規(guī)則開(kāi)發(fā)”的感受是乏味、疲憊和缺乏技術(shù)含量。如何解決規(guī)則開(kāi)發(fā)的效率問(wèn)題，***化解放開(kāi)發(fā)團(tuán)隊(duì)成為目前的一個(gè) KPI。

規(guī)則引擎作為常見(jiàn)的維護(hù)策略規(guī)則的框架很快進(jìn)入我的思路。它能將業(yè)務(wù)決策邏輯從系統(tǒng)邏輯中抽離出來(lái)，使兩種邏輯可以獨(dú)立于彼此而變化，這樣可以明顯降低兩種邏輯的維護(hù)成本。

分析規(guī)則引擎如何設(shè)計(jì)正是本文的主題，過(guò)程中也簡(jiǎn)單介紹了實(shí)現(xiàn)方案。

美團(tuán)規(guī)則引擎應(yīng)用實(shí)踐

首先回顧幾個(gè)美團(tuán)點(diǎn)評(píng)的業(yè)務(wù)場(chǎng)景，通過(guò)這些場(chǎng)景大家能更好地理解什么是規(guī)則，規(guī)則的邊界是什么。

在每個(gè)場(chǎng)景后面都介紹了業(yè)務(wù)系統(tǒng)現(xiàn)在使用的解決方案以及主要的優(yōu)缺點(diǎn)。

門店信息校驗(yàn)

場(chǎng)景

美團(tuán)點(diǎn)評(píng)合并前的美團(tuán)平臺(tái)事業(yè)部中，門店信息入口作為門店信息的***道關(guān)卡，有一個(gè)很重要的職責(zé)，就是質(zhì)量控制，其中***步就是針對(duì)一些字段的校驗(yàn)規(guī)則。

下面從流程的角度看下門店信息入口業(yè)務(wù)里校驗(yàn)門店信息的規(guī)則模型(已簡(jiǎn)化)，如下圖：

規(guī)則主體包括三部分：

• 分支條件。分支內(nèi)邏輯條件為“==”和“<”。
• 簡(jiǎn)單計(jì)算規(guī)則。如：字符串長(zhǎng)度。
• 業(yè)務(wù)定制計(jì)算規(guī)則。如：逆地址解析、經(jīng)緯度反算等。

方案：硬編碼

由于歷史原因，門店信息校驗(yàn)采用了硬編碼的方式，偽代碼如下：

if (StringUtil.isBlank(fieldA) 
   || StringUtil.isBlank(fieldB) 
   || StringUtil.isBlank(fieldC) 
   || StringUtil.isBlank(fieldD)) { 
   return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "門店參數(shù)缺少必填項(xiàng)"); 
}if (fieldA.length() < 10) { 
   return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "門店名稱長(zhǎng)度不能少于10個(gè)字符"); 
} 
if (!isConsistent(fieldB, fieldC, fieldD)) { 
   return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "門店xxx地址、行政區(qū)和經(jīng)緯度不一致"); 
} 

優(yōu)點(diǎn)：

• 當(dāng)規(guī)則較少、變動(dòng)不頻繁時(shí)，開(kāi)發(fā)效率***。
• 穩(wěn)定性較佳，語(yǔ)法級(jí)別錯(cuò)誤不會(huì)出現(xiàn)，由編譯系統(tǒng)保證。

缺點(diǎn)：

• 規(guī)則迭代成本高，對(duì)規(guī)則的少量改動(dòng)就需要走全流程(開(kāi)發(fā)、測(cè)試、部署)。
• 當(dāng)存量規(guī)則較多時(shí)，可維護(hù)性差。
• 規(guī)則開(kāi)發(fā)和維護(hù)門檻高，規(guī)則對(duì)業(yè)務(wù)分析人員不可見(jiàn)。業(yè)務(wù)分析人員有規(guī)則變更需求后無(wú)法自助完成開(kāi)發(fā)，需要由開(kāi)發(fā)人員介入開(kāi)發(fā)。

門店審核流程

場(chǎng)景

流程控制中心(負(fù)責(zé)在運(yùn)行時(shí)根據(jù)輸入?yún)?shù)選擇不同的流程節(jié)點(diǎn)從而構(gòu)建一個(gè)流程實(shí)例)會(huì)根據(jù)輸入門店信息中的渠道來(lái)源和品牌等特征確定本次審核(不)走哪些節(jié)點(diǎn)，其中選擇策略的模型如下圖：

規(guī)則主體是分支條件：

• 分支條件主體是“==”，參與計(jì)算的參數(shù)是固定值和用戶輸入實(shí)體的屬性(比如：渠道來(lái)源和品牌類型)。

方案：開(kāi)源 Drools 從入門到放棄

經(jīng)過(guò)一系列調(diào)研，團(tuán)隊(duì)選擇基于開(kāi)源規(guī)則引擎 Drools 來(lái)配置流程中審核節(jié)點(diǎn)的選擇策略。使用 Drools 后的規(guī)則配置流程如下圖：

上圖中 DSL 即是規(guī)則主體，規(guī)則內(nèi)容如下：

rule "1.1" 
   when 
       poi : POI( source == 1 && brandType == 1 ) 
   then 
           System.out.println( "1.1 matched" ); 
           poi.setPassedNodes(1); 
 
end 
 
rule "1.2" 
   when 
       poi : POI( source == 1 && brandType == 2 ) 
   then 
           System.out.println( "1.2 matched" ); 
 
end 
 
rule "2.1" 
   when 
       poi : POI( source == 2 && brandType == 1 ) 
   then 
           System.out.println( "2.1 matched" ); 
           poi.setPassedNodes(2); 
 
end 
 
rule "2.2" 
   when 
       poi : POI( source == 2 && brandType == 2 ) 
   then 
           System.out.println( "2.2 matched" ); 
           poi.setPassedNodes(3); 
 
end 

在實(shí)踐中，我們發(fā)現(xiàn) Drools 方案有如下幾個(gè)優(yōu)缺點(diǎn)，由于 Drools 的問(wèn)題較多，***這個(gè)方案還是放棄了。

優(yōu)點(diǎn)：

• 策略規(guī)則和執(zhí)行邏輯解耦方便維護(hù)。

缺點(diǎn)：

• 業(yè)務(wù)分析師無(wú)法獨(dú)立完成規(guī)則配置，由于規(guī)則主體 DSL 是編程語(yǔ)言(支持 Java，Groovy，Python)，因此仍然需要開(kāi)發(fā)工程師維護(hù)。
• 規(guī)則規(guī)模變大以后也會(huì)變得不好維護(hù)，相對(duì)硬編碼的優(yōu)勢(shì)便不復(fù)存在。
• 規(guī)則的語(yǔ)法僅適合扁平的規(guī)則，對(duì)于嵌套條件語(yǔ)義(then 里嵌套 when...then 子句)的規(guī)則只能將條件進(jìn)行笛卡爾積組合以后進(jìn)行配置，不利于維護(hù)。

績(jī)效指標(biāo)計(jì)算

場(chǎng)景

美團(tuán)外賣業(yè)務(wù)發(fā)展非常迅速，績(jī)效指標(biāo)規(guī)則需要快速迭代才能緊跟業(yè)務(wù)發(fā)展步伐。績(jī)效考核頻率是一個(gè)月一次，因此績(jī)效規(guī)則的迭代頻率也是每月一次。因?yàn)榭?jī)效規(guī)則系統(tǒng)是硬編碼實(shí)現(xiàn)，因此開(kāi)發(fā)團(tuán)隊(duì)需要投入大量的人力滿足規(guī)則更新需求。

2016 年 10 月底，我受績(jī)效團(tuán)隊(duì)委托成立一個(gè)項(xiàng)目組，開(kāi)發(fā)部署了一套績(jī)效指標(biāo)配置系統(tǒng)，系統(tǒng)上線直接減少了產(chǎn)品經(jīng)理和技術(shù)團(tuán)隊(duì) 70% 的工作量。

下面我們首先分析下績(jī)效指標(biāo)計(jì)算的規(guī)則模型，如下圖：

規(guī)則主體是結(jié)構(gòu)化數(shù)據(jù)處理邏輯：

規(guī)則邏輯是從若干數(shù)據(jù)源獲取數(shù)據(jù)，然后進(jìn)行一系列聚合處理(可以采用結(jié)構(gòu)化查詢 SQL 語(yǔ)句+少量代碼實(shí)現(xiàn))，***輸出到目標(biāo)數(shù)據(jù)源。

方案：業(yè)務(wù)定制規(guī)則引擎

績(jī)效規(guī)則主體是數(shù)據(jù)處理，但我們認(rèn)為數(shù)據(jù)處理同樣屬于規(guī)則的范疇，因此我們將其放在本文進(jìn)行分析。

下圖是績(jī)效指標(biāo)配置系統(tǒng)，觸發(fā)器負(fù)責(zé)定時(shí)驅(qū)動(dòng)引擎進(jìn)行計(jì)算;視圖負(fù)責(zé)給商業(yè)分析師提供規(guī)則配置界面，規(guī)則表達(dá)能力取決于視圖;引擎負(fù)責(zé)將配置的規(guī)則解析成 Spark 原語(yǔ)進(jìn)行計(jì)算。

優(yōu)點(diǎn)：

• 規(guī)則配置門檻低，視圖和引擎內(nèi)部數(shù)據(jù)模型完全貼合績(jī)效業(yè)務(wù)模型，因此業(yè)務(wù)分析師很容易上手。
• 系統(tǒng)支持規(guī)則熱部署。

缺點(diǎn)：

• 適用范圍有限，因?yàn)橐晥D和引擎的設(shè)計(jì)完全基于績(jī)效業(yè)務(wù)模型，因此很難低成本修改后推廣到別的業(yè)務(wù)。

探索全新設(shè)計(jì)

“案例”一節(jié)中三種落地方案的問(wèn)題總結(jié)如下：

• 硬編碼迭代成本高。
• Drools 維護(hù)門檻高。視圖對(duì)非技術(shù)人員不友好，即使對(duì)于技術(shù)人員來(lái)說(shuō)維護(hù)成本也不比硬編碼低。
• 績(jī)效定制引擎表達(dá)能力有限且擴(kuò)展性差，無(wú)法推廣到別的業(yè)務(wù)。

由于“高效配置規(guī)則”是業(yè)務(wù)里長(zhǎng)期存在的剛需，且行業(yè)內(nèi)又缺乏符合需求的解決方案，2017 年 2 月我在團(tuán)隊(duì)內(nèi)部設(shè)立了一個(gè)虛擬小組專門負(fù)責(zé)規(guī)則引擎的設(shè)計(jì)研發(fā)。

引擎設(shè)計(jì)指標(biāo)是要覆蓋工作中基礎(chǔ)的規(guī)則迭代需求(包括但不限于“案例”一節(jié)中的多個(gè)場(chǎng)景)，同時(shí)針對(duì)“案例”一節(jié)中已有解決方案揚(yáng)長(zhǎng)避短。

下面分三節(jié)來(lái)重現(xiàn)這個(gè)項(xiàng)目的設(shè)計(jì)過(guò)程：

• “需求模型”，會(huì)基于“案例”一節(jié)的場(chǎng)景嘗試抽象出規(guī)則模型，同時(shí)提煉出系統(tǒng)設(shè)計(jì)大綱。
• “Maze 框架”，會(huì)基于需求模型設(shè)計(jì)一個(gè)規(guī)則引擎。
• “Maze 框架能力模型”，會(huì)介紹 Maze 框架的特點(diǎn)。

需求模型

對(duì)規(guī)則引擎來(lái)說(shuō)，世界皆規(guī)則。通過(guò)“案例”一節(jié)的分析，我們對(duì)規(guī)則以及規(guī)則引擎該如何構(gòu)建的思路正逐漸變得清晰。

下面兩節(jié)分別定義規(guī)則數(shù)據(jù)模型和規(guī)則引擎的系統(tǒng)模型，目標(biāo)是對(duì)“Maze 框架”一節(jié)中的規(guī)則引擎產(chǎn)品進(jìn)行框架性指導(dǎo)。

規(guī)則數(shù)據(jù)模型

規(guī)則本質(zhì)是一個(gè)函數(shù)，由 n 個(gè)輸入、1 個(gè)輸出和函數(shù)計(jì)算邏輯 3 部分組成。

y = f(x1, x2, …, xn)

具體結(jié)合“案例”一節(jié)中的場(chǎng)景，我們梳理出的規(guī)則模型如下圖所示：

主要由三部分構(gòu)成：

• FACT 對(duì)象，用戶輸入的規(guī)則模型，作為決策因子使用。
• 規(guī)則，LHS(Left Hand Side)部分即條件分支邏輯。RHS(Right Hand Side)部分即執(zhí)行邏輯。LHS 和 RHS 部分是由一個(gè)或多個(gè)模式構(gòu)成的。模式是規(guī)則內(nèi)最小單位。

模式的輸入?yún)?shù)可以是另一個(gè)模式或 FACT 對(duì)象(比如邏輯與運(yùn)算[參數(shù) 1] && [參數(shù) 2]中參數(shù) 1 可以是另一個(gè)表達(dá)式)。

模式需要支持以下三種類別：

• 客戶定義方法，F(xiàn)ACT 對(duì)象的實(shí)例方法、靜態(tài)方法。
• 常規(guī)表達(dá)式，邏輯運(yùn)算、算數(shù)運(yùn)算、關(guān)系運(yùn)算、對(duì)象屬性處理等。
• 結(jié)構(gòu)化查詢。

結(jié)果對(duì)象，規(guī)則處理完畢后的結(jié)果。需要支持自定義類型或者簡(jiǎn)單類型(Integer、Long、Float、Double、Short、String、Boolean 等)。

系統(tǒng)模型

我們需要設(shè)計(jì)一個(gè)系統(tǒng)能配置、加載、解釋執(zhí)行上節(jié)中的數(shù)據(jù)模型，另外設(shè)計(jì)時(shí)還需要規(guī)避“案例”一節(jié) 3 個(gè)方案的缺點(diǎn)。最終我們定義了如下圖所示的系統(tǒng)模型。

主要由三個(gè)模塊構(gòu)成：

• 知識(shí)庫(kù)，負(fù)責(zé)提供配置視圖和模式因子。知識(shí)庫(kù)之所以叫“知識(shí)”庫(kù)一個(gè)很重要的特征是知識(shí)庫(kù)可以低成本擴(kuò)展知識(shí)。

知識(shí)擴(kuò)展包括視圖和模式的添加，視圖和模式有一對(duì)一映射關(guān)系，比如我們?cè)诮缑嫔险故疽粋€(gè)如：大于小于等于一樣的視圖，則一定有一個(gè)模式$參數(shù) 1 > $參數(shù) 2與之對(duì)應(yīng)。

• 一方面降低操作門檻。
• 一方面約束用戶輸入，保證輸入合法性。
• 視圖，用于業(yè)務(wù)分析師等非技術(shù)背景的人員配置規(guī)則，作用于兩方面。
• 模式，構(gòu)成規(guī)則的最小單位，不可拆分，可以直接被規(guī)則引擎執(zhí)行。
• 資源管理器，負(fù)責(zé)管理規(guī)則。
• 版本管理，支持規(guī)則迭代更新、回滾和灰度等功能。
• 依賴管理，負(fù)責(zé)將規(guī)則解析為模式樹(shù)。為了***限度地增強(qiáng)規(guī)則的表達(dá)能力，每一個(gè)模式設(shè)計(jì)都很“原子”，這樣如果想配置一個(gè)完整語(yǔ)義的規(guī)則，則必須由多個(gè)子規(guī)則共同構(gòu)成，因此規(guī)則之間會(huì)有樹(shù)形依賴關(guān)系。

如$參數(shù) 1 + $參數(shù) 2 > $參數(shù) 3 這樣的規(guī)則便是由多個(gè)模式“復(fù)合”而成，則他的依賴關(guān)系如下所示：

最終結(jié)果           /** 變量模式 */ 
             | 
             | 
           中間結(jié)果 > $參數(shù)3  /** 關(guān)系運(yùn)算模式 */ 
             | 
             | 
      $參數(shù)1 + $參數(shù)2        /** 算數(shù)運(yùn)算模式 */ 

• 規(guī)則引擎，負(fù)責(zé)執(zhí)行規(guī)則。
• 調(diào)度器，根據(jù)規(guī)則的依賴關(guān)系以及硬件資源驅(qū)動(dòng)模式執(zhí)行器執(zhí)行模式，目標(biāo)是達(dá)到***吞吐或***延遲。
• 模式執(zhí)行器，負(fù)責(zé)直接執(zhí)行模式。執(zhí)行器可以根據(jù)業(yè)務(wù)的表達(dá)能力需求選擇基于 Drools、Aviator 等第三方引擎，甚至可以基于 ANTLR 定制。

Maze 框架

基于"需求模型"一節(jié)的定義，我們開(kāi)發(fā)了 Maze 框架(Maze 是迷宮的意思，寓意：迷宮一樣復(fù)雜的規(guī)則)。

Maze 框架分兩個(gè)引擎：

• MazeGO(策略引擎)。
• MazeQL(結(jié)構(gòu)化數(shù)據(jù)處理引擎)。

其中 MazeGO 內(nèi)解析到結(jié)構(gòu)化數(shù)據(jù)處理模式會(huì)調(diào)用 SQLC 驅(qū)動(dòng) MazeQL 完成計(jì)算，比如：從數(shù)據(jù)庫(kù)里查詢某個(gè) BD 的月交易額，如果交易額超過(guò) 30 萬(wàn)則執(zhí)行 A 邏輯否則執(zhí)行 B 邏輯，這個(gè)語(yǔ)義的規(guī)則需要執(zhí)行結(jié)構(gòu)化查詢。

MazeQL 內(nèi)解析到策略計(jì)算模式會(huì)調(diào)用 VectorC 驅(qū)動(dòng) MazeGO 進(jìn)行計(jì)算，比如：有一張訂單表，其中***列是商品 ID，第二列是商品購(gòu)買數(shù)量，第三列是此商品的單價(jià)。

我們需要計(jì)算每類商品的總價(jià)則需要對(duì)結(jié)構(gòu)化查詢到的結(jié)果的每一行執(zhí)行第二列 * 第三列這樣的策略模式計(jì)算。

名詞解釋：

• VectorC 指向量計(jì)算，針對(duì)矩陣的行列進(jìn)行計(jì)算。有三種計(jì)算方式：
• 針對(duì)一行的多列進(jìn)行策略計(jì)算。
• 針對(duì)一列進(jìn)行計(jì)算。
• 針對(duì)分組聚合(GroupBy)后的每一組內(nèi)的列進(jìn)行運(yùn)算。
• SQLC 指結(jié)構(gòu)化查詢，擁有執(zhí)行 SQL 的能力。

MazeGO

MazeGO 核心主要由三部分構(gòu)成：

• 資源管理器。
• 知識(shí)庫(kù)。
• MazeGO 引擎。

另外兩個(gè)輔助模塊是流量控制器和規(guī)則效果分析模塊，基本構(gòu)成如下圖：

三個(gè)核心模塊(引擎、知識(shí)庫(kù)和資源管理器)的職責(zé)見(jiàn)“需求模型”一節(jié)中“系統(tǒng)模型”一節(jié)。

下面只介紹下和“系統(tǒng)模型”不同的部分：

• MazeGO引擎，預(yù)加載規(guī)則實(shí)例。首先為了避免訪問(wèn)規(guī)則時(shí)需要實(shí)時(shí)執(zhí)行遠(yuǎn)程調(diào)用而造成較大的時(shí)延，另外規(guī)則并不是時(shí)刻發(fā)生變更沒(méi)有必要每次訪問(wèn)時(shí)拉取一次***版本。

基于以上兩個(gè)原因規(guī)則管理模塊會(huì)在引擎初始化階段將有效版本的規(guī)則實(shí)例緩存在本地并且監(jiān)聽(tīng)規(guī)則變更事件(監(jiān)聽(tīng)可以基于 ZooKeeper 實(shí)現(xiàn))。

預(yù)編譯規(guī)則實(shí)例，因?yàn)橐?guī)則每次編譯執(zhí)行會(huì)導(dǎo)致性能問(wèn)題，因此會(huì)在引擎初始化和規(guī)則有變更這兩個(gè)時(shí)機(jī)將增量版本的規(guī)則預(yù)編譯成可執(zhí)行代碼。規(guī)則管理模塊。職責(zé)如下：

• 流量控制器，負(fù)責(zé)不同版本規(guī)則的調(diào)度。方便業(yè)務(wù)方修改規(guī)則后，灰度部分流量到新規(guī)則。
• 規(guī)則效果分析，規(guī)則新增或修改后，業(yè)務(wù)方需要分析效果。本模塊會(huì)提供規(guī)則內(nèi)部執(zhí)行路徑、運(yùn)行時(shí)參數(shù)和結(jié)果的鏡像數(shù)據(jù)，數(shù)據(jù)可以存儲(chǔ)在 Hbase 上。

MazeQL

MazeQL 核心主要由三部分構(gòu)成：

• 配置中心。
• MazeQL 引擎。
• 平臺(tái)。

• MazeQL引擎

調(diào)度器，SQLC 和 VectorC 類規(guī)則大多由多個(gè)規(guī)則組合而成(對(duì)于 SQLC 而言可以將依賴的規(guī)則簡(jiǎn)單的理解為子查詢)，因此也需要和“系統(tǒng)模型”一節(jié)一樣的調(diào)度管理，實(shí)現(xiàn)層面完全一致。

QL 驅(qū)動(dòng)器，驅(qū)動(dòng)平臺(tái)進(jìn)行規(guī)則計(jì)算。因?yàn)槿蝿?wù)的實(shí)際執(zhí)行平臺(tái)有多種(會(huì)在下一個(gè)“平臺(tái)”部分介紹)，因此 QL 驅(qū)動(dòng)器也有多種實(shí)現(xiàn)。

預(yù)加載規(guī)則實(shí)例，首先為了避免訪問(wèn)規(guī)則時(shí)需要實(shí)時(shí)執(zhí)行遠(yuǎn)程調(diào)用而造成較大的時(shí)延，另外規(guī)則并不是時(shí)刻發(fā)生變更沒(méi)有必要每次訪問(wèn)時(shí)拉取一次***版本。

基于以上兩個(gè)原因規(guī)則管理模塊會(huì)在引擎初始化階段將有效版本的規(guī)則實(shí)例緩存在本地并且監(jiān)聽(tīng)規(guī)則變更事件(監(jiān)聽(tīng)可以基于 ZooKeeper 實(shí)現(xiàn))。

預(yù)解析規(guī)則實(shí)例，因?yàn)橐?guī)則每次解析執(zhí)行會(huì)導(dǎo)致性能(大對(duì)象)問(wèn)題，因此會(huì)在引擎初始化階段解析為運(yùn)行時(shí)可用的調(diào)度棧幀。

規(guī)則管理模塊，職責(zé)如下，運(yùn)行時(shí)模塊。分為調(diào)度器和 QL 驅(qū)動(dòng)器。

• 平臺(tái)

負(fù)責(zé)實(shí)際執(zhí)行規(guī)則邏輯，分兩種運(yùn)行模式：一種是以嵌入式方式運(yùn)行在客戶端進(jìn)程內(nèi)部，好處是實(shí)時(shí)性更好，時(shí)延更低，適合小批量數(shù)據(jù)處理;另一種是以遠(yuǎn)程方式運(yùn)行在 Spark 平臺(tái)，適合離線大規(guī)模數(shù)據(jù)處理。

嵌入式模式下是基于 MySQL 和 Derby 等實(shí)時(shí)性較好的數(shù)據(jù)庫(kù)實(shí)現(xiàn)的。在 Spark 平臺(tái)上是基于 Spark SQL 實(shí)現(xiàn)的。

QL 執(zhí)行器，負(fù)責(zé)執(zhí)行結(jié)構(gòu)化查詢邏輯。兩種不同的運(yùn)行模式下 QL 執(zhí)行器在執(zhí)行 SQL 模式時(shí)會(huì)選擇兩種不同的 QL 執(zhí)行器實(shí)現(xiàn)，兩種實(shí)現(xiàn)分別是：

• 配置中心

提供規(guī)則配置視圖。版本管理，同“系統(tǒng)模型”一節(jié)。

數(shù)據(jù)源綁定，即是定義參與計(jì)算的 SQL 邏輯中使用到的數(shù)據(jù)源，便于系統(tǒng)進(jìn)行管理。

結(jié)構(gòu)查詢定義，即是定義 SQL 規(guī)則，這是主體規(guī)則內(nèi)容。

向量計(jì)算定義，定義 VectorC 類計(jì)算(VectorC見(jiàn)“Maze框架”章節(jié)開(kāi)頭的介紹)。

Maze 框架能力模型

Maze 框架是一個(gè)適用于非技術(shù)背景人員，支持復(fù)雜規(guī)則的配置和計(jì)算引擎。

規(guī)則迭代安全性

規(guī)則支持熱部署，系統(tǒng)通過(guò)版本控制，可以灰度一部分流量，增加上線信心。

規(guī)則表達(dá)能力，框架的表達(dá)能力覆蓋絕大部分代碼表達(dá)能力。下面用偽代碼的形式展示下 Maze 框架的規(guī)則部分具有的能力。

// 輸入N個(gè)FACT對(duì)象 
function(Fact[] facts) {    
   // 從FACT對(duì)象里提取模式      
   String xx= facts[0].xx;   
   // 從某個(gè)數(shù)據(jù)源獲取特征數(shù)據(jù)，SQLC數(shù)據(jù)處理能力遠(yuǎn)超sql語(yǔ)言本身能力，SQLC具有編程+SQL的混合能力 
   List<Fact> moreFacts = connection.executeQuery("select * from xxx where xx like '%" + xx + "%');   
   // 對(duì)特征數(shù)據(jù)和FACT對(duì)象應(yīng)用用戶自定義計(jì)算模式 
   UserDefinedClass userDefinedObj = userDefinedFuntion(facts, moreFacts);   
   // 使用系統(tǒng)內(nèi)置表達(dá)式模式處理特征                       
   int compareResult = userDefinedObj.getFieldXX().compare(XX);  
   // 聲明用戶自定義對(duì)象          
   UserDefinedResultClass userDefinedResultObj = new UserDefinedResultClass();   
   // 使用系統(tǒng)內(nèi)置條件語(yǔ)句模式處理特征                               
   if (compareResult  == 0) {      
       userDefinedResultObj.setCompareResult(Boolean.FALSE); 
   } else if (compareResult > 0) { 
       userDefinedResultObj.setCompareResult(Boolean.FALSE); 
   } else { 
       userDefinedResultObj.setCompareResult(Boolean.TRUE); 
   } 
   // 將結(jié)果返回給客戶 
   return userDefinedResultObj;         
} 

規(guī)則執(zhí)行效率

執(zhí)行效率分三方面：

• 引擎的調(diào)度模塊會(huì)確保吞吐優(yōu)先，并且調(diào)度并發(fā)度等系統(tǒng)配置可以根據(jù)資源情況調(diào)整。
• 引擎運(yùn)行過(guò)程中沒(méi)有遠(yuǎn)程通信開(kāi)銷。
• 引擎執(zhí)行代碼實(shí)現(xiàn)編譯或解析后執(zhí)行，運(yùn)行效率較高。

規(guī)則接入成本

開(kāi)發(fā)人員接入：

• 首先，開(kāi)發(fā)人員在項(xiàng)目工程里導(dǎo)入一個(gè) MazeGO jar 包。
• 然后，開(kāi)發(fā)人員在項(xiàng)目工程里需要調(diào)用計(jì)算規(guī)則的地方引入 MazeGO client(如下代碼片段)。

// 初始化MazeGO client，建議在本應(yīng)用程序的初始化階段執(zhí)行 
MazeGOReactor reactor = new MazeGOReactor(); 
reactor.setMazeIds(Arrays.asList(<mazeId>)); 
reactor.init(); 
 
// 調(diào)用MazeGO client執(zhí)行規(guī)則 
reactor.go(<mazeId>, <fact>); 
 
// 銷毀MazeGO client，建議在本應(yīng)用程序的銷毀階段執(zhí)行 
reactor.destroy(); 

規(guī)則配置，規(guī)則配置基本實(shí)現(xiàn)由業(yè)務(wù)分析師、產(chǎn)品經(jīng)理或運(yùn)營(yíng)人員自助完成。

業(yè)務(wù)分析師在 MazeGO 上配置規(guī)則的視圖如下圖所示：

總結(jié)

本文開(kāi)頭介紹了幾個(gè)工作中的規(guī)則使用場(chǎng)景，順帶引出了多個(gè)不同的解決方案，***介紹了 Maze 框架的設(shè)計(jì)，基本上展現(xiàn)了我們對(duì)這個(gè)框架思考和設(shè)計(jì)的整個(gè)過(guò)程。