原文：
消息驅動型應用
后臺數據處理服務是一個不同的例子。 你要寫一個需要快速響應UI請求的以用戶為中心的應用， 但是你又想捕捉發生的各種不同類型的活動。讓我們想一下在線廣告系統 - 當一個用戶點擊時你想要非常快速的把它們轉向到他們的目標廣告，但同時你也需要拿到點擊發生的數據以便于給廣告商充值。（這個例子可不是假設的 - 我在Intent Media的前團隊最近正在做這樣的設計。）
傳統上，架構可能看起來是這樣的。‘廣告服務器’同步地響應用戶 - 在這個例子中我們可不關心交互 - 而他也會用‘點擊處理器’向頻道發送一條異步處理消息以便于更新數據庫，例如去扣減廣告商的預算。
在Serverless的世界看起來是這樣的：
這里的架構跟我們之前那個例子有一點不同。我們將一個長存活周期的消費者應用替換成了廠家給我們提供的可以跑在事件驅動上下文中的FaaS函數。記住廠家同時提供MessageBroker和FaaS環境 - 這兩個系統緊密捆綁在一起。
FaaS環境也可以用啟動多個函數代碼副本的方式來處理并行的點擊 - 取決于我們如何寫原始的處理邏輯，這是一個我們需要考慮新概念。
拆解‘函數即服務’
我們已經說了很多FaaS的主意，但現在是時候深入講下它到底是什么意思了。我們可以先看一下Amazon Lambda產品的公開介紹 https://aws.amazon.com/lambda/。我加了一些注釋，會在下面講解。
AWS lambda可以讓你在不需要管服務器的情況下跑代碼。(1)… 用Lambda，你可以運行各種類型的應用或后臺服務(2) - 全都是0管理配置。只需要上傳你的代碼并讓Lambda來管讓你的代碼高可靠的運行(3)并伸縮(4)的事。你可以設置讓你的代碼被其他AWS服務(5)自動觸發或者直接從任何web或移動應用調用。
1.基本上FaaS就是運行后端代碼并不需要管理你自己服務器或你自己服務端應用的系統。第二個部分 - 服務端應用 - 是一個與像容器和PaaS（平臺即服務）這樣現代架構模式的關鍵不同。
如果我們回到之前點擊處理的例子，FaaS做的就是替換點擊處理服務器（可能是個物理服務器，），換成一些不需要實際服務器或者一直運行應用的東西。
2.FaaS可以不需要對某種框架或類庫做編碼。如果用語言和環境來實現FaaS函數功能的話一般就是常規的應用。例如AWS Lambda函數可以在Javascript，Python和任何JVM語言（Java, Clojure, Scala等）中被實現成‘一級類’。總之你的Lambda函數可以執行任何被任何綁定了其部署描述的進程，這樣你可以用任何語言最終編譯成一個Unix進程（參考后面的Apex）FaaS函數確實有明顯的架構限制，特別是當它遇到狀態和執行周期，這個我們后面會說。
讓我們再想一下我們的點擊處理例子 - 唯一需要更改并移動到FaaS的是‘主方法/啟動’代碼，這處需要刪除，并且這個會變成頂層消息處理器（’消息監聽借口’實現），但這只是對方法簽名的一點改變。其他所有的代碼（例如對數據庫寫數據的）在FaaS世界沒有什么不同。
3.既然我們沒有服務器程序要跑，部署跟傳統系統非常不同 - 我們上傳代碼到FaaS提供商并且讓它做其他所有事情。現在這基本上就是讓你上傳一個新的代碼定義（例如zip或JAR文件），并且調用一個合適的API來初始化更新。
4.水平擴展是完全自動的，由供應商管理彈性。如果你的系統需要并行處理100個請求，供應商會處理而你不需要任何額外配置。FaaS供應商用‘計算容器’短暫執行你的函數方法并且根據運行時需求來銷毀。
讓我們回到點擊處理。比如我們今天運氣很好，用戶像比平常點擊了10倍的廣告量。我們的點擊處理應用能處理嗎？比如我們是否對能一次能處理很多消息的場景進行編碼？甚至我們只用運行一個應用實例夠不夠？我們能否運行自動擴展運行多個處理程序或者我們需要手動更改配置嗎？在FaaS上你需要在寫行數方法時先考慮并行，但在這之后FaaS供應商會自動處理所有擴展伸縮需求。
5.FaaS的函數方法是由廠家定義的事件類型來觸發的。在亞馬遜AWS上這包括了S3（文件）更新，時間（計劃任務）和被發送到消息總線的消息（如Kinesis）。你的函數需要為你綁定的消息源提供特定的參數。在點擊處理器中我們假設我們使用了支持FaaS的消息分發者。如果我們需要換一個，那么需要連消息生產者也要改。
6.大多數廠商允許函數方法可以被進入的http請求觸發并作為響應，這很像一種API網關。（如AWS API Gateway, Webtask)。在我們寵物商店里作為‘搜索’和‘下單’的函數功能。
文章來自微信平臺「麥芽面包」
微信公眾號「darkjune_think」轉載請注明。
微信掃一掃關注公眾號。
文章列表
留言列表
