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的目的和目標。

簡化該業務領域下的寫法。

云/端表達的統一。

該寫法要作為blink的一層通用抽象表達。

該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的表達能力進行加強，同時將接入端計算能力，使得一些符合端測直接計算的業務場景，實時性得到更高的提升。同時將結合算法能力，去挖掘潛在的業務價值。

?

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

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

?

總結

以上是生活随笔為你收集整理的码农节快乐|一个系统，高效解决复杂事件采集-计算-实时触达的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。