隨著云計(jì)算技術(shù)的進(jìn)步，軟件系統(tǒng)的架構(gòu)方式也因此發(fā)生著一些變化，其中Serverless架構(gòu)就是這里的一個(gè)典型的例子。

[[192528]]

一、什么是Serverless架構(gòu)

目前關(guān)于Serverless架構(gòu)的準(zhǔn)確定義，業(yè)界并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。那么我們從字面上來(lái)分析，所謂Serverless架構(gòu)，翻譯過(guò)來(lái)也就是無(wú)服務(wù)器架構(gòu)。那么似乎可以涵蓋以下兩個(gè)方面：

1. BaaS(Backend as a Service)即后臺(tái)即服務(wù)。后臺(tái)即服務(wù)出現(xiàn)有很長(zhǎng)一段的時(shí)間了，例如Parse,Firebase都是典型的代表。具體來(lái)說(shuō)就是服務(wù)器端的邏輯和狀態(tài)是完全依賴于云平臺(tái)進(jìn)行管理的。
2. FaaS(Function as a Service)即函數(shù)即服務(wù)。函數(shù)即服務(wù)，意味著這些函數(shù)中的后臺(tái)邏輯是由我們開(kāi)發(fā)者自己實(shí)現(xiàn)的。但是這些函數(shù)是執(zhí)行在一個(gè)無(wú)狀態(tài)的計(jì)算容器中的，函數(shù)的執(zhí)行是基于事件驅(qū)動(dòng)的，關(guān)于這些函數(shù)的部署、執(zhí)行、觸發(fā)是由云平臺(tái)來(lái)管理的。其最典型的例子就是AWS Lambda。

我們這篇文章中的所討論的Serverless，是指的第二種，也就是FaaS。在我們Thoughtworks***一期的技術(shù)雷達(dá)中，Serverless架構(gòu)位于試驗(yàn)象限，下文就介紹下我們?cè)赟erverless架構(gòu)下的一些實(shí)踐經(jīng)驗(yàn)。

二、數(shù)據(jù)處理業(yè)務(wù)的Serverless架構(gòu)演進(jìn)

所謂的數(shù)據(jù)處理業(yè)務(wù)，是指我們的系統(tǒng)需要每天定時(shí)獲取一些外部數(shù)據(jù)與我們自身的數(shù)據(jù)結(jié)合，生成一些數(shù)據(jù)報(bào)表。那么最初我們是怎么設(shè)計(jì)技術(shù)方案的呢?

1. 傳統(tǒng)架構(gòu)方式

我們將業(yè)務(wù)拆分為3個(gè)獨(dú)立的服務(wù)，2個(gè)Data Collector，1個(gè)Data Loader，都分別部署在AWS服務(wù)器上，將中間數(shù)據(jù)存儲(chǔ)在一個(gè)外部S3(AWS的數(shù)據(jù)存儲(chǔ))上。***將數(shù)據(jù)保存在數(shù)據(jù)庫(kù)中，在數(shù)據(jù)庫(kù)之上使用專門的BI工具來(lái)制作報(bào)表。

我們***個(gè)數(shù)據(jù)服務(wù)就是按照這樣的架構(gòu)進(jìn)行設(shè)計(jì)和實(shí)踐的。當(dāng)系統(tǒng)上線服務(wù)以后，我們發(fā)現(xiàn)了里邊的一些問(wèn)題。

在這套系統(tǒng)中，Data Collector 2每天的執(zhí)行時(shí)間較長(zhǎng)，需要1個(gè)小時(shí)左右的時(shí)間，而Data Collector 1每天的執(zhí)行時(shí)間較短，通常執(zhí)行時(shí)間不會(huì)超過(guò)1分鐘，但是由于外部數(shù)據(jù)源的更新時(shí)間是不確定的，所以雖然我們服務(wù)實(shí)際有效時(shí)間只有僅僅一到兩分鐘，但是也不得不讓服務(wù)器全天運(yùn)行。

可以看到，這個(gè)系統(tǒng)每天的有效時(shí)間只有一個(gè)小時(shí)，其他23個(gè)小時(shí)實(shí)際上是在浪費(fèi)資源，如何改善這樣的情況呢?首先想到了讓服務(wù)定點(diǎn)運(yùn)行的方法。由于我們外服數(shù)據(jù)源的更新特點(diǎn)，雖然它的更新時(shí)間是不確定的，但是它在某個(gè)特定的時(shí)間點(diǎn)前是一定會(huì)更新的。基于這樣的前提，我們將服務(wù)運(yùn)行時(shí)間改為定點(diǎn)運(yùn)行，這樣是不是就能解決問(wèn)題了呢?

然而現(xiàn)實(shí)并不總是那么美好，因?yàn)槲覀兎?wù)間是有依賴關(guān)系的，Data Loader是依賴于我們Data Collector的處理結(jié)果的，當(dāng)我們把運(yùn)行方式改為定點(diǎn)運(yùn)行后，帶來(lái)的問(wèn)題是，一旦Data Collector的運(yùn)行狀態(tài)出現(xiàn)了問(wèn)題，例如運(yùn)行時(shí)間過(guò)長(zhǎng)，運(yùn)行中出現(xiàn)錯(cuò)誤，那么Data Loader必然出錯(cuò)。同時(shí)改為定點(diǎn)運(yùn)行后，我們的數(shù)據(jù)更新必然有延遲。

