基于 Docker 的 Serverless 架構實踐

一、計算的進化

UCloud 是一個做 IaaS (基礎設施即服務)的服務商， IaaS 本質上有三塊：計算的虛擬化、網絡的虛擬化、存儲的虛擬化。

其中計算的虛擬化本身是以主機 uhost 為主，后來面向一些虛擬機解決不了的問題，比如高性能的 DB 等一些需要很強計算能力的場景時推出了 uphost，可以頁面上生產物理機；后來面向更傳統的行業，推出了托管云項目，用戶可以把機器托管到機架上面，當網絡、虛擬機和物理機打通了，就是所謂的混合云的架構。

下一個計算產品是什么？

云計算是通過網絡快速獲取計算資源、網絡資源和存儲資源的，云計算本身的發展有不同的形態：基于 IaaS 的形態之上出現了 PaaS （平臺基于服務）、BaaS （后端即服務）和 FaaS （函數基于服務）等類似的產品，。

對于用戶來說，PaaS 基本上解決了運維部署的工作，提供了代碼托管的環境；但是 PaaS 需要自己寫代碼，而 BaaS 已經把服務提供好了，可以直接調用，但是如果很多個請求過來，PaaS 就無法同時執行； FaaS 會按照請求量執行函數，結束后就銷毀掉，因此可以同時執行多個請求。

FaaS 概念今年火起來是在 6 月份 martinfowler 上的一篇關于 Serverless 的博文，AWS 推出Lambda 的時候說：“ AWS 對一個應用的理解就是數據+函數+事件。”Lambda 支持 Python、Java 和 note.js，你可以按照它的方式寫一個函數，并且可以在它的頁面上設定有哪些事件的時候執行這個函數，這也是 FaaS 具體的形態。

Serverless跟前面三者有相同之處也有區別，傳統的架構是業務邏輯是放在一個數據化的 Sever 上面，但 Serverless 沒有服務器，認證模塊、DB、計算都是放在別人提供的服務上的，自身的客戶端只要將這些服務按照邏輯組合起來就可以了。

簡單來說，提供這個服務的廠商來幫你搞定 Sever，你只管邏輯把它跟客戶端串起來就可以，降低了自己寫 Server 的門檻。

在做計算的虛擬化的時候會購買大量的物理機，但是有很多物理機資源是空閑的，因為做虛擬化產品，最核心的部分是怎么管理物理機資源，用戶申請到虛擬機的時候，怎么知道虛擬機分配到哪臺物理機上面是合適的。按照物理機的負載權重來隨機分配、按照一定比例分配都可以，但是每個人申請的虛擬機最后運行效率是不一樣的，這就會導致物理機在運行過程中負載有高有低，從而導致大量的剩余資源。

這個算法有沒有改進的空間？如何把數以萬臺的服務器、大量的 CPU 和內存資源壓榨出來？

需求：

?業務跑在虛擬機上，每次擴容都要向資源部門申請資源

? 運維部門部署和運維工作量大

? 剩余資源如何以更便于使用的方式提供出來

二、通用計算的實現

方案一：在這片物理機上面再生成一個非常大配置的虛擬機，專門給他們用，這樣的話就可以把剩余資源給占了，避免浪費。

虛擬化的問題：

? 隔離性好，但調度粒度過大

UCloud 的 IO 性能對比于業界的虛擬機要好，但是虛擬機的 IO 是托到本地盤而不是基于網絡盤的，這就對在線遷移提了很高的要求，因為基于網絡盤的虛擬機在線遷移只需要遷內存和整個設備的狀態就可以了，而基于本地盤的在線遷移要把塊設備的數據全部遷移過去，所以如果磁盤很大的話，就會導致遷移速度很慢，調度虛擬機時非常困難，或者時間周期很長。

? 以資源為中心而不是以服務為中心

申請虛擬機部署服務本質上還是以資源為中心的，要知道虛擬機的 ip，并且要部署、監控它等等。

? ?戶需要關心 vm 的部署和監控

方案二：考慮使用 Docker

好處：

?更細的粒度

? 更輕的調度

? 易于部署

? 計算資源做服務化打包，提供以服務為中心的視角 。如果一個程序打包成 Docker 的話，通過 Docker 為單位調度，調度的是這個服務，而不是資源。

? 跨語?。任何語言按照 Docker 的標準打包起來的話就變成一個通用的、方便移植的東西，對語言沒有任何限制。

方案三：根據虛擬化和Docker 的好處采取內外結合的方案

?問題： Docker 隔離性問題，以 Docker 為粒度提供對外服務并不安全，如果它有問題可能損壞運行環境。

?解決：采用 vm+ Docker 的模式 ，將算法打包成 Docker ， 以 restful 方式執行算法。

產品架構圖：

ULB4是內網負載均衡，可以做到跨機房的容災。

openresty的目的是用于做灰度發布，當程序有更新的時候，把流量導到某個地方去。

