Servrless概念

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

Serverless 和 PaaS的關系

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

Serverless 和 BaaS 的關系

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

與 Serverless 的***次接觸

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

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

alexjc/neural-doodle 

它的效果大概是這樣：

先過一遍步驟：

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

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

試用 Serverless 產品(UCloud UGC)

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

下圖其中一個使用場景：

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

很適我們本次梵高風格化圖片的需求。下面是我這次搭建服務過程：

1. 創建私有倉庫(WEB界面)
2. 登錄鏡像倉庫(cli)
3. 制作梵高風格轉換鏡像(cli)(如果你認真看文檔，你會發現其實 alexjc/neural-doodle 其實是有直接提供鏡像的，^_^)
4. 上傳鏡像(cli)
5. 查看鏡像詳情(WEB界面)
6. 告警模板配置(WEB界面)
7. 使用 SDK 提交任務(Python SDK)
8. 查看任務執行統計WEB界面)
9. 查看監控(WEB界面)

下面是詳細的操作步驟：

|> 創建私有倉庫

|> 下載梵高風格轉換鏡像

鏡像介紹頁面：https://hub.docker.com/r/alexjc/neural-doodle/

我們直接從 Docker 官方下載它：

docker pull alexjc/neural-doodle

|> 修改鏡像名稱

docker tag alexjc/neural-doodle cn-bj2.ugchub.service.ucloud.cn/kevingao/neural-doodle:first

|> 登錄UCloud鏡像倉庫

docker login cn-bj2.ugchub.service.ucloud.cn

|> 上傳鏡像

將我們剛才下載的鏡像上傳到UCloud鏡像倉庫

docker push cn-bj2.ugchub.service.ucloud.cn/kevingao/neural-doodle:first

|> 查看鏡像信息

|> 告警模板配置

目前包含超時與失敗兩個模板可以直接使用。

|> 使用SDK提交風格轉換任務

在Python SDK中配置自己賬號的公私鑰和Docker image 路徑，然后使用 Web后端調用，發布風格轉換任務。

至此我們風格轉換接口就就緒了，使用相同的方法搞定打水印的鏡像，我們先使用腳本測試一下接口，然后通過UCloud UGC服務后臺來查看執行的情況

|> 查看任務執行統計

包含調用次數、成功率、結果、花費CPU時間等信息。

下面我們就要開始前端的制作了。

前端交互

Web App有兩個功能，打水印和梵高風格轉換，

它們的交互基本是一致的，這里我截圖打水印的頁面來做演示：

***步：選擇圖片

第二步：上傳圖片 (也可以直接使用UGC 對象存儲功能)

第三步：輸入要打的水印(鏡像需要的參數)

第四步：返回結果展示

第五步：統計任務執行結果

如上文所見，這個簡單的Web APP完成了『圖片梵高風格化』和『圖片打水印』兩個功能，這里它體現了UGC的兩大優點：

• 計算能力自動擴展，處理一張照片與處理100張照片的時間花費是一樣的;
• 高并發，UGC擁有多節點數萬核的資源支持可以輕松支持高并發的請求。

附UGC 官網：https://www.ucloud.cn/site/product/ugc.html