摘要：比如我們的指標(biāo)是最近分鐘的同一用戶的下單量，那么我們就需要實(shí)現(xiàn)一種類似的滑動(dòng)窗口算法，以便任何時(shí)候都能拿到最近分鐘的數(shù)據(jù)。

此文已由作者肖凡授權(quán)網(wǎng)易云社區(qū)發(fā)布。

歡迎訪問(wèn)網(wǎng)易云社區(qū)，了解更多網(wǎng)易技術(shù)產(chǎn)品運(yùn)營(yíng)經(jīng)驗(yàn)。

背景
考拉安全部技術(shù)這塊目前主要負(fù)責(zé)兩塊業(yè)務(wù)：一個(gè)是內(nèi)審，主要是通過(guò)敏感日志管理平臺(tái)搜集考拉所有后臺(tái)系統(tǒng)的操作日志，數(shù)據(jù)導(dǎo)入到es后，結(jié)合storm進(jìn)行實(shí)時(shí)計(jì)算，主要有行為查詢、數(shù)據(jù)監(jiān)控、事件追溯、風(fēng)險(xiǎn)大盤等功能；一個(gè)是業(yè)務(wù)風(fēng)控，主要是下單、支付、優(yōu)惠券、紅包、簽到等行為的風(fēng)險(xiǎn)控制，對(duì)抗的風(fēng)險(xiǎn)行為包括黃牛刷單、惡意占用庫(kù)存、機(jī)器領(lǐng)券、擼羊毛等。這兩塊業(yè)務(wù)其實(shí)有一個(gè)共通點(diǎn)，就是有大量需要進(jìn)行規(guī)則決策的場(chǎng)景，比如內(nèi)審中需要進(jìn)行實(shí)時(shí)監(jiān)控，當(dāng)同一個(gè)人在一天時(shí)間內(nèi)的導(dǎo)出操作超過(guò)多少次后進(jìn)行告警，當(dāng)?shù)卿洉r(shí)不是常用地登錄并且設(shè)備指紋不是該賬號(hào)使用過(guò)的設(shè)備指紋時(shí)告警。而在業(yè)務(wù)風(fēng)控中需要使用到規(guī)則決策的場(chǎng)景更多，由于涉及規(guī)則的保密性，這里就不展開了?？傊?，基于這個(gè)出發(fā)點(diǎn)，安全部決定開發(fā)出一個(gè)通用的規(guī)則引擎平臺(tái)，來(lái)滿足以上場(chǎng)景。

寫在前面
在給出整體架構(gòu)前，想跟大家聊聊關(guān)于架構(gòu)的一些想法。目前架構(gòu)上的分層設(shè)計(jì)思想已經(jīng)深入人心，大家都知道要分成controller,server,dao等，是因?yàn)槲覀儎偨佑|到編碼的時(shí)候，mvc的模型已經(jīng)大行其道，早期的jsp里面包含大量業(yè)務(wù)代碼邏輯的方式已經(jīng)基本絕跡。但是這并不是一種面向?qū)ο蟮乃伎挤绞?，而往往我們是以一種面向過(guò)程的思維去編程。舉個(gè)簡(jiǎn)單例子，我們要實(shí)現(xiàn)一個(gè)網(wǎng)銀賬戶之間轉(zhuǎn)賬的需求，往往會(huì)是下面這種實(shí)現(xiàn)方式：

設(shè)計(jì)一個(gè)賬戶交易服務(wù)接口AccountingService，設(shè)計(jì)一個(gè)服務(wù)方法transfer()，并提供一個(gè)具體實(shí)現(xiàn)類AccountingServiceImpl，所有賬戶交易業(yè)務(wù)的業(yè)務(wù)邏輯都置于該服務(wù)類中。

提供一個(gè)AccountInfo和一個(gè)Account，前者是一個(gè)用于與展示層交換賬戶數(shù)據(jù)的賬戶數(shù)據(jù)傳輸對(duì)象，后者是一個(gè)賬戶實(shí)體（相當(dāng)于一個(gè)EntityBean），這兩個(gè)對(duì)象都是普通的JavaBean，具有相關(guān)屬性和簡(jiǎn)單的get/set方法。

然后在transfer方法中，首先獲取A賬戶的余額，判斷是否大于轉(zhuǎn)賬的金額，如果大于則扣減A賬戶的余額，并增加對(duì)應(yīng)的金額到B賬戶。