虛線框是產品完整的邏輯，每個set 都是平等的，并且是每個是獨立的服務，其中一個掛了不會影響其他的服務，可以通過 set 去灰度一些重要功能：

API 負責對外提供服務；

TaskManger 負責調度；

Executor 則是每個虛擬機都部署的，用來執行 Docker ；

產品名詞解釋

? Docker 鏡像：計算任務的算法打包方式，將 Docker 鏡像提交至 GeneralCompute 的鏡像倉庫，用于后面的計算任務提交

? 任務：通過用計算服務提供的 http api 提交，任務內容包含：Docker 鏡像路路徑，算法輸入。任務的輸出由api 返回。任務分為同步任務及異步任務：

1） 同步任務

用于實時計算，客戶端提交任務后等待api返回任務結果。

2） 異步任務

用于離線長耗時的計算，客戶端提交任務后，api 返回任務 id, 客戶端根據任務 id 查詢任務狀態及結果。

服務使用方式：

用戶將服務打包成 Docker 并上傳到 Docker倉庫 ，通過HTTP API方式調用任務，拉起 Docker 完成計算，Docker 跑在 vm 集群中，位置和調度由 TaskManager 完成

好處：

忘掉資源，忘掉部署，專注算法

產品優勢：

1）海量計算能力

十萬核級的計算能力，自動高效完成計算分布，你可以通過一套 api 享受到十萬核級別的計算能力。

2）以計算為中心

用戶無需要關心資源位置及環境部署，只需要專注自己的算法及通過 api 做任務編排就可以了。

3）靈活易用

以 Docker 方式打包自定義算法，支持 API 方式調用計算服務，易于集成到應用的業務流程。paas 有個重要的問題沒解決，就是供應商綁定的問題，docker 提供的方案就很大程度地解決了這個問題。

4）按需付費

按實際消耗的計算資源計費，無需付出非計算資源(內存，磁盤)的費用，無需擔心浪費。 這可能是最吸引用戶的地方。

5）自動擴容+高并發

可以同時提交多個API，同時跑多個算法，算法跑在不同的節點上，完全是并發的，但是隱含了一個限制，就是這個任務必須是無狀態的，這也是 FaaS 的要求。

但是 Docker 的優點很明顯，缺點也很明顯，用戶在使用 Docker 的過程中不應該追求最新的技術，應該根據自己的需求出發。

三、通用計算的應用例子

1.圖片處理實踐 - UFILE 圖片處理

u?le 是 UCloud 的類 S3 服務，用戶提供一張圖片，ufile 提供幾種圖片處理的算法，通過算法對圖片進行縮略圖、格式轉換、旋轉、打水印等操作，再給用戶返回一張處理好的圖片。

需求：

? 實時性

? 跨語言的算法

? 大并發。ufile的用戶量很大。

? ?量的計算

實現：

將u?le的圖片處理算法打包成 Docker，基于數據流的實時計算，將輸入流重定向到Docker實例的標準輸入，圖片處理算法讀取標準輸入并將處理結果輸出到標準輸出，管理程序將Docker標準輸出變成HTTP流返回給用戶。

普通實現圖解：用戶通過 ufile api 將圖片傳到 server 上面，發現 URL 不一樣調用不同的算法把圖片處理完，再把圖片返回給用戶。

使用 Serverless 架構實現圖解：把算法打包成 Docker 鏡像傳到鏡像倉庫里，通過 api 把圖片傳過來，api 可以指定算法對應的鏡像，就把圖片返回去。

優點：

? 節省了大量的物理機。

? 節省了大量的人力。不需要寫 server，只要寫鏡像，而且不用關心資源在哪里，和擴容和看鏡像的問題。

2.圖片處理實踐 - OCR 識別

OCR 識別的作用是把題目掃描成圖片，通過 opencv 和機器學習的方式識別題目的內容。

需求：

? 每天 1600 萬的圖片處理

? 每張圖片處理時間 2~3s

? 算法優化依賴特殊的 CPU 指令

實現：

將opencv及機器學習模型打包成 docker 鏡像，計算節點支持特殊 CPU 指令，并發執?。

普通實現圖解：用戶把圖片傳給中控 Server ，中控 Server 是一個持久化的服務，里面的邏輯把圖片識別完返回物理機集群里，但是寫 Server 的門檻對于做機器學習的人員來說太高。

使用 Serverless 架構實現圖解：將opencv及機器學習模型打包成 Docker 鏡像后就沒有 Server ，用戶直接把圖片通用的 api 傳過來即可，相當于機器學習的模型在線化的服務。

優點：

? 節省百臺物理機

? 算法優化不用考慮并發，只需專注單張圖片的處理效率

四、未來展望

? 基于深度學習的圖片處理

? 基于通用計算平臺的分布式訓練

? 基于通用計算平臺的模型在線化服務

? 科學計算

? 基于通用計算的 paas & faas產品

 

來自：https://my.oschina.net/osccreate/blog/792470