作者：閑魚技術-绛曲
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的表達能力進行加強，同時将接入端計算能力，使得一些符合端測直接計算的業務場景，實時性得到更高的提升。同時将結合算法能力，去挖掘潛在的業務價值。
參考資料：
- https://arxiv.org/pdf/cs/0612128.pdf 【SASE: Complex Event Processing over Streams】
- http://m.chinaaet.com/article/107902 【面向RFID的複雜事件描述語言研究及應用】