這種設(shè)計(jì)在需求簡(jiǎn)單的情況下看上去沒(méi)啥問(wèn)題，但是當(dāng)需求變得復(fù)雜后，會(huì)導(dǎo)致代碼變得越來(lái)越難以維護(hù)，整個(gè)架構(gòu)也會(huì)變的腐爛。比如現(xiàn)在需要增加賬戶的信用等級(jí)，不同等級(jí)的賬戶每筆轉(zhuǎn)賬的最大金額不同，那么我們就需要在service里面加上這個(gè)邏輯。后來(lái)又需要記錄轉(zhuǎn)賬明細(xì)，我們又需要在service里面增加相應(yīng)的代碼邏輯。最后service代碼會(huì)由于需求的不斷變化變得越來(lái)越長(zhǎng)，最終變成別人眼中的“祖?zhèn)鞔a”。導(dǎo)致這個(gè)問(wèn)題的根源，我認(rèn)為就是我們使用的是一種面向過(guò)程的編程思想。那么如何去解決這種問(wèn)題呢？主要還是思維方式上需要改變，我們需要一種真正的面向?qū)ο蟮乃季S方式。比如一個(gè)“人”，除了有id、姓名、性別這些屬性外，還應(yīng)該有“走路”、“吃飯”等這些行為，這些行為是天然屬于“人”這個(gè)實(shí)體的，而我們定義的bean都是一種“失血模型”，只有g(shù)et/set等簡(jiǎn)單方法，所有的行為邏輯全部上升到了service層，這就導(dǎo)致了service層過(guò)于臃腫，并且很難復(fù)用已有的邏輯，最后形成了各個(gè)service之間錯(cuò)綜復(fù)雜的關(guān)聯(lián)關(guān)系，在做服務(wù)拆分的時(shí)候，很難劃清業(yè)務(wù)邊界，導(dǎo)致服務(wù)化進(jìn)程陷入泥潭。

對(duì)應(yīng)上面的問(wèn)題，我們可以在Account這個(gè)實(shí)體中加入本應(yīng)該就屬于這個(gè)實(shí)體的行為，比如借記、貸記、轉(zhuǎn)賬等。每一筆轉(zhuǎn)賬都對(duì)應(yīng)著一筆交易明細(xì)，我們根據(jù)交易明細(xì)可以計(jì)算出賬戶的余額，這個(gè)是一個(gè)潛在的業(yè)務(wù)規(guī)則，這種業(yè)務(wù)規(guī)則都需要交由實(shí)體本身來(lái)維護(hù)。另外新增賬戶信用實(shí)體，提供賬戶單筆轉(zhuǎn)賬的最大金額計(jì)算邏輯。這樣我們就把原本全部在service里面的邏輯劃入到不同的負(fù)責(zé)相關(guān)職責(zé)的“領(lǐng)域?qū)ο蟆碑?dāng)中了，service的邏輯變得非常清楚明了，想實(shí)現(xiàn)A給B轉(zhuǎn)賬，直接獲取A實(shí)體，然后調(diào)用A實(shí)體中的轉(zhuǎn)賬方法即可。service將不再關(guān)注轉(zhuǎn)賬的細(xì)節(jié)，只負(fù)責(zé)將相關(guān)的實(shí)體組織起來(lái)，完成復(fù)雜的業(yè)務(wù)邏輯處理。

上面的這種架構(gòu)設(shè)計(jì)方式，其實(shí)就是一種典型的“領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)”思想，在這里就不展開說(shuō)明了（主要是自己理解的還不夠深入，怕誤導(dǎo)大家了）。DDD也是目前非常熱門的一種架構(gòu)設(shè)計(jì)思想了，它不能減少你的代碼量，但是能使你的代碼具有很高的內(nèi)聚性，當(dāng)你的項(xiàng)目變得越來(lái)越復(fù)雜時(shí)，能保持架構(gòu)的穩(wěn)定而不至于過(guò)快的腐爛掉，不了解的同學(xué)可以查看相關(guān)資料。要說(shuō)明的是，沒(méi)有一種架構(gòu)設(shè)計(jì)是萬(wàn)能的、是能解決所有問(wèn)題的，我們需要做的是吸收好的架構(gòu)設(shè)計(jì)思維方式，真正架構(gòu)落地時(shí)還是需要根據(jù)實(shí)際情況選擇合適的架構(gòu)。

