最近半年來(lái)，隨著AWS的各線服務(wù)都開(kāi)始支持lambda，serverless architecture便漸漸成為一個(gè)火熱的話題。lambda是amzon推出的一個(gè)受控的運(yùn)行環(huán)境，起初僅僅支持nodejs(之后添加了java/python的支持)。你可以寫(xiě)一段nodejs的代碼，為其創(chuàng)建一個(gè)lambda資源，這樣，當(dāng)指定的事件來(lái)臨的時(shí)候，aws的運(yùn)行時(shí)會(huì)創(chuàng)建你的運(yùn)行環(huán)境，執(zhí)行你的代碼，執(zhí)行完畢(或者timeout)后，回收一切資源。這看起來(lái)并不稀罕，整個(gè)運(yùn)行環(huán)境還受到很多限制，比如目前aws為lambda提供了哪些事件支持，你就能用哪些事件，同時(shí)你的代碼無(wú)法超過(guò)timeout指定的時(shí)間執(zhí)行(目前***是5min)，內(nèi)存使用最多也就是1.5G。那么問(wèn)題來(lái)了，這樣一個(gè)看起來(lái)似乎有那么點(diǎn)雞肋的服務(wù)，為什么還受到如此熱捧?原因就在于無(wú)比低廉的價(jià)格(每百萬(wàn)次請(qǐng)求0.2美元 + 每百萬(wàn)GB秒運(yùn)行時(shí)間16.67美元)，毋須操心infrastructure，以及近乎***擴(kuò)容的能力。

使用lambda處理事件觸發(fā)

在服務(wù)器端，我們所寫(xiě)的大部分代碼是事件觸發(fā)的：

處理用戶對(duì)某個(gè)URI的請(qǐng)求(打開(kāi)某個(gè)頁(yè)面，點(diǎn)擊某個(gè)按鈕)

用戶注冊(cè)時(shí)發(fā)郵件驗(yàn)證郵箱地址

用戶上傳圖片時(shí)將圖片切割成合適的尺寸

當(dāng)log持續(xù)出現(xiàn)若干次500 internal error時(shí)將錯(cuò)誤日志聚合發(fā)給指定的郵箱

半夜12點(diǎn)，分析一天來(lái)收集的數(shù)據(jù)(比如clickstream)并生成報(bào)告

當(dāng)數(shù)據(jù)庫(kù)的某個(gè)字段修改時(shí)做些事后處理

同時(shí)，在處理一個(gè)事件的過(guò)程中，往往會(huì)觸發(fā)新的事件?；旧衔覀冏鲆粋€(gè)系統(tǒng)，如果能厘清內(nèi)部的數(shù)據(jù)流和事件流，以及對(duì)應(yīng)的行為，那么這個(gè)系統(tǒng)的架構(gòu)也就八九不離十了。如果要讓我們自己來(lái)設(shè)計(jì)一個(gè)分布式的事件處理系統(tǒng)，一般會(huì)使用Message Qeueue，比如RabbitMQ或者Kafka作為事件激發(fā)和事件處理的中樞。這往往意味著在現(xiàn)有的infrastructure之外至少添置事件處理的broker(MQ)和worker(讀取并處理事件的例程)。如果你用aws的服務(wù)，SQS(或者SNS+SQS)可以作為broker，然后配置若干臺(tái)EC2做worker。如果某個(gè)事件流的產(chǎn)生速度大大超過(guò)這個(gè)事件流的處理速度，那么我們還得考慮使用auto scaling group在queue的長(zhǎng)度超過(guò)一定閾值或者低于一定閾值時(shí)scale up / down。這不僅麻煩，也無(wú)法滿足某些要求一定訪問(wèn)延遲保障的場(chǎng)景，因?yàn)椋碌腅C2的啟動(dòng)直至在auto scaling group里被標(biāo)記為可用是數(shù)十秒級(jí)的動(dòng)作。