那么如何解決這些問(wèn)題呢?

2. Serverless的系統(tǒng)架構(gòu)

我們引入了Lambda，將Data Collector 和 Data Loader用Lambda進(jìn)行了替換，帶來(lái)了下面這些好處：

由于Lambda是由事件驅(qū)動(dòng)的，S3上一個(gè)數(shù)據(jù)的變化可以觸發(fā)一個(gè)事件，SNS的一條消息可以觸發(fā)一個(gè)時(shí)間等等，在使用Lambda后，我們就可以講原來(lái)基于時(shí)間的數(shù)據(jù)處理流程，轉(zhuǎn)變?yōu)榛谑录臄?shù)據(jù)處理流程，這樣一方面可以保證我們數(shù)據(jù)更新的實(shí)時(shí)性，另一方面可以大大節(jié)省資源，由于Lambda是按照觸發(fā)次數(shù)收費(fèi)的，所以在我們的這個(gè)用例下，可以大大減少花費(fèi)。

可能細(xì)心的讀者想問(wèn)為什么我們Data Collector 2沒(méi)有使用Lambda進(jìn)行替換呢?這是因?yàn)樗臉I(yè)務(wù)邏輯比較復(fù)雜，每次運(yùn)行的時(shí)間較長(zhǎng)，而Lambda的最長(zhǎng)執(zhí)行時(shí)間是5分鐘，所以在這種情況下，就不適合使用Lambda進(jìn)行替換了。

3. 實(shí)時(shí)數(shù)據(jù)處理下的Serverless架構(gòu)

在初識(shí)Serverless架構(gòu)的好處之后，我們開(kāi)始在其他方面的應(yīng)用嘗試，比較典型的一個(gè)例子就是在實(shí)時(shí)數(shù)據(jù)處理業(yè)務(wù)下的Serverless架構(gòu)。在我們業(yè)務(wù)下，我們需要實(shí)時(shí)跟蹤一個(gè)外部的數(shù)據(jù)源API，根據(jù)它的數(shù)據(jù)變化來(lái)實(shí)時(shí)更新我們的數(shù)據(jù)。

在我們的架構(gòu)設(shè)計(jì)中，我們使用一個(gè)Lambda來(lái)跟蹤外部數(shù)據(jù)源的數(shù)據(jù)變化，并將其推到AWS Kinesis Stream里，AWS Kinesis會(huì)觸發(fā)第二個(gè)Lambda進(jìn)行相應(yīng)的數(shù)據(jù)處理，并把數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)中，值得注意的是由于Lambda是可以根據(jù)需求自動(dòng)伸縮的，所以Lambda會(huì)根據(jù)Kinesis的需求來(lái)自動(dòng)擴(kuò)展。這就體現(xiàn)了Serverless架構(gòu)下的另一個(gè)好處，可以相對(duì)簡(jiǎn)單的，自動(dòng)進(jìn)行伸縮擴(kuò)展。

4. Web系統(tǒng)的Serverless架構(gòu)

對(duì)于Web系統(tǒng)這種我們最為熟悉和常見(jiàn)的IT系統(tǒng)來(lái)說(shuō)，它能不能用Serverless的架構(gòu)來(lái)實(shí)現(xiàn)呢?我們來(lái)看下邊的例子。我們先來(lái)看看傳統(tǒng)的例子。

在傳統(tǒng)實(shí)現(xiàn)中，我們會(huì)利用Load Blancer來(lái)做負(fù)載均衡，然后后續(xù)的應(yīng)用會(huì)部署在AutoScaling Group中，根據(jù)流量來(lái)做自動(dòng)伸縮，這種模式已經(jīng)是十分成熟了。那么在Serverless的架構(gòu)下該如何設(shè)計(jì)呢?

在Serverless架構(gòu)下，一般我們的前端應(yīng)用的資源文件包括Html，JS，CSS，都是部署在S3(AWS的文件存儲(chǔ))上的。前端應(yīng)用通過(guò)AJAX請(qǐng)求向后臺(tái)請(qǐng)求數(shù)據(jù)。后臺(tái)通過(guò)API GateWay定義對(duì)外的Endpoint，同時(shí)每個(gè)Endpoint會(huì)觸發(fā)一個(gè)Lambda進(jìn)行數(shù)據(jù)操作，例如圖中的GET，和POST請(qǐng)求會(huì)觸發(fā)兩個(gè)不同Lambda。這樣的Serverless架構(gòu)可以讓開(kāi)發(fā)者不必?fù)?dān)心水平擴(kuò)展的問(wèn)題。

三、Serverless架構(gòu)的未來(lái)

目前AWS Lambda似乎已經(jīng)成為了Serverless的代名詞，為了幫助開(kāi)發(fā)者更好的構(gòu)建Serverless應(yīng)用，市場(chǎng)上出現(xiàn)了一些工具和框架，例如Serverless Framework。但是同樣我們還可以看到一些其他的云平臺(tái)和開(kāi)源框架也在提供類似的服務(wù)，例如webtask，OpenWhisk，以及其在IBM Bluemix上的實(shí)現(xiàn)。

Serverless架構(gòu)作為一種新的架構(gòu)方式，還在不斷的發(fā)展中。希望本文能給您帶來(lái)一些思考。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文