與Serverless的第一次親密接觸

作者：UCloud產(chǎn)品團隊 2017-08-08 12:50:51

Serverless 是一個架構上的概念，從字面上理解就是無服務器架構。Serverless最初是用于描述依賴第三方服務實現(xiàn)對邏輯和狀態(tài)進行管理的應用，典型的例子是單頁 Web 和移動 App 這種富客戶端應用。

Servrless概念

Serverless 是一個架構上的概念，從字面上理解就是無服務器架構。Serverless最初是用于描述依賴第三方服務實現(xiàn)對邏輯和狀態(tài)進行管理的應用，典型的例子是單頁 Web 和移動 App 這種富客戶端應用，他們一般都使用基于云端的數(shù)據(jù)庫(例如Parse、Firebase)，認證服務(Auth0、AWS congnito)等。這些第三方服務通常稱為 BaaS(Backend as a Service) 。Serverless 的第二種含義，是用來描述這樣一種應用架構：除了使用第三方 BaaS 服務外，一部分服務端邏輯仍然由應用的研發(fā)人員實現(xiàn)，但是跟傳統(tǒng)架構不同在于，這部分服務端代碼運行于無狀態(tài)的容器中，可以由事件觸發(fā)，短暫的，完全被第三方管理。業(yè)界對 Serverless 的熱議，大部分集中第二種，因為第二種形式代碼托管代表技術更新，以 FaaS(Function as a Service) 而聞名。根據(jù)第二種場景，有一個***的定義是：Serverless 架構是基于互聯(lián)網(wǎng)的系統(tǒng)，其中應用開發(fā)不使用常規(guī)的服務進程。相反，它們僅依賴于第三方服務(例如 AWS Lambda 服務)，客戶端邏輯和服務托管遠程過程調(diào)用的組合。后面敘述都是基于第二種定義來進行，也就是基于 FaaS 函數(shù)計算服務來實現(xiàn)的 Serverless 應用架構，在這個定義上可以簡單把 Serverless 等同 FaaS。

Serverless 和 PaaS的關系

FaaS 與 PaaS的概念在某些方面有許多相似的地方。人們甚至認為 FaaS 就是另一種形式的 PaaS，但是 Intent Media 的工程副總裁 Mike Roberts 提出一個微妙的差別：“大部分PaaS應用無法針對每個請求啟動和停止整個應用程序，而 FaaS 平臺生來就是為了實現(xiàn)這樣的目的。” AWS 云架構戰(zhàn)略副總裁 Adrian Cockcroft 曾經(jīng)針對兩者的界定給出了一個簡單的方法：“如果你的PaaS 能夠有效地在20毫秒內(nèi)啟動實例并運行半秒，那么就可以稱之為 Serverless”。我理解兩個人的意思，都是認為傳統(tǒng)的 PaaS 和 FaaS 的抽象層次不一樣，PaaS 是對整個應用的抽象，F(xiàn)aaS 是對應用邏輯的單位(函數(shù))的抽象。舉例來說，PaaS 不是針對每個請求來拉起一個服務，它是常駐的服務，而 FaaS 是根據(jù)每個請求來拉起一個容器來執(zhí)行，屬于更細粒度的拆分。也就是：PaaS 托管的是整個應用，而 FaaS 托管應用的某個碎片化的邏輯代碼，從資源使用率和成本角度更具優(yōu)勢。

Serverless 和 BaaS 的關系

BaaS 和 Serverless 的區(qū)別主要在于，BaaS 是一般是第三方提供的后端服務，例如 AWS 提供的Congito就是典型的 BaaS 服務，業(yè)界比較成功的 BaaS 服務幾乎都是為移動開發(fā)的后端云服務，例如 Facebook 的 Parese, google 的 Firebase, 國內(nèi) LeandCloud，提供的功能大同小異，都是實時數(shù)據(jù)庫，消息推送等等。BaaS 的粒度介乎 PaaS 和 FaaS, PaaS 是提供了應用運行環(huán)境，而是BaaS將特定應用變成一個云服務。而應用想實施 Serverless 架構，還是需要自己的服務代碼來組合這些 BaaS 服務來滿足自己的業(yè)務邏輯，而且服務代碼要通過 FaaS 來管理。用兩張圖說明兩者區(qū)別，兩個圖是都是實現(xiàn)一個廣告點擊行為數(shù)據(jù)處理，Click Processor 是實際處理動作的服務。***張圖 Click Processor 是一個 BaaS 服務，進程常駐，每次都由這個進程處理。第二張圖把它改造成 Serverless 架構，每次點擊拉起一個進程執(zhí)行一個函數(shù)，函數(shù)托管在 FaaS 服務中。

與 Serverless 的***次接觸

想象一下，你是一名 Web 開發(fā)工程師，你接到一個需求需要做一個單頁面應用，上傳一張圖并在幾秒后獲得一張梵高風格化的圖，像這樣：

遇到這種情況，一般…嗯……先 Google 一下，找到了這個：

alexjc/neural-doodle

它的效果大概是這樣：

先過一遍步驟：

瀏覽器發(fā)請求給服務端，body 是一張圖片的二進制數(shù)據(jù);
服務端從 body 中取出二進制數(shù)據(jù)，轉成圖片，調(diào)用 doodle.py 中的方法，轉換風格存儲之并返回存儲位置;
瀏覽器按位置請求圖片并展示之。

但是有幾個問題，如果這個 SPA 出乎意料的受歡迎，接口負載過高呢?是不是要升級，加機器，加負載均衡?如果來了一個新需求或者簡單的 bugfix，是不是又涉及到批量更新節(jié)點，這還是沒有考慮日志，運維，監(jiān)控等運營方面的工作量。根據(jù)前面對Serverless的介紹，這個場景很適合用Serverless產(chǎn)品來解決，這是一個典型的無狀態(tài)服務+計算的自動擴展，這些問題交給Serverless服務提供方即可。下面我選擇UCloud的Serverless產(chǎn)品UGC來搭建這個服務，并測試一下效果，看是否能滿足我的需求。

試用 Serverless 產(chǎn)品(UCloud UGC)

根據(jù)官方的介紹，UCloud通用計算(UCloud General Compute)是分布式大規(guī)模并行計算服務。可提供數(shù)萬核級的并發(fā)計算能力，系統(tǒng)自動完成任務調(diào)度，并按實際使用量計費。UGC充分利用一個區(qū)域內(nèi)的多個可用區(qū)計算資源，提供了基于云平臺的跨可用區(qū)級別的高可用性、高安全性和高并發(fā)性。UGC可滿足圖片處理、機器學習、大數(shù)據(jù)處理、生物數(shù)據(jù)分析等領域的計算需求。

下圖其中一個使用場景：

UCloud基于UGC的高效并行計算能力搭建的對象存儲(UFile)圖片處理服務，得以輕松支持用戶每天***別的圖片處理請求，滿足用戶對高時效的需求。