| 在互聯(lián)網(wǎng)時代，安全已經(jīng)成為企業(yè)的命脈。美團信息安全團隊需要采用各種措施和手段來保障業(yè)務安全，從而確保美團平臺上的用戶和商戶利益不會受到侵害。

本文主要介紹了美團在打造自有規(guī)則引擎Zeus（中文名“宙斯”）的過程中，信息安全團隊遇到的挑戰(zhàn)以及對應的解決方案，并分享了很多踩過的坑，同時還有一些思考和總結。希望對從事安全領域相關工作的同學能夠有所啟發(fā)或者幫助。

背景

美團App每天都面臨著各類的欺詐、盜號、作弊、套現(xiàn)以及營銷活動被惡意刷單、惡意搶占資源等風險。而業(yè)務安全團隊采用的主要措施和手段就是在業(yè)務請求中識別出誰、在什么時間、通過什么方式、做了什么事。這個識別邏輯的制定過程叫做策略的生產(chǎn)。同時，還要對已經(jīng)完成生產(chǎn)的策略進行快速的驗證和落地，以防止風險變化后策略失效。從發(fā)現(xiàn)風險經(jīng)過策略生產(chǎn)、驗證，再到最終的落地部署，全流程的處理速度和效果將決定整個業(yè)務的成敗。

在業(yè)務發(fā)展初期，我們可以通過硬編碼的方式將風控邏輯部署在業(yè)務邏輯中實現(xiàn)，但美團的業(yè)務比較復雜，從最初的團購形式，經(jīng)過與大眾點評、摩拜、貓眼等業(yè)務的融合，發(fā)展到涵蓋餐飲、到店、貓眼、外賣、金融、酒店、旅游、大交通等多個垂直領域。隨著業(yè)務的快速發(fā)展，適用于初期的硬編碼方式出現(xiàn)了策略分散無法管理、邏輯同業(yè)務強耦合、策略更新迭代率受限于開發(fā)、對接成本高等多種問題。此時，我們需要有一套可配置化的規(guī)則管理平臺，進而實現(xiàn)風控策略與業(yè)務解耦、快速部署、驗證。

但規(guī)則引擎的建設初期，會面臨著各種困難和挑戰(zhàn)，主要包括以下幾個方面：

• 在業(yè)務層面：垂直領域多，包含幾乎所有的吃喝玩樂服務。美團細分業(yè)務多達百個。服務用戶角色多（用戶、商戶、供應商、渠道商），交易頻率高，日訂單量大。
• 在風險層面：存在用戶作弊、商家刷單、賬號盜用冒用、支付和信貸等多種風險。
• 在企業(yè)外部環(huán)境層面：黑產(chǎn)已形成自下而上的產(chǎn)業(yè)鏈，攻擊方式升級比較快速。

針對以上這些挑戰(zhàn)，我們打造了自有的規(guī)則引擎 Zeus（中文“宙斯”，來源于“宙斯盾”作戰(zhàn)系統(tǒng)的啟發(fā)，期望規(guī)則引擎平臺能同“宙斯盾”一樣成為先進的中央作戰(zhàn)決策系統(tǒng)，實現(xiàn)對風險的精準、高效打擊）。

下面，我們就來具體介紹一下，美團信息安全團隊在系統(tǒng)構建過程中面臨的挑戰(zhàn)以及對應的解決方案。

挑戰(zhàn)與方案

1. 業(yè)務多-接入成本高

規(guī)則引擎最早只是業(yè)務系統(tǒng)中的一個函數(shù)，逐步演化成了獨立的服務。而這個獨立服務與業(yè)務后臺的交互是單點方式，即業(yè)務后臺在關鍵動作節(jié)點前調(diào)用規(guī)則引擎，判斷“有沒有風險”。但這樣每次新增加一個業(yè)務或新出現(xiàn)一個風險場景時，規(guī)則引擎和業(yè)務都要重新進行對接聯(lián)調(diào)。頻繁地調(diào)整給上下游團隊都帶來了不小的負擔，而且在頻繁的更改中，系統(tǒng)質(zhì)量也難以保證。如何便捷、快速地實現(xiàn)業(yè)務接入是系統(tǒng)設計的核心目標之一。

