基于 Docker的Serverless 架構(gòu)實踐如何理解UCloud通用計算產(chǎn)品的實現(xiàn)及其應(yīng)?

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)基于 Docker的Serverless 架構(gòu)實踐如何理解UCloud通用計算產(chǎn)品的實現(xiàn)及其應(yīng)?，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一、計算的進化

UCloud 是一個做 IaaS (基礎(chǔ)設(shè)施即服務(wù))的服務(wù)商， IaaS 本質(zhì)上有三塊：計算的虛擬化、網(wǎng)絡(luò)的虛擬化、存儲的虛擬化。

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

下一個計算產(chǎn)品是什么？

云計算是通過網(wǎng)絡(luò)快速獲取計算資源、網(wǎng)絡(luò)資源和存儲資源的，云計算本身的發(fā)展有不同的形態(tài)：基于 IaaS 的形態(tài)之上出現(xiàn)了 PaaS （平臺基于服務(wù)）、BaaS （后端即服務(wù)）和 FaaS （函數(shù)基于服務(wù)）等類似的產(chǎn)品，。

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

FaaS 概念今年火起來是在 6 月份 martinfowler 上的一篇關(guān)于 Serverless 的博文（翻譯版）， AWS 推出 Lambda 的時候說：“ AWS 對一個應(yīng)用的理解就是數(shù)據(jù)+函數(shù)+事件。” Lambda 支持 Python、Java 和 note.js ，你可以按照它的方式寫一個函數(shù)，并且可以在它的頁面上設(shè)定有哪些事件的時候執(zhí)行這個函數(shù)，這也是 FaaS 具體的形態(tài)。

Serverless跟前面三者有相同之處也有區(qū)別，傳統(tǒng)的架構(gòu)是業(yè)務(wù)邏輯是放在一個數(shù)據(jù)化的 Sever 上面，但 Serverless 沒有服務(wù)器，認(rèn)證模塊、DB、計算都是放在別人提供的服務(wù)上的，自身的客戶端只要將這些服務(wù)按照邏輯組合起來就可以了。

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

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

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

需求：

?業(yè)務(wù)跑在虛擬機上，每次擴容都要向資源部門申請資源

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

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

二、通用計算的實現(xiàn)

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

虛擬化的問題：

? 隔離性好，但調(diào)度粒度過大

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

? 以資源為中心而不是以服務(wù)為中心

申請?zhí)摂M機部署服務(wù)本質(zhì)上還是以資源為中心的，要知道虛擬機的 ip，并且要部署、監(jiān)控它等等。

? ?戶需要關(guān)心 vm 的部署和監(jiān)控

方案二：考慮使用 Docker

好處：

?更細的粒度

? 更輕的調(diào)度

? 易于部署

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

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

方案三：根據(jù)虛擬化和 Docker 的好處采取內(nèi)外結(jié)合的方案

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

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

產(chǎn)品架構(gòu)圖：

ULB4是內(nèi)網(wǎng)負載均衡，可以做到跨機房的容災(zāi)。

openresty的目的是用于做灰度發(fā)布，當(dāng)程序有更新的時候，把流量導(dǎo)到某個地方去。

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

API 負責(zé)對外提供服務(wù)；

TaskManger 負責(zé)調(diào)度；

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

產(chǎn)品名詞解釋

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

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

1） 同步任務(wù)

用于實時計算，客戶端提交任務(wù)后等待api返回任務(wù)結(jié)果。

2） 異步任務(wù)

用于離線長耗時的計算，客戶端提交任務(wù)后，api 返回任務(wù) id, 客戶端根據(jù)任務(wù) id 查詢?nèi)蝿?wù)狀態(tài)及結(jié)果。

服務(wù)使用方式：

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

好處：

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

產(chǎn)品優(yōu)勢：

1）海量計算能力

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

2）以計算為中心

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

3）靈活易用

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

4）按需付費

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

5）自動擴容+高并發(fā)

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

但是 Docker 的優(yōu)點很明顯，缺點也很明顯，用戶在使用 Docker 的過程中不應(yīng)該追求最新的技術(shù)，應(yīng)該根據(jù)自己的需求出發(fā)。

三、通用計算的應(yīng)用例子

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

u?le 是 UCloud 的類 S3 服務(wù)，用戶提供一張圖片，ufile 提供幾種圖片處理的算法，通過算法對圖片進行縮略圖、格式轉(zhuǎn)換、旋轉(zhuǎn)、打水印等操作，再給用戶返回一張?zhí)幚砗玫膱D片。

需求：

? 實時性

? 跨語言的算法

? 大并發(fā)。ufile的用戶量很大。

? ?量的計算

實現(xiàn)：

將u?le的圖片處理算法打包成 Docker，基于數(shù)據(jù)流的實時計算，將輸入流重定向到Docker實例的標(biāo)準(zhǔn)輸入，圖片處理算法讀取標(biāo)準(zhǔn)輸入并將處理結(jié)果輸出到標(biāo)準(zhǔn)輸出，管理程序?qū)ocker標(biāo)準(zhǔn)輸出變成HTTP流返回給用戶。

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

使用 Serverless 架構(gòu)實現(xiàn)圖解：把算法打包成 Docker 鏡像傳到鏡像倉庫里，通過 api 把圖片傳過來，api 可以指定算法對應(yīng)的鏡像，就把圖片返回去。

優(yōu)點：

? 節(jié)省了大量的物理機。

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

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

OCR 識別的作用是把題目掃描成圖片，通過 opencv 和機器學(xué)習(xí)的方式識別題目的內(nèi)容。

需求：

? 每天 1600 萬的圖片處理

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

? 算法優(yōu)化依賴特殊的 CPU 指令

實現(xiàn)：

將opencv及機器學(xué)習(xí)模型打包成 docker 鏡像，計算節(jié)點支持特殊 CPU 指令，并發(fā)執(zhí)?。

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

使用 Serverless 架構(gòu)實現(xiàn)圖解：將opencv及機器學(xué)習(xí)模型打包成 Docker 鏡像后就沒有 Server ，用戶直接把圖片通用的 api 傳過來即可，相當(dāng)于機器學(xué)習(xí)的模型在線化的服務(wù)。

優(yōu)點：

? 節(jié)省百臺物理機

? 算法優(yōu)化不用考慮并發(fā)，只需專注單張圖片的處理效率

上述就是小編為大家分享的基于 Docker的Serverless 架構(gòu)實踐如何理解UCloud通用計算產(chǎn)品的實現(xiàn)及其應(yīng)?了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。