lambda就很好地彌補(bǔ)了這個(gè)問(wèn)題。lambda的執(zhí)行是置于container之中的，所以啟動(dòng)速度可以低至幾十到數(shù)百毫秒之間，而且它可以被已知的事件或者某段代碼觸發(fā)，所以基本上你可以在不同的上下文中直接調(diào)用或者觸發(fā)lambda函數(shù)，當(dāng)然也可以使用SNS(kenisis)+lambda取代原本用MQ+worker完成的工作。

我們看上述事件的處理：

處理用戶對(duì)某個(gè)URI的請(qǐng)求(打開(kāi)某個(gè)頁(yè)面，點(diǎn)擊某個(gè)按鈕)：使用API gateway + lambda

用戶注冊(cè)時(shí)發(fā)郵件驗(yàn)證郵箱地址：

可以在用戶注冊(cè)的流程里直接調(diào)用lambda函數(shù)發(fā)送郵件

如果使用dynamodb，可以配置lambda函數(shù)使其使用dynamodb stream在用戶數(shù)據(jù)寫(xiě)入數(shù)據(jù)時(shí)調(diào)用lambda

用戶上傳圖片時(shí)將圖片切割成合適的尺寸

可以配置lambda函數(shù)被S3的Object Create Event觸發(fā)，在lambda函數(shù)里使用libMagic的衍生庫(kù)處理圖片。

當(dāng)log持續(xù)出現(xiàn)若干次500 internal error時(shí)將錯(cuò)誤日志聚合發(fā)給指定的郵箱

如果用kenisis來(lái)收集log，那么可以配置lambda函數(shù)使其使用kenisis stream

半夜12點(diǎn)，分析一天來(lái)收集的數(shù)據(jù)(比如clickstream)并生成報(bào)告

使用aws***支持lambda cronjob

當(dāng)數(shù)據(jù)庫(kù)的某個(gè)字段修改時(shí)做些事后處理

如果使用dynamodb，同上(配置lambda函數(shù)使其使用dynamodb)

如果使用RDBMS，可以使用database trigger + lambda cronjob

想進(jìn)一步深入代碼的童鞋，可以看我的這個(gè)repo: https://github.com/tyrchen/aws-lambda-thumbnail 。它接收S3的Object Create Event，并對(duì)event中所述的圖片做resize，代碼使用es6完成。為了簡(jiǎn)便起見(jiàn)，沒(méi)有使用cloudformation創(chuàng)建/更新lambda function，而是使用了aws CLI(見(jiàn)makefile)。如果想要運(yùn)行此代碼，你需要定義自己的 $(LAMBDA_ROLE)，手工創(chuàng)建S3 bucket并將其和lambda函數(shù)關(guān)聯(lián)(目前aws cli不支持S3 event)。

使用lambda處理大數(shù)據(jù)

lambda近乎***擴(kuò)容的能力使得我們可以很輕松地進(jìn)行大容量數(shù)據(jù)的map/reduce。你可以使用一個(gè)lambda函數(shù)分派數(shù)據(jù)給另一個(gè)lambda函數(shù)，使其執(zhí)行成千上萬(wàn)個(gè)相同的實(shí)例。假設(shè)在你的S3里存放著過(guò)去一年間每小時(shí)一份的日志文件，為做security audit，你需要從中找出非正常訪問(wèn)的日志并聚合。如果使用lambda，你可以把訪問(wèn)高峰期(7am-11pm)每?jī)尚r(shí)的日志，或者訪問(wèn)低谷期每四小時(shí)的日志交給一個(gè)lambda函數(shù)處理，處理結(jié)果存入dynamodb。這樣會(huì)同時(shí)運(yùn)行近千個(gè)lambda函數(shù)(24 x 365 / 10)，在不到一分鐘的時(shí)間內(nèi)完成整個(gè)工作。同樣的事情交給EC2去做的話，單單為這些instance配置網(wǎng)絡(luò)就讓人頭疼：instance的數(shù)量可能已經(jīng)超出了子網(wǎng)中剩余IP地址的數(shù)量(比如，你的VPC使用了24位掩碼)。