在接入成本上，一次性集中接入往往是最便捷的方式。因此我們選擇在每個業(yè)務都會通用節(jié)點接入規(guī)則引擎，例如：用戶中心、商戶中心、訂單中心、收銀臺等均為各類業(yè)務的通用節(jié)點，規(guī)則引擎同這些通用節(jié)點對接，業(yè)務在調(diào)用通用節(jié)點時，通用節(jié)點調(diào)用規(guī)則引擎即可完成業(yè)務的接入。

隨著美團業(yè)務和場景種類的增多，現(xiàn)在也存在不經(jīng)過通用節(jié)點的業(yè)務。因此，我們需要提供通用的接入接口，目前業(yè)務側(cè)直接調(diào)用一個獨立服務接口即可獲得風控判斷。

2. 風險點多-邏輯復雜、邏輯復用

風險點多且業(yè)務多，進一步增加了場景、策略邏輯的復雜度。表達式語言可支持的邏輯計算范圍有限，復雜的邏輯若仍通過硬編碼實現(xiàn)，會存在效率低、不易復用等問題。

受模塊化思維啟發(fā)，我們將復雜的邏輯封裝成模版，實現(xiàn)配置化，并支持邏輯復用。這樣就大大提升了規(guī)則引擎可實現(xiàn)的邏輯范圍。目前，我們已經(jīng)建設的幾類常用的封裝邏輯如下：

擴展函數(shù)：主要用于數(shù)據(jù)格式的提取和處理，比如字符串、數(shù)組等格式轉(zhuǎn)換、數(shù)據(jù)提取等。通過擴展函數(shù)功能，對業(yè)務側(cè)數(shù)據(jù)格式要求大大降低，也降低了業(yè)務側(cè)數(shù)據(jù)處理的負擔。

累計因子：在業(yè)務中會高頻使用到與累計相關的邏輯。例如，在登陸、下單、支付等事件需要同IP的UserID進行計數(shù)計算，計算結果作為特征引用在規(guī)則中。規(guī)則引擎引入了內(nèi)部研發(fā)的高效事件計數(shù)服務，實現(xiàn)累計通用邏輯的封裝，比如支持累計周期、計數(shù)/求和/最近幾次、累計值等計算邏輯配置化等等。

決策表因子：部分業(yè)務中需要引擎處理的判斷條件較多，各條件又相互組合，存在多種決策方案的情況，這就需要用精確、簡潔的方式來描述這類復雜邏輯。在低頻使用時，我們可以通過硬編碼的case-when、if-else等語句實現(xiàn)，但在實時性和配置化上不盡人意。最終，我們通過決策表將多個獨立的條件和多個動作直接地聯(lián)系、清晰地表示出來，并實現(xiàn)了邏輯的封裝。

名單庫因子：與名單庫聯(lián)動過程中，將查詢名單的邏輯進行封裝。

工具因子：將一堆規(guī)則進行打包形成大的邏輯集合，并對組成的規(guī)則設置評分。在執(zhí)行時輸出評分結果并實現(xiàn)跨場景、跨業(yè)務應用，同時將大邏輯進行“黑盒”處理，簡化邏輯復用時的配置、溝通成本。

風險點多的另一個挑戰(zhàn)點是在多業(yè)務中會存在同質(zhì)性，即制定的風險策略是可復用的。當一百條規(guī)則需要復用在幾十個場景中，逐個配置的效率太低，不僅一致性難以保障，后續(xù)的修改也是問題。同時又衍變出部分復用、部分差異化，讓業(yè)務直接復用場景行不通。因此，我們引入【規(guī)則組】的概念，將規(guī)則聚類管理。比如眾包識別規(guī)則組、虛假設備規(guī)則組、涉黃內(nèi)容識別規(guī)則組等。業(yè)務在應用時，可在自己的場景中進行差異化的應用。

3. 風險變化快、長期對抗-效果驗證速度

當外部風險變化時，風控的對抗也需要及時響應，這是一個爭奪“主導權”的比賽。風控通過對不同階段的組合打擊，實現(xiàn)策略的健壯性，包括用于識別有沒有風險的基礎對抗階段、引導節(jié)奏混淆視聽的“短平快”階段、誘敵深入的“高精尖”階段。對應系統(tǒng)需要支持不同階段的策略配置、迭代和驗證需求。而在策略迭代和部署階段，需要特別注意因配置錯誤導致的誤命中問題。

