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

它的效果大概是這樣：

先過一遍步驟：

瀏覽器發請求給服務端，body 是一張圖片的二進制數據；

服務端從 body 中取出二進制數據，轉成圖片，調用 doodle.py 中的方法，轉換風格存儲之并返回存儲位置；

瀏覽器按位置請求圖片并展示之。

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

試用 Serverless

本文以UCloud通用計算（UCloud General Compute）為例來介紹。UGC可滿足圖片處理、機器學習、大數據處理、生物數據分析等領域的計算需求。

下圖是其中一個使用場景：

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

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

創建私有倉庫（WEB界面）

登錄鏡像倉庫（cli）

制作梵高風格轉換鏡像（cli）（如果你認真看文檔，你會發現其實 alexjc/neural-doodle 其實是有直接提供鏡像的，^_^）

上傳鏡像（cli）

查看鏡像詳情（WEB界面）

告警模板配置（WEB界面）

使用 SDK 提交任務（Python SDK）

查看任務執行統計WEB界面）

查看監控（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

• 登錄鏡像倉庫
  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后端調用，發布風格轉換任務。至此我們風格轉換接口就就緒了，使用相同的方法搞定打水印的鏡像，我們先使用腳本測試一下接口，然后通過UGC服務后臺來查看執行的情況
• 查看任務執行統計
  
  包含調用次數、成功率、結果、花費CPU時間等信息

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

前端交互

Web App有兩個功能，打水印和梵高風格轉換，它們的交互基本是一致的，這里我截圖打水印的頁面來做演示：

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

- 第三步：輸入要打的水印（鏡像需要的參數）

- 第四步：返回結果展示

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

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

計算能力自動擴展，處理一張照片與處理100張照片的時間花費是一樣的；

高并發，UGC擁有多節點數萬核的資源支持可以輕松支持高并發的請求。

總結

以上是生活随笔為你收集整理的与Serverless 的第一次亲密接触的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。