同時(shí)，這樣一個(gè)量級(jí)的處理所需的花費(fèi)幾乎可以忽略不計(jì)。而EC2不足一小時(shí)按一小時(shí)計(jì)費(fèi)，上千臺(tái)t2.small運(yùn)行一小時(shí)的花費(fèi)約等于26美金，相當(dāng)可觀。

使用lambda帶來(lái)的架構(gòu)優(yōu)勢(shì)

如果說(shuō)lambda為事件處理和某些大容量數(shù)據(jù)的快速處理帶來(lái)了新的思路，并實(shí)實(shí)在在省下了在基礎(chǔ)設(shè)施和管理上的真金白銀，那么，其在架構(gòu)上也帶來(lái)了新的思路和優(yōu)勢(shì)。

web系統(tǒng)是天然離散的系統(tǒng)，里面涵蓋了眾多大大小小，或并聯(lián)，或串聯(lián)的子系統(tǒng)。因?yàn)榛A(chǔ)設(shè)施的成本問(wèn)題，很多時(shí)候我們做了邏輯上的分層和解耦，卻在物理上將其部署在一起，這為scalability和management都帶來(lái)了一些隱患。scalability上的隱患好理解，management上的隱患是指這無(wú)形把dev和ops分成不同的team：一個(gè)個(gè)dev team可以和邏輯上的子系統(tǒng)一一對(duì)應(yīng)，但ops卻要集中起來(lái)處理部署的問(wèn)題，免得一個(gè)邏輯上「解耦」的功能更新，在物理上卻影響了整個(gè)系統(tǒng)的正常運(yùn)行。這種混搭的管理架構(gòu)勢(shì)必會(huì)影響部署的速度和效率，和「一個(gè)team負(fù)責(zé)從功能開(kāi)發(fā)到上線所有的事情」的思路是相悖的。

舉個(gè)例子：「用戶上傳圖片時(shí)將圖片切割成合適的尺寸」這一需求可能在不斷變化和優(yōu)化。對(duì)于任何失焦的照片我們還希望做一些焦距上的優(yōu)化，此外，如果上傳的是頭像，那么我們希望切割的位置是最合適的頭像的位置，如果上傳的是照片，除了切割外，我們可能還要生成黑白/灰度等等不同主題的圖片。這個(gè)功能在不改變已有接口的前提下，并不會(huì)影響其他團(tuán)隊(duì)的工作，但因?yàn)楹推渌δ芊旁谝黄鸩渴穑圆渴鸬墓ぷ鞑⒉荒茏约赫f(shuō)了算。因?yàn)椴渴鸾挥蓪ｉT的ops團(tuán)隊(duì)完成(可能一天部署一次，也可能一周部署一次)，這個(gè)團(tuán)隊(duì)無(wú)法很快地把一些有意思的點(diǎn)子拿出來(lái)在生產(chǎn)環(huán)境試驗(yàn)，拖累了試錯(cuò)和創(chuàng)新。

而lambda解決了基礎(chǔ)設(shè)施上的問(wèn)題，每個(gè)子系統(tǒng)甚至子功能(小到函數(shù)級(jí)的粒度)都可以獨(dú)立部署，這就讓功能開(kāi)發(fā)無(wú)比輕松。只要界定好事件流的輸入輸出，任何事件處理的功能本身可以按照自己團(tuán)隊(duì)的節(jié)奏更新。

部署和管理上的改變反過(guò)來(lái)會(huì)影響架構(gòu)，促成以micro-service為主體的系統(tǒng)架構(gòu)。micro-service孰好孰壞目前尚有爭(zhēng)論，但micros-ervice不僅擁抱軟件設(shè)計(jì)上的解耦，同時(shí)擁抱軟件部署上的解耦是不爭(zhēng)的事實(shí)。一個(gè)web系統(tǒng)的成敗和其部署方案有著密切的關(guān)系，耦合度越低的部署方案，其局部部署更新的能力也就越強(qiáng)，而一個(gè)系統(tǒng)越大越復(fù)雜，就越不容易整體部署，所以對(duì)局部部署的要求也越來(lái)越高。這如同一個(gè)有機(jī)體，其自我更新從來(lái)不靠「死亡-重生」，而是通過(guò)新陳代謝。