參考開發(fā)環(huán)境分類：測試環(huán)境、預發(fā)布環(huán)境和生產(chǎn)環(huán)境。規(guī)則引擎在規(guī)則的部署和迭代上，可通過標記、雙跑和回溯功能，我們通過應用實時線上流量和歷史數(shù)據(jù)來驗證策略的有效性。

• 標記：規(guī)則在場景中的狀態(tài)，標記狀態(tài)的規(guī)則邏輯將灰度執(zhí)行，即：與生效規(guī)則類似會實時執(zhí)行，但決策信息不實時返回給上游業(yè)務方，不影響決策。同時用戶可在實時日志查詢中查看標記規(guī)則的命中情況。
• 雙跑：規(guī)則在場景中的狀態(tài)，雙跑狀態(tài)的規(guī)則邏輯將灰度執(zhí)行，但僅會出現(xiàn)在修改生效規(guī)則、因子（因子修改導致引用規(guī)則的邏輯執(zhí)行變化）時，才會存在的狀態(tài)。
• 回溯：規(guī)則在場景中的狀態(tài)，回溯狀態(tài)的規(guī)則邏輯將灰度執(zhí)行，但僅使用回放的歷史數(shù)據(jù)。

通過這些功能，可以降低策略迭代的風險，縮短策略部署上線的時間周期。

思路總結

在確認清楚挑戰(zhàn)和解決方案之后，規(guī)則引擎的整體建設思路就已經(jīng)形成了。現(xiàn)今，規(guī)則引擎隨著業(yè)務的快速擴張，由一個內(nèi)部系統(tǒng)逐漸發(fā)展為服務多個風控團隊的公共平臺。

從初期主要圍繞風控防控痛點進行搭建的表達式服務包，升級到配置化平臺，在配置效率和執(zhí)行效率也得到了很大的提升。同時，隨著人工智能技術的應用和風控對抗進入白熱化，規(guī)則引擎也將從配置化快速迭代至自動化、智能化。

1. 確定核心快速論證、快速落地

在系統(tǒng)建設中，進行了充分的論證后就需要快速落地，避免因長項目周期需求發(fā)生裂變而導致不可控。在初期，我們已經(jīng)建立了aviator表達式服務包并穩(wěn)定服務。因此，配置化平臺搭建時仍基于表達式語言，引入場景、規(guī)則、因子、決策等概念搭建，將策略的執(zhí)行分為執(zhí)行層和計算層。

執(zhí)行層：通過場景獲得一堆規(guī)則集合，規(guī)則執(zhí)行完成后將其結果和對應的決策返回。

結果和：在規(guī)則執(zhí)行時會進行其構成因子計算。

2. 根據(jù)角色，進行定向提效

規(guī)則引擎搭建的初衷之一是提升風控對抗的整體效率。在對抗過程中，我們需要各種角色配合，例如開發(fā)建設系統(tǒng)、策略制定者、策略使用者和風險用戶等，因此需要針對各類角色定向開展提效工作。

（1）風險用戶處理提效（風險用戶）

業(yè)務已經(jīng)可以實時獲得風控的決策，但發(fā)現(xiàn)風險用戶會在很多場景下重復攻擊。對這類用戶的處理，除了對當次行為阻斷，還要阻斷其未來的行為，因此就有名單管理的訴求。我們通過與名單庫的聯(lián)動，提升該類用戶的處理效率。

例如：在美團金融項目場景下，嚴重逾期的用戶會加入禁貸名單，再次申貸時取消其貸款資格。

（2）業(yè)務接入提效（業(yè)務方）

除了上面介紹的統(tǒng)一接入外，還有一種常見的情況：業(yè)務無法在發(fā)起請求時就將執(zhí)行所需要的全部參數(shù)準備好，此時就需要引擎能主動獲取外部數(shù)據(jù)。針對這類情況，規(guī)則引擎通過數(shù)據(jù)接口的方式實現(xiàn)了外部數(shù)據(jù)的補充，在策略執(zhí)行時根據(jù)計算需要動態(tài)獲取相關的參數(shù)。在實現(xiàn)與外部數(shù)據(jù)聯(lián)動的功能后，大大降低了使用規(guī)則引擎業(yè)務方數(shù)據(jù)準備階段的壓力，從全部參數(shù)準備簡化為僅提供核心參數(shù)即可，剩余參數(shù)按需引擎自行調(diào)度即可。

