碼農節快樂|一個系統，高效解決複雜事件採集-計算-實時觸達

PartI： 1024

今天是1024，一個特別的數字，比如某網站內容的解壓密碼通常都是1024，想求一個種子留言也是1024。1024是屬於廣大程式猿（又稱碼農）的節日，在這樣一個節日裡，各種“黑”程式猿的新老段子將紛紛出現在各大媒體網站。為什麼程式猿屬於經常被黑的一個群體？凌亂的髮型、黑框眼鏡、雙肩包、格子衫、牛仔褲、運動鞋、錢多話少是很多人眼中的程式猿形象。

程式猿經常被黑的原因，還因為他們喜歡自黑（對比下另一個工種，千萬不能當著XXX們的面，叫他們美工，一定要叫設計師），但程式猿真的是描述中的那樣嗎

除了錢多話少是對的，其他都不完全對，比如說我，穿的是一身國際名牌'優衣庫'，喝酒燙頭不抽菸，但我只是個二流的程式猿，在閒魚裡，頂級的程式猿是這個樣子的。

程式猿接的最多的需求：這是老闆的需求。程式猿程式碼上線的時間：明天上線。程式猿寫過的bug：怎麼會有bug。1024祝廣大程式猿節日快日，繼續加班寫bug！！！

Part II 這是一篇技術文章

閒魚作為一款閒置物品交易平臺，讓使用者的閒置物品再次得到價值流通，普惠每一位使用者。先看下面幾個業務場景：

場景1：在閒魚的一次活動中，使用者進入活動會場後，瀏覽了幾個不同的寶貝，就會獎勵一個包郵券。
場景2：使用者關注的使用者寶貝降價了，實時告知使用者該降價資訊。
場景3：在使用者搜尋租房後，並瀏覽N個租房資訊，則為其推送一套合適的房源。
場景4：雙十一會場活動，使用者進入會場，點選商品詳情，對其傳送優惠。

類似這樣的業務還有很多，如果每次都是case by case的去解決，不僅重複性建設，還非常的浪費人力。程式猿最大的優點就是懶，喜歡將看似不同的事務進行抽象，找出其共性，進行歸納和演繹，並透過設計一種架構，去解決該類似場景下的諸多業務，以減少重複性的勞作。
而架構的設計是有套路可以遵循的，然並卵，雖然瞭解了很多的架構原理、設計理念，但往往實際的操作過程中，很容易空對空，這裡給出一種設計架構的套路步驟：系統解決的問題定義->系統設計的目標->核心設計->各子系統模組的詳細設計。

系統解決的問題定義

問題的定義是從解決的業務場景出發的，也是最難的一步，如果問題定義的不明白，後面的系統設計很容易出現偏差，甚至各方理解不一，無法落地。上面的這些業務場景有哪些共性呢，用一句話可以描述為：“使用者的一系列操作，滿足一定的複雜規則條件後，對其實時的觸達相應的權益”。這裡有一個要求，需要“實時”，能夠秒級的觸達使用者。 因此係統解決的問題可以定義為：能夠處理複雜規則事件的實時觸達系統。

系統設計目標

有了對業務場景的問題定義，如何設計一個架構，去解決這個問題，在設計之初，老闆給了一些目標要求：

1. 技術與業務分離，構建技術元件和能力，組合後實現業務需求；
2. 事件的資料格式需要結構化和標準化，支援擴充套件；
3. 規則的表達定義類似SQL的申明式DSL，貼合業務領域；
4. 客戶端和服務端有各⾃的行動觸發能力，⽀持擴充套件開發；客戶端支援服務端驅動；
5. 觸發和計算分離，計算模式外掛化；

系統設計的目標是為了保證最終的實現和最初的想法不要出現太大的偏差，有一個衡量標準在，一是讓專案內的成員依據此目標進行設計，避免出現公說公有理、婆說婆有理的情況；二是專案的驗收可以依據這個目標去評判，有理可依。

核心內容設計

核心設計這一步很考驗基本功和技術視野的，需要綜合判斷、權衡取捨，依據設計目標選出一個當前的最優解。在系統的設計目標中，其中一條，就是要標準化，標準化最大的好處是可以統一不變的接入。網際網路是個發展只有不到30年的行業，但工業已經發展了幾百年，很多網際網路行業裡的問題，在工業裡已經有了標準化的定義。在蒐集技術方案資料中，對RFID（射頻識別）進行復雜事件的流處理的方案進入我們視野[參考1]。