整體架構(gòu)設(shè)計(jì)
上面說(shuō)了些架構(gòu)設(shè)計(jì)方面的想法，現(xiàn)在我們回到規(guī)則引擎平臺(tái)本身。我們抽象出了四個(gè)分層，從上到下分別為：服務(wù)層、引擎層、計(jì)算層和存儲(chǔ)層，整個(gè)邏輯層架構(gòu)見(jiàn)下圖：

Alt pic

服務(wù)層：服務(wù)層主要是對(duì)外提供服務(wù)的入口層，提供的服務(wù)包括數(shù)據(jù)分析、風(fēng)險(xiǎn)檢測(cè)、業(yè)務(wù)決策等，所有的服務(wù)全部都是通過(guò)數(shù)據(jù)接入模塊接入數(shù)據(jù)，具體后面講

引擎層：引擎層是整個(gè)平臺(tái)的核心，主要包括了執(zhí)行規(guī)則的規(guī)則引擎、還原事件現(xiàn)場(chǎng)和聚合查詢分析的查詢引擎以及模型預(yù)測(cè)的模型引擎

計(jì)算層：計(jì)算層主要包括了指標(biāo)計(jì)算模塊和模型訓(xùn)練模塊。指標(biāo)會(huì)在規(guī)則引擎中配置規(guī)則時(shí)使用到，而模型訓(xùn)練則是為模型預(yù)測(cè)做準(zhǔn)備

存儲(chǔ)層：存儲(chǔ)層包括了指標(biāo)計(jì)算結(jié)果的存儲(chǔ)、事件信息詳情的存儲(chǔ)以及模型樣本、模型文件的存儲(chǔ)

在各個(gè)分層的邏輯架構(gòu)劃定后，我們就可以開始分析整個(gè)平臺(tái)的業(yè)務(wù)功能模塊。主要包括了事件接入模塊、指標(biāo)計(jì)算模塊、規(guī)則引擎模塊、運(yùn)營(yíng)中心模塊，整個(gè)業(yè)務(wù)架構(gòu)如下圖：

Alt pic

1.事件接入中心

事件接入中心主要包括事件接入模塊和數(shù)據(jù)管理模塊。數(shù)據(jù)接入模塊是整個(gè)規(guī)則引擎的數(shù)據(jù)流入口，所有的業(yè)務(wù)方都是通過(guò)這個(gè)模塊接入到平臺(tái)中來(lái)。提供了實(shí)時(shí)(dubbo)、準(zhǔn)實(shí)時(shí)（kafka）和離線（hive）三種數(shù)據(jù)接入方式。數(shù)據(jù)管理模塊主要是進(jìn)行事件的元數(shù)據(jù)管理、標(biāo)準(zhǔn)化接入數(shù)據(jù)、補(bǔ)全必要的字段，如下圖： Alt pic

2.指標(biāo)計(jì)算模塊

指標(biāo)計(jì)算模塊主要是進(jìn)行指標(biāo)計(jì)算。一個(gè)指標(biāo)由主維度、從維度、時(shí)間窗口等組成，其中主維度至少有一個(gè)，從維度最多有一個(gè)。如下圖： Alt pic

舉個(gè)例子，若有這樣一個(gè)指標(biāo)：“最近10分鐘，同一個(gè)賬號(hào)在同一個(gè)商家的下單金額”，那么主維度就是下單賬號(hào)+商家id，從維度就是訂單金額?？梢钥吹?，這里的主維度相當(dāng)于sql里面的group by，從維度相當(dāng)于count，數(shù)值累加相當(dāng)于sum。從關(guān)于指標(biāo)計(jì)算，有幾點(diǎn)說(shuō)明下：

key的構(gòu)成。我們的指標(biāo)存儲(chǔ)是用的redis，那么這里會(huì)涉及到一個(gè)key該如何構(gòu)建的問(wèn)題。我們目前的做法是：key=指標(biāo)id+版本號(hào)+主維度值+時(shí)間間隔序號(hào)。

指標(biāo)id就是指標(biāo)的唯一標(biāo)示；

版本號(hào)是指標(biāo)對(duì)象的版本，每次更新完指標(biāo)都會(huì)更新對(duì)應(yīng)的版本號(hào)，這樣可以讓就的指標(biāo)一次全部失效；