（3）策略管理提效（產(chǎn)品）

策略產(chǎn)品是規(guī)則引擎的主要用戶，主要的工作流程是圍繞策略管理、分析、驗證進行提效。如何管理大量的規(guī)則和應用場景？怎樣快速驗證策略有效性、評估誤傷率？客訴反饋問題，如何快速還原規(guī)則命中情況？針對這些維度，我們分別提供不同的產(chǎn)品功能進行提效。

• 在策略管理層面，可通過規(guī)則組方式、因子工具等，進行同類規(guī)則集合的管理、打包和復用。
• 在規(guī)則分析層面，可通過實時查詢規(guī)則的執(zhí)行詳細數(shù)據(jù)和將規(guī)則執(zhí)行流程進行回放提升分析效率。
• 在策略驗證層面，提供標記、雙跑和回溯提升策略驗證速度。

（4）工程效率提效（工程師）

復雜的邏輯且具有通用性就可以對特征邏輯封裝，避免工程師重復進行邏輯開發(fā)工作，釋放出的開發(fā)資源可以進行其它維度的提效。

（5）算法/模型接入提效（算法工程師）

當對抗升級時，策略的產(chǎn)生者由人變?yōu)樗惴?模型。而機器的生產(chǎn)效率遠遠高于人，人工搬運算法/模型會成為迭代效率的瓶頸，怎樣跟算法、模型平臺進行快速聯(lián)動呢？最簡單、快速的方式就是使用引擎提供的外部數(shù)據(jù)聯(lián)動方式，將模型結果包裝成數(shù)據(jù)接口使用。但在實踐過程中，我們發(fā)現(xiàn)模型的出入?yún)?shù)較多且存在變化，整體的配置化效率低，模型應用和迭代頻率受限制。公司內(nèi)部提供的深度學習還是算法工程平臺，目前主攻計算、訓練等場景，在上下游應用提供標準化的數(shù)據(jù)產(chǎn)出，但無法同類似引擎的平臺對接。

因此，僅聚焦在引擎與算法平臺的聯(lián)動上，可通過建設調(diào)度模塊實現(xiàn)：1.訓練樣本預處理–>2.算法平臺對接–>3.自動化生成接口–>4.自動注冊接口/策略至引擎–>5.評估任務啟動–>6.評估結果處理（策略上下線、樣本數(shù)據(jù)沉淀）–>1.訓練樣本預處理的閉環(huán)流程。

3. 發(fā)現(xiàn)問題、橫向擴展、兼容更多場景

隨著引擎在多業(yè)務場景的應用，我們發(fā)現(xiàn)幾個實時引擎不好處理的場景。比如拉新場景，需要結合“注冊+登陸+交易”等多種行為來判斷是否有“薅羊毛”等黑灰產(chǎn)行為，需要將很多事件放到一起去綜合判定。當發(fā)現(xiàn)風險時，或在當前時間點漏過的變異風險在發(fā)現(xiàn)之后，需要對歷史數(shù)據(jù)進行回撈，這些在實時引擎中都不太好實現(xiàn)。當前已有的異步引擎也無法很好地進行覆蓋。為了避免做“重復造輪子”的事情，團隊充分地討論了實時、異步和離線引擎的定位和服務邊界。

在實時引擎已經(jīng)覆蓋的邏輯基礎上，我們引入新的封裝邏輯-個體因子，全局因子實現(xiàn)SQL語句的配置化管理，進而實現(xiàn)批量累計、聚合特征的計算，比如：近一年某商家的平均下單金額，近30天商戶大盤下單均值，標準差等批數(shù)據(jù)的復雜邏輯。并基于Spark和實時引擎底層，實現(xiàn)多流和批數(shù)據(jù)的處理，解決上述場景無法處理的一些問題。

4. 業(yè)務實踐結果

交易安全

策略產(chǎn)品在日常工作中，通過對業(yè)務分析發(fā)現(xiàn)風險、挖掘風險特征并應用在策略中。通過Zeus實現(xiàn)策略的部署和應用，大大降低了業(yè)務風險，提升風險防控效率。例如：在某業(yè)務地推場景中發(fā)現(xiàn)B、C端聯(lián)合刷單風險，以返利、送贈品收到誘騙下單。

