AWS Lambda - A BIG THING

各位週末好，今天先不說docker了，說說一些其餘的東西。最近圖表君的項目上普遍的用到了AWS Lambda。之前沒以爲Lambda怎麼樣，最近由於項目上的需求深刻的看了下，AWS Lambda多是個Big Thing。

什麼是AWS Lambda

好了，第一個問題來了，什麼是AWS Lambda。AWS Lambda是2014年末AWS推出的一個全新的服務。用戶能夠簡單講本身的code部署到AWS Lambda上，那麼這個Lambda能夠由其餘的事件來trigger。這些事件的來源能夠是AWS S3上一個文件變化，能夠是Dynamo Table的一個數據update，能夠是一個SNS的Message。Lambda的出現讓用戶在使用AWS上其餘雲服務的時候擴展性更高。

Lambda 能解決什麼問題

好了上邊的講法有些抽象，那麼Lambda到底能解決什麼問題呢？OK，下邊就是一個例子咱們來看看Lambda到底能解決什麼問題。

假定如今有這樣一個場景，有一個外邊的數據源，天天會定時的往S3（AWS的文件存儲）放一些新的數據，而後咱們本身的Service來處理這些數據。這樣的場景相信是咱們現實工做中的典型場景。那麼應該怎麼來設計咱們的構架呢？

---

External DataSource --> S3 <--- Our Service

---

簡單來講，咱們可使這樣來作，咱們本身寫一個Service部署在一個 Instance上，這個Service不斷的去監控S3當發現有數據更新的時候，將其取出來，而後作相應的處理。這樣的方式是至關天然的。那麼這麼作有什麼問題呢？

1. 成本的問題。有可能咱們數據源天天的更新次數不多（假設3次），可是更新時間是不固定的。並且每一次的處理時間只有一分鐘。若是全天這個instance都是啓動的，那麼一天內有效的工做時間只有3分鐘，其餘的工做時間都是浪費的。

2. 維護成本。多一個Instance就多一套維護成本，系統部署，系統監控，log收集，同樣也少不了。

3. 代碼的複雜度。上邊的例子可能並不十分的合適，考慮下邊一個場景。

---

SNS ---> Our Service

---

有個SNS的消息服務，咱們的Service訂閱這個消息服務，當有消息的時候，咱們的Service會相應處理。那麼在實際中，咱們的Service可能會採用多線程的方式，並行處理這些消息以得到更快的處理效率。可是這樣同時會帶來代碼上覆雜度的提高。

那麼有了Lambda，能帶來什麼呢？第一例子中的構建設計就變成了下邊這樣：

---

External DataSource --> S3 ---> Lambda --> OtherService

---

S3上的任何文件變化都會trigger一個Lambda，這個Lambda就能夠進行相應的處理。這樣使得軟件構架變成了Event Trigger。那麼就能很好的解決咱們一個成本問題。若是天天只有3次文件更新，那麼就trigger3次Lambda處理就OK了。這樣會使得成本大大下降。一樣維護問題也交給了AWS來幫咱們處理。

再來看咱們的第二個例子，使用Lambda後的構建就變成了這樣：

---

SNS ---> Lambda --> OtherService

---

因爲Lambda 自帶的Auto Scaling的特性，開發者能夠基本不考慮併發的問題，當有多個message須要處理的時候，Lambda會本身來Auto Scaling來處理多個messages。

Lambda的出現讓開發者可以更快的專一本身的業務場景，而且減小運維上的壓力。Lambda的出現也使得Serverless的軟件構建漸漸的興起。

Lambda的侷限性

固然Lambda有必定侷限性，圖表君目前以爲可能影響最大的是 Maximum execution duration per request只有5分鐘，這樣Lambda處理一些複雜的業務場景時候就不太合適了。固然侷限也不止於此，具體你們能夠參考AWS的官方文檔。

將來

Lambda的出現已經快兩年了，圖表君以爲這可能又是一個能帶來大改變的東西。最近Amazon又推出了一個硬件產品叫AWS IOT button，是AWS在物聯網方案中的一個基礎產品。下邊這個圖一看你們就明白了：

咱們能夠看到Lambda是這裏關鍵一環。

AWS Lambda will be a big thing.

---

原創文章，歡迎轉發，但請標明出處。歡迎關注圖表君的公衆號，一塊兒成長。在微信中搜索 「多彩數據」 或者 「Data_Visualization」