主維度值是指當(dāng)前事件對(duì)象中，主維度字段對(duì)應(yīng)的值，比如一個(gè)下單事件，主維度是用戶賬號(hào)，那么這里就是對(duì)應(yīng)的類似XXX@163.com，如果有多個(gè)主維度則需要全部組裝上去；

如果主維度的值出現(xiàn)中文，這樣直接拼接在key里面會(huì)有問(wèn)題，可以采用轉(zhuǎn)義或者md5的方式進(jìn)行。

時(shí)間間隔序號(hào)是指當(dāng)前時(shí)間減去指標(biāo)最后更新時(shí)間，得到的差值再除以采樣周期，得到一個(gè)序號(hào)。這么做主要是為了實(shí)現(xiàn)指標(biāo)的滑動(dòng)窗口計(jì)算，下面會(huì)講

滑動(dòng)窗口計(jì)算。比如我們的指標(biāo)是最近10分鐘的同一用戶的下單量，那么我們就需要實(shí)現(xiàn)一種類似的滑動(dòng)窗口算法，以便任何時(shí)候都能拿到“最近10分鐘”的數(shù)據(jù)。這里我們采用的是一種簡(jiǎn)單的算法：創(chuàng)建指標(biāo)時(shí)，指定好采樣次數(shù)。比如要獲取“最近10分鐘”的數(shù)據(jù)，采樣次數(shù)設(shè)置成30次，這樣我們會(huì)把每隔20秒的數(shù)據(jù)會(huì)放入一個(gè)key里面。每次一個(gè)下單事件過(guò)來(lái)時(shí)，計(jì)算出時(shí)間間隔序號(hào)（見(jiàn)第1點(diǎn)），然后組裝好key之后看該key是否存在，存在則進(jìn)行累計(jì)，否則往redis中添加該key。

如何批量獲取key。每次獲取指標(biāo)值時(shí)，我們都是先計(jì)算出需要的key集合（比如我要獲取“單個(gè)賬號(hào)最近10分鐘的下單量”，我可能需要獲取30個(gè)key，因?yàn)槊總€(gè)key的跨度是20s），然后獲取到對(duì)應(yīng)的value集合，再進(jìn)行累加。而實(shí)際上我們只是需要累加后的值，這里可以通過(guò)redis+lua腳本進(jìn)行優(yōu)化，腳本里面直接根據(jù)key集合獲取value后進(jìn)行累加然后返回給客戶端，這樣就較少了每次響應(yīng)的數(shù)據(jù)量。

如何保證指標(biāo)的計(jì)算結(jié)果不丟失？目前的指標(biāo)是存儲(chǔ)在redis里面的，后來(lái)會(huì)切到solo-ldb，ldb提供了持久化的存儲(chǔ)引擎，可以保證數(shù)據(jù)不丟失。

3.規(guī)則引擎模塊
計(jì)劃開始做規(guī)則引擎時(shí)進(jìn)行過(guò)調(diào)研，發(fā)現(xiàn)很多類似的平臺(tái)都會(huì)使用drools。而我們從一開始就放棄了drools而全部使用groovy腳本實(shí)現(xiàn)，主要是有以下幾點(diǎn)考慮：

drools相對(duì)來(lái)說(shuō)有點(diǎn)重，而且它的規(guī)則語(yǔ)言不管對(duì)于開發(fā)還是運(yùn)營(yíng)來(lái)說(shuō)都有學(xué)習(xí)成本

drools使用起來(lái)沒(méi)有g(shù)roovy腳本靈活。groovy可以和spring完美結(jié)合，并且可以自定義各種組件實(shí)現(xiàn)插件化開發(fā)。

當(dāng)規(guī)則集變得復(fù)雜起來(lái)時(shí)，使用drools管理起來(lái)有點(diǎn)力不從心。

當(dāng)然還有另外一種方式是將drools和groovy結(jié)合起來(lái)，綜合雙方的優(yōu)點(diǎn)，也是一種不錯(cuò)的選擇，大家可以嘗試一下。

規(guī)則引擎模塊是整個(gè)平臺(tái)的核心，我們將整個(gè)模塊分成了以下幾個(gè)部分： Alt pic

規(guī)則引擎在設(shè)計(jì)中也碰到了一些問(wèn)題，這里給大家分享下一些心得：