金融安全

金融風控主要有反欺詐和信用安全。反欺詐同業(yè)務安全在策略形態(tài)上相同，都是判斷有無風險，在決策結果上是通過和拒絕。因此，通過普通決策即可滿足業(yè)務需求。

但信用安全會比前兩者復雜一些，在決策上，除了通過和拒絕外，對于通過的請求要進行分層實現(xiàn)金融的差異化定價。因此，需要在規(guī)則引擎中引入更多功能，來滿足業(yè)務需求。主要包括：

• 路由場景：可支持多層，決策流模式，即一堆規(guī)則的集合，支持按照邏輯進行分流，滿足指定條件可以指定走向在每個節(jié)點進行條件設置，實現(xiàn)最終流向。例如：對于某分期場景用戶申請一筆貸款，需要經(jīng)過欺詐識別、信用評估后方可給出最終的額度、定價。
• 決策衍生參數(shù)：適用于復雜的多級路由決策場景Key-Value型數(shù)據(jù)，在決策中指定衍生參數(shù)信息從而在路由場景中產(chǎn)生全局傳遞變量，比如：流轉(zhuǎn)過不同的場景需要將用戶進行等級分類。
• 決策附加信息：適用于復雜決策場景Key-Value型數(shù)據(jù)，在決策中指定附加信息從而實現(xiàn)更多決策信息的計算及返回，比如：加入風控名單庫，加入什么風險類型、風險等級、名單類型。

未來發(fā)展與思考

目前規(guī)則引擎正處于配置化階段，正在向自動化、智能化的階段發(fā)展，從而不斷提升策略的管理和迭代的速度。但業(yè)務間的智能化訴求和進程不同，平臺可以提供更多集成托管服務，從而提升各業(yè)務的智能化覆蓋度。

其次，引擎仍然存在無法處理的幾個問題：

一些長時間周期特征無法快速應用的問題，例如近一年的時間周期。如何將離線引擎和實時引擎在特征計算上組合，實現(xiàn)特征的快速生產(chǎn)、驗證和應用，從而擴展引擎的計算能力范圍、提升風控業(yè)務的對抗效率。

當前引擎的接入對非復雜邏輯需求的業(yè)務就比較重。而接入成本是各業(yè)務接入時重點評估的因素，如何實現(xiàn)快速、低成本的業(yè)務接入（包括技術接入和人員操作接入），考慮提供模塊化的引擎計算服務能力適用于各類業(yè)務訴求，實現(xiàn)按需接入，比較“臃腫”的全局接入會更快速和便捷。但這種在引擎?zhèn)仍鯓痈玫毓芾磉@些模塊，也是一個挑戰(zhàn)。

最后，業(yè)務流量和策略的增長速度仍在高速增長，引擎的穩(wěn)定性和策略管理效率也需要持續(xù)提升。

踩過的坑

1. 如何實現(xiàn)產(chǎn)品功能高聚合架構上低耦合

規(guī)則引擎建設時兼容各類業(yè)務場景，具備了極高的靈活性，同時自身也相對復雜。從頂層的路由場景到底層的參數(shù)（路由場景-場景-規(guī)則組-規(guī)則-決策-因子-參數(shù)-數(shù)據(jù)接口-參數(shù)）每一個節(jié)點、節(jié)點間都是由用戶配置的，在產(chǎn)品上期望用戶的操作流程是連貫的，在一個操作流程中解決盡量多的問題。系統(tǒng)架構上，包括配置層、執(zhí)行層、計算層、數(shù)據(jù)獲取層等，各層之間相互依賴，對最終引擎的輸出結果負責，底層上需要盡量的解耦合，才將降低單模塊對引擎的影響。但在實踐中，隨著業(yè)務訴求的增多，慢慢就出現(xiàn)來產(chǎn)品上的低耦合、架構上的高耦合情況。

