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

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]。

而這個工業場景下的問題定義，具備標準化和通用性，其核心內容包含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的表達能力進行增強，同時將接入端計算能力，使得一些符合端測直接計算的業務場景，實時性獲得更高的提高。同時將結合算法能力，去挖掘潛在的業務價值。

參考資料：

1. https://arxiv.org/pdf/cs/0612128.pdf 【SASE: Complex Event Processing over Streams】
2. http://m.chinaaet.com/article/107902 【面向RFID的復瑣事件描述語言研究及應用】

阿里雲雙11億元補貼提早領，進入抽取iPhone 11 Pro：https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

---

本文做者：閒魚技術-絳曲

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。