此外，lambda還是一個(gè)充分受限的環(huán)境，給代碼的撰寫(xiě)帶來(lái)很多約束條件。我之前在談架構(gòu)的時(shí)候曾經(jīng)提到，約束條件是好事，設(shè)計(jì)軟件首先要搞明白約束條件。lambda***的幾個(gè)約束是：

lambda函數(shù)必須設(shè)計(jì)成無(wú)狀態(tài)的，因?yàn)槠渌袪顟B(tài)(內(nèi)存，磁盤)都會(huì)在其短短的生命周期結(jié)束后消失

lambda函數(shù)有***內(nèi)存限制

lambda函數(shù)有***運(yùn)行時(shí)間限制

這些限制要求你把每個(gè)lambda函數(shù)設(shè)計(jì)得盡可能簡(jiǎn)單，一次只做一件事，但把它做到***。很符合unix的哲學(xué)。反過(guò)來(lái)，這些限制強(qiáng)迫你接受極簡(jiǎn)主義之外，為你帶來(lái)了***擴(kuò)容的好處。

JAWS和server-less architecture

兩三個(gè)月前，我介紹了JAWS，當(dāng)時(shí)它是一個(gè)利用aws剛剛推出的API gateway和lambda配合，來(lái)提供REST API的工具，如果輔以架設(shè)在S3上的靜態(tài)資源，可以打造一個(gè)完全不依賴EC2的網(wǎng)站。這個(gè)項(xiàng)目從另一個(gè)角度詮釋了lambda的巨大威力，所以demo一出爐，就獲得了一兩千的github star。如今JAWS羽翼臻至豐滿，推出了尚處在beta的jaws fraemwork v1版本：https://github.com/jaws-framework/JAWS，并且在re:invent 2015上做了相當(dāng)精彩的主題演講(見(jiàn)github)。JAWS framework大量使用API gateway，cloudformation和lambda來(lái)提供serverless architecture，值得關(guān)注。

一個(gè)完整的serverless website可以這么考慮：

用戶注冊(cè)使用：API gateway，lambda，dynamodb，SES(發(fā)郵件)

用戶登錄使用：API gateway，lambda，或者(cognito和IAM，如果要集成第三方登錄)

用戶UGC各種內(nèi)容：API gateway，lambda，dynamodb

其他REST API：API gateway + lambda

各種事件處理使用lambda

所有的靜態(tài)資源放在S3上，使能static website hosting，然后通過(guò)javascript訪問(wèn)cognito或者REST API

日志存放在cloudWatch，并在需要的時(shí)候觸發(fā)lambda

clickstream存在在kenisis，并觸發(fā)lambda

如此這般，一個(gè)具備基本功能的serverless website就搭起來(lái)了。

如果你對(duì)JAWS感興趣，可以嘗試我生成的 https://github.com/tyrchen/jaws-test。

避免失控

lambda帶來(lái)的部署上的解耦同時(shí)是把雙刃劍。成千上萬(wàn)個(gè)功能各異的lambda函數(shù)(再加上各自不同的版本)，很容易把系統(tǒng)推向失控的邊緣。所以，***通過(guò)以下手段來(lái)避免失控：

為lambda函數(shù)合理命名：使用一定規(guī)格的，定義良好的前綴(可類比ARN)

使用cloudformation處理資源的分配和部署(可以考慮JAWS)

可視化系統(tǒng)的實(shí)時(shí)數(shù)據(jù)流/事件流(類似下圖)

(圖片來(lái)自youtube視頻截圖：A Day in the Life of a Netflix Engineer，圖片和本文關(guān)系不大，但思想類似)

由于基于lambda的諸多應(yīng)用場(chǎng)景還處在剛剛起步的階段，所以很多orchestration的事情還需要自己做，相信等lambda的使用日趨成熟時(shí)，就像docker生態(tài)圈一樣，會(huì)產(chǎn)生眾多的orchestration的工具，解決或者緩解系統(tǒng)失控的問(wèn)題。