例如：在用戶修改生產(chǎn)策略時的強制更新流程優(yōu)化項目中 ，就涉及了這個問題。在產(chǎn)品功能上用戶修改策略–>雙版本策略并行執(zhí)行–>兩版本數(shù)據(jù)核驗–>修改完成；但在系統(tǒng)架構上，上述的產(chǎn)品流程就產(chǎn)生了系統(tǒng)架構高耦合，即生產(chǎn)修改雙版本問題，配置層、執(zhí)行層、計算層高度耦合。項目一期上線后在性能上、后續(xù)功能擴展性上都有瓶頸。隨后，技術項目優(yōu)化配置層的緩存模式，采用增量更新方式。產(chǎn)品功能上增加用戶進入修改模式后修改。重新立項后，實現(xiàn)了用戶修改流程閉環(huán)、系統(tǒng)架構上僅配置層兼容雙版本，執(zhí)行層和計算層無耦合。

因此，在產(chǎn)品功能設計上除了用戶閉環(huán)操作外，還需要考慮是否低耦合。在技術優(yōu)化時需要前瞻性的開展去耦合項目。

2. 如何平衡系統(tǒng)復雜度與業(yè)務需求

隨著接入業(yè)務的增多，又需要兼容新業(yè)務定制化需求，就面臨這一個問題：定制化的功能不具有通用性，大量定制功能將加重平臺的復雜度。這個問題一直困擾引擎建設團。，目前，我們采用的也許不是最優(yōu)但比較有效的辦法。主要通過定、判、看Gap，將業(yè)務需求轉(zhuǎn)化為系統(tǒng)模塊升級功能和非系統(tǒng)功能：

• 功：重新定義“定制和通用”。在現(xiàn)實中有些定制化需求其實是業(yè)務速度已經(jīng)遠遠領先于其它業(yè)務，所有需求看上去是定制化，實際上是未來可預見性的問題。
• 未：將業(yè)務需求進行分類，判斷需求是針對主干流程還是分支節(jié)點。
• 看Gap：需求同當前建設情況比對差距。

對于系統(tǒng)模塊升級功能，可逐個完成。對于非系統(tǒng)功能，可通過提供公共對接服務的外掛來實現(xiàn)。

3. 特別需要“防呆”設計

人工操作會存在各類誤操作引起的風險問題，在產(chǎn)品設計上，用戶操作簡潔的初衷是好的，但需要增加防止錯誤發(fā)生的限制方法。在實踐中這些“防呆”設置大大降低了人工誤操作Case，例如：

• 業(yè)務高峰期封版—>禁止業(yè)務高峰期時變更策略。
• 降低無邏輯驗證的誤傷情況–>策略上線前，強制標記驗證執(zhí)行是否符合業(yè)務預期；修改生產(chǎn)上應用的策略，強制雙跑驗證修改后的邏輯執(zhí)行是否符合業(yè)務預期。
• 降低邏輯配置錯誤幾率–>策略部署時強制測試邏輯正確性。
• 慣性操作–>驗證數(shù)據(jù)結果強制回填等。

4. 產(chǎn)品功能最佳實踐的意外驚喜

要承認一個事實就是，最了解功能使用的可能不是規(guī)則引擎的產(chǎn)品經(jīng)理。在規(guī)則引擎的建設中出現(xiàn)了這樣的”驚喜”，例如：

規(guī)則組功能建設初期目標是實現(xiàn)規(guī)則的高效管理、復用。在A業(yè)務場景基于規(guī)則組除實現(xiàn)規(guī)則的高效管理、復用外，還實現(xiàn)了決策計算。但這種用法在隨著其業(yè)務的發(fā)展復雜度增加，已經(jīng)不再利于策略高效管理，目前還在尋找更優(yōu)的解決方案。

累計因子的功能是將對多條請求進行計數(shù)或求和邏輯進行封裝。B業(yè)務基于上述功能上還是實現(xiàn)了事件行為記錄、多事件時序性累計和攔截行為的累計。目前在其業(yè)務下廣泛使用并有效地識別了跨事件風險。

總結而言，做好業(yè)務定期應用回訪和應用監(jiān)控是非常有必要的。

招聘信息

美團信息安全部正在招聘實習生，業(yè)務方向包括：安全\后端開發(fā)\機器學習算法\自然語言處理\風控策略\數(shù)據(jù)開發(fā)\Web前端\測試開發(fā)\產(chǎn)品經(jīng)理\產(chǎn)品運營\安全與隱私合規(guī)等。工作地點：北京/上海。歡迎感興趣的同學發(fā)送簡歷至：tech@meituan.com（郵件標題注明：美團信息安全團隊）

總結

以上是生活随笔為你收集整理的复杂风控场景下，如何打造一款高效的规则引擎的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。