使用插件的方式加載各種組件到上下文中，極大的方便了功能開發(fā)的靈活性。

使用預(yù)加載的方式加載已有的規(guī)則，并將加載后的對(duì)象緩存起來(lái)，每次規(guī)則變更時(shí)重新load整條規(guī)則，極大的提升了引擎的執(zhí)行效率

計(jì)數(shù)器引入AtomicLongFieldUpdater工具類，來(lái)減少計(jì)數(shù)器的內(nèi)存消耗

靈活的上下文使用方式，方便定制規(guī)則執(zhí)行的流程（規(guī)則執(zhí)行順序、同步異步執(zhí)行、跳過(guò)某些規(guī)則、規(guī)則集短路等），靈活定義返回結(jié)果（可以返回整個(gè)上下文，可以返回每條規(guī)則的結(jié)果，也可以返回最后一條規(guī)則的結(jié)果），這些都可以通過(guò)設(shè)置上下文來(lái)實(shí)現(xiàn)。

groovy的方法查找策略，默認(rèn)是從metaClass里面查找，再?gòu)纳舷挛睦镎遥瑸榱颂嵘阅?，我們重寫了metaClass，修改了這個(gè)查詢邏輯：先從上下文里找，再?gòu)膍etaClass里面找。

規(guī)則配置如下圖所示：

Alt pic

未來(lái)規(guī)劃
后面規(guī)則引擎平臺(tái)主要會(huì)圍繞下面幾點(diǎn)來(lái)做：

指標(biāo)存儲(chǔ)計(jì)劃從redis切換到hbase。目前的指標(biāo)計(jì)算方式會(huì)導(dǎo)致緩存key的暴漲，獲取一個(gè)指標(biāo)值可能需要N個(gè)key來(lái)做累加，而換成hbase之后，一個(gè)指標(biāo)就只需要一條記錄來(lái)維護(hù)，使用hbase的列族來(lái)實(shí)現(xiàn)滑動(dòng)窗口的計(jì)算。

規(guī)則的灰度上線。當(dāng)一條新規(guī)則創(chuàng)建后，如果不進(jìn)行灰度的測(cè)試，直接上線是可能會(huì)帶來(lái)災(zāi)難的。后面再規(guī)則上線流程中新增灰度上線環(huán)節(jié)，整個(gè)引擎會(huì)根據(jù)配置的灰度比例，復(fù)制一定的流量到灰度規(guī)則中，并對(duì)灰度規(guī)則的效果進(jìn)行展示，達(dá)到預(yù)期效果并穩(wěn)定后才能審批上線。

事件接入的自動(dòng)化。dubbo這塊可以采用泛化調(diào)用，http接口需要統(tǒng)一調(diào)用標(biāo)準(zhǔn)，消息需要統(tǒng)一格式。有了統(tǒng)一的標(biāo)準(zhǔn)就可以實(shí)現(xiàn)事件自動(dòng)接入而不需要修改代碼上線，這樣也可以保證整個(gè)引擎的穩(wěn)定性。

模型生命周期管理。目前模型這塊都是通過(guò)在猛犸平臺(tái)上提交jar包的方式，離線跑一個(gè)model出來(lái)，沒(méi)有一個(gè)統(tǒng)一的平臺(tái)去管控整個(gè)模型的生命周期?，F(xiàn)在杭研已經(jīng)有類似的平臺(tái)了，后續(xù)需要考慮如何介入。

數(shù)據(jù)展示優(yōu)化?，F(xiàn)在整個(gè)平臺(tái)的數(shù)字化做的比較弱，沒(méi)法形成數(shù)據(jù)驅(qū)動(dòng)業(yè)務(wù)。而風(fēng)控的運(yùn)營(yíng)往往是需要大量的數(shù)據(jù)去驅(qū)動(dòng)規(guī)則的優(yōu)化的，比如規(guī)則閾值的調(diào)試、規(guī)則命中率、風(fēng)險(xiǎn)大盤等都需要大量數(shù)據(jù)的支撐。

網(wǎng)易云免費(fèi)體驗(yàn)館，0成本體驗(yàn)20+款云產(chǎn)品！

更多網(wǎng)易技術(shù)、產(chǎn)品、運(yùn)營(yíng)經(jīng)驗(yàn)分享請(qǐng)點(diǎn)擊。

文章來(lái)源： 網(wǎng)易云社區(qū)