Serverless架構(gòu)實踐初探
隨著云計算技術(shù)的進(jìn)步，軟件系統(tǒng)的架構(gòu)方式也因此發(fā)生著一些變化，其中Serverless架構(gòu)就是這里的一個典型的例子。
一、什么是Serverless架構(gòu)
目前關(guān)于Serverless架構(gòu)的準(zhǔn)確定義，業(yè)界并沒有一個統(tǒng)一的標(biāo)準(zhǔn)。那么我們從字面上來分析，所謂Serverless架構(gòu)，翻譯過來也就是無服務(wù)器架構(gòu)。那么似乎可以涵蓋以下兩個方面：
- BaaS(Backend as a Service)即后臺即服務(wù)。后臺即服務(wù)出現(xiàn)有很長一段的時間了，例如Parse,Firebase都是典型的代表。具體來說就是服務(wù)器端的邏輯和狀態(tài)是完全依賴于云平臺進(jìn)行管理的。
- FaaS(Function as a Service)即函數(shù)即服務(wù)。函數(shù)即服務(wù)，意味著這些函數(shù)中的后臺邏輯是由我們開發(fā)者自己實現(xiàn)的。但是這些函數(shù)是執(zhí)行在一個無狀態(tài)的計算容器中的，函數(shù)的執(zhí)行是基于事件驅(qū)動的，關(guān)于這些函數(shù)的部署、執(zhí)行、觸發(fā)是由云平臺來管理的。其最典型的例子就是AWS Lambda。
我們這篇文章中的所討論的Serverless，是指的第二種，也就是FaaS。在我們Thoughtworks***一期的技術(shù)雷達(dá)中，Serverless架構(gòu)位于試驗象限，下文就介紹下我們在Serverless架構(gòu)下的一些實踐經(jīng)驗。
二、數(shù)據(jù)處理業(yè)務(wù)的Serverless架構(gòu)演進(jìn)
所謂的數(shù)據(jù)處理業(yè)務(wù)，是指我們的系統(tǒng)需要每天定時獲取一些外部數(shù)據(jù)與我們自身的數(shù)據(jù)結(jié)合，生成一些數(shù)據(jù)報表。那么最初我們是怎么設(shè)計技術(shù)方案的呢?
1. 傳統(tǒng)架構(gòu)方式
我們將業(yè)務(wù)拆分為3個獨立的服務(wù)，2個Data Collector，1個Data Loader，都分別部署在AWS服務(wù)器上，將中間數(shù)據(jù)存儲在一個外部S3(AWS的數(shù)據(jù)存儲)上。***將數(shù)據(jù)保存在數(shù)據(jù)庫中，在數(shù)據(jù)庫之上使用專門的BI工具來制作報表。
我們***個數(shù)據(jù)服務(wù)就是按照這樣的架構(gòu)進(jìn)行設(shè)計和實踐的。當(dāng)系統(tǒng)上線服務(wù)以后，我們發(fā)現(xiàn)了里邊的一些問題。
在這套系統(tǒng)中，Data Collector 2每天的執(zhí)行時間較長，需要1個小時左右的時間，而Data Collector 1每天的執(zhí)行時間較短，通常執(zhí)行時間不會超過1分鐘，但是由于外部數(shù)據(jù)源的更新時間是不確定的，所以雖然我們服務(wù)實際有效時間只有僅僅一到兩分鐘，但是也不得不讓服務(wù)器全天運行。
可以看到，這個系統(tǒng)每天的有效時間只有一個小時，其他23個小時實際上是在浪費資源，如何改善這樣的情況呢?首先想到了讓服務(wù)定點運行的方法。由于我們外服數(shù)據(jù)源的更新特點，雖然它的更新時間是不確定的，但是它在某個特定的時間點前是一定會更新的?；谶@樣的前提，我們將服務(wù)運行時間改為定點運行，這樣是不是就能解決問題了呢?
然而現(xiàn)實并不總是那么美好，因為我們服務(wù)間是有依賴關(guān)系的，Data Loader是依賴于我們Data Collector的處理結(jié)果的，當(dāng)我們把運行方式改為定點運行后，帶來的問題是，一旦Data Collector的運行狀態(tài)出現(xiàn)了問題，例如運行時間過長，運行中出現(xiàn)錯誤，那么Data Loader必然出錯。同時改為定點運行后，我們的數(shù)據(jù)更新必然有延遲。
那么如何解決這些問題呢?
2. Serverless的系統(tǒng)架構(gòu)
我們引入了Lambda，將Data Collector 和 Data Loader用Lambda進(jìn)行了替換，帶來了下面這些好處：
由于Lambda是由事件驅(qū)動的，S3上一個數(shù)據(jù)的變化可以觸發(fā)一個事件，SNS的一條消息可以觸發(fā)一個時間等等，在使用Lambda后，我們就可以講原來基于時間的數(shù)據(jù)處理流程，轉(zhuǎn)變?yōu)榛谑录臄?shù)據(jù)處理流程，這樣一方面可以保證我們數(shù)據(jù)更新的實時性，另一方面可以大大節(jié)省資源，由于Lambda是按照觸發(fā)次數(shù)收費的，所以在我們的這個用例下，可以大大減少花費。
可能細(xì)心的讀者想問為什么我們Data Collector 2沒有使用Lambda進(jìn)行替換呢?這是因為它的業(yè)務(wù)邏輯比較復(fù)雜，每次運行的時間較長，而Lambda的最長執(zhí)行時間是5分鐘，所以在這種情況下，就不適合使用Lambda進(jìn)行替換了。
3. 實時數(shù)據(jù)處理下的Serverless架構(gòu)
在初識Serverless架構(gòu)的好處之后，我們開始在其他方面的應(yīng)用嘗試，比較典型的一個例子就是在實時數(shù)據(jù)處理業(yè)務(wù)下的Serverless架構(gòu)。在我們業(yè)務(wù)下，我們需要實時跟蹤一個外部的數(shù)據(jù)源API，根據(jù)它的數(shù)據(jù)變化來實時更新我們的數(shù)據(jù)。
在我們的架構(gòu)設(shè)計中，我們使用一個Lambda來跟蹤外部數(shù)據(jù)源的數(shù)據(jù)變化，并將其推到AWS Kinesis Stream里，AWS Kinesis會觸發(fā)第二個Lambda進(jìn)行相應(yīng)的數(shù)據(jù)處理，并把數(shù)據(jù)存儲到數(shù)據(jù)庫中，值得注意的是由于Lambda是可以根據(jù)需求自動伸縮的，所以Lambda會根據(jù)Kinesis的需求來自動擴展。這就體現(xiàn)了Serverless架構(gòu)下的另一個好處，可以相對簡單的，自動進(jìn)行伸縮擴展。
4. Web系統(tǒng)的Serverless架構(gòu)
對于Web系統(tǒng)這種我們最為熟悉和常見的IT系統(tǒng)來說，它能不能用Serverless的架構(gòu)來實現(xiàn)呢?我們來看下邊的例子。我們先來看看傳統(tǒng)的例子。
在傳統(tǒng)實現(xiàn)中，我們會利用Load Blancer來做負(fù)載均衡，然后后續(xù)的應(yīng)用會部署在AutoScaling Group中，根據(jù)流量來做自動伸縮，這種模式已經(jīng)是十分成熟了。那么在Serverless的架構(gòu)下該如何設(shè)計呢?
在Serverless架構(gòu)下，一般我們的前端應(yīng)用的資源文件包括Html，JS，CSS，都是部署在S3(AWS的文件存儲)上的。前端應(yīng)用通過AJAX請求向后臺請求數(shù)據(jù)。后臺通過API GateWay定義對外的Endpoint，同時每個Endpoint會觸發(fā)一個Lambda進(jìn)行數(shù)據(jù)操作，例如圖中的GET，和POST請求會觸發(fā)兩個不同Lambda。這樣的Serverless架構(gòu)可以讓開發(fā)者不必?fù)?dān)心水平擴展的問題。
三、Serverless架構(gòu)的未來
目前AWS Lambda似乎已經(jīng)成為了Serverless的代名詞，為了幫助開發(fā)者更好的構(gòu)建Serverless應(yīng)用，市場上出現(xiàn)了一些工具和框架，例如Serverless Framework。但是同樣我們還可以看到一些其他的云平臺和開源框架也在提供類似的服務(wù)，例如webtask，OpenWhisk，以及其在IBM Bluemix上的實現(xiàn)。
Serverless架構(gòu)作為一種新的架構(gòu)方式，還在不斷的發(fā)展中。希望本文能給您帶來一些思考。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