RFID系統資訊體系結構

而這個工業場景下的問題定義，具有標準化和通用性，其核心內容包含3個模組：資料採集模組、複雜事件處理模組、結果觸發相應的時間模組。
這個設計正好符合我們的業務場景所需要解決的問題。結合我們自己的業務，我們將其定義為“日誌採集模組、複雜事件的實時處理(EPL)模組、結果觸達模組”，其核心的架構圖設計如下：

核心架構圖
這3大核心模組，都是透過非同步訊息進行通訊，目的是每個模組可以解耦，即可以進行獨立使用，又可以作為整體的能力提供。
透過日誌採集模組，進行日誌的採集和歸一，得到輸入的資料；而後進入EPL模組，進行規則定義和計算；最終的結果進入觸達模組，進行使用者的結果觸達。下面分別介紹這3個模組的詳細設計。

各子系統模組的詳細設計

1：日誌採集模組
閒魚的系統架構，入口應用多，而且還有是異構的（有java應用，dart應用，Fass應用）。我們做了一個攔截器，遮蔽這些應用的細節，作統一的攔截處理。 經過統一請求攔截層，將所有的請求日誌寫入到SLS中。如圖

但這些日誌的格式千變萬化，對下游的業務處理非常的不便，因此需要對原始的日誌資料進行清洗，清洗為統一的格式，同時這個清洗任務隨著原始資料的多變，需要支援可配置化。
我們使用blink實時的對原始資料進行清洗，同時在blink任務裡，嵌入一個UDTF，這個UDTF接入動態化配置平臺，支援對清洗任務的可配置化。經過blink清洗後的資料，格式歸一化為：

歸一化格式後的資料，透過rocketMQ和SLS往下游輸出。這裡提一下為何要透過兩種資料通道輸出：rocketMQ對於線上業務的接入非常方便； SLS對下游接blink任務實時計算併發度要快。

2：EPL引擎模組
EPL模組，在之前的這篇 《閒魚如何打造高效CEP系統及DSL程式語言》 已經對這個模組進行了詳細的講解(請戳  https://mp.weixin.qq.com/s/is1IlJdCyr-vup78rIoUIw)，這裡不再贅述。
這裡提一下我們設計此DSL的目的和目標。

1. 簡化該業務領域下的寫法。
2. 雲/端表達的統一。
3. 該寫法要作為blink的一層通用抽象表達。
4. 該DSL要儘量的符合行業內的規範。

最終的DSL實現方案，一個任務的編寫大約只需要5行，而如果使用blink程式碼實現，至少上百行。我們跟blink合作，推動該DSL作為blink一種上層業務的抽象表達，可以擴充套件blink的使用。同時DSL的設計並不是天馬行空的想出來的，而是根據1這兩篇論文進行的設計，儘量去符合業界的規範。
同時這裡的EPL引擎模板，除了雲端的計算，還包含了端測計算能力，後面會有針對這一塊內容的文章，敬請期待

3：結果觸達模組
結果觸達模組包含了對EPL計算結果的處理，支援可配置化，支援自定義，並提供了諸如“push、poplayer、openPage”等基礎觸達能力。後面會有一篇詳細的文章進行介紹，敬請期待。

應用效果

業務方接入，只需要3個步驟：1.配置需要獲取的日誌資料，2，使用DSL編寫任務規則。3.配置一條觸達能力。不需要一行程式碼的開發，只透過配置半天內就可以上線一個業務。
同時，從上游的資料採集->計算->結果觸達，整個鏈路的耗時只需要10s就可以完成。

總結和展望

我們用一個攔截器，解決諸多異構應用的日誌採集問題，然後使用可配置化的blink任務，對原始的日誌資料進行清洗，輸出標準化的格式資料。接著根據行業的規範，設計出自定義的DSL，以方便複雜規則任務的編寫，並和blink合作，無縫的接入blink實時計算平臺，進行任務的計算。計算出的結果，只需進行配置，就可以進行到端的push/poplayer/openPage觸達。
目前我們的這款技術產品，已經接入了十多個業務，線上執行穩定，接入的效率得到極大提升。
未來我們將進一步對DSL的表達能力進行加強，同時將接入端計算能力，使得一些符合端測直接計算的業務場景，實時性得到更高的提升。同時將結合演算法能力，去挖掘潛在的業務價值。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。