這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)基于 Docker的Serverless 架構(gòu)實(shí)踐如何理解UCloud通用計(jì)算產(chǎn)品的實(shí)現(xiàn)及其應(yīng)?，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
主要從事網(wǎng)頁設(shè)計(jì)、PC網(wǎng)站建設(shè)（電腦版網(wǎng)站建設(shè)）、wap網(wǎng)站建設(shè)（手機(jī)版網(wǎng)站建設(shè)）、響應(yīng)式網(wǎng)站開發(fā)、程序開發(fā)、微網(wǎng)站、小程序制作等，憑借多年來在互聯(lián)網(wǎng)的打拼，我們在互聯(lián)網(wǎng)網(wǎng)站建設(shè)行業(yè)積累了豐富的成都做網(wǎng)站、網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷經(jīng)驗(yàn)，集策劃、開發(fā)、設(shè)計(jì)、營銷、管理等多方位專業(yè)化運(yùn)作于一體，具備承接不同規(guī)模與類型的建設(shè)項(xiàng)目的能力。
UCloud 是一個做 IaaS (基礎(chǔ)設(shè)施即服務(wù))的服務(wù)商， IaaS 本質(zhì)上有三塊：計(jì)算的虛擬化、網(wǎng)絡(luò)的虛擬化、存儲的虛擬化。
其中計(jì)算的虛擬化本身是以主機(jī) uhost 為主，后來面向一些虛擬機(jī)解決不了的問題，比如高性能的 DB 等一些需要很強(qiáng)計(jì)算能力的場景時(shí)推出了 uphost，可以頁面上生產(chǎn)物理機(jī)；后來面向更傳統(tǒng)的行業(yè)，推出了托管云項(xiàng)目，用戶可以把機(jī)器托管到機(jī)架上面，當(dāng)網(wǎng)絡(luò)、虛擬機(jī)和物理機(jī)打通了，就是所謂的混合云的架構(gòu)。
下一個計(jì)算產(chǎn)品是什么？
云計(jì)算是通過網(wǎng)絡(luò)快速獲取計(jì)算資源、網(wǎng)絡(luò)資源和存儲資源的，云計(jì)算本身的發(fā)展有不同的形態(tài)：基于 IaaS 的形態(tài)之上出現(xiàn)了 PaaS （平臺基于服務(wù)）、BaaS （后端即服務(wù)）和 FaaS （函數(shù)基于服務(wù)）等類似的產(chǎn)品，。
對于用戶來說，PaaS 基本上解決了運(yùn)維部署的工作，提供了代碼托管的環(huán)境；但是 PaaS 需要自己寫代碼，而 BaaS 已經(jīng)把服務(wù)提供好了，可以直接調(diào)用，但是如果很多個請求過來，PaaS 就無法同時(shí)執(zhí)行； FaaS 會按照請求量執(zhí)行函數(shù)，結(jié)束后就銷毀掉，因此可以同時(shí)執(zhí)行多個請求。
FaaS 概念今年火起來是在 6 月份 martinfowler 上的一篇關(guān)于 Serverless 的博文（翻譯版）， AWS 推出 Lambda 的時(shí)候說：“ AWS 對一個應(yīng)用的理解就是數(shù)據(jù)+函數(shù)+事件?！?nbsp;Lambda 支持 Python、Java 和 note.js ，你可以按照它的方式寫一個函數(shù)，并且可以在它的頁面上設(shè)定有哪些事件的時(shí)候執(zhí)行這個函數(shù)，這也是 FaaS 具體的形態(tài)。
Serverless跟前面三者有相同之處也有區(qū)別，傳統(tǒng)的架構(gòu)是業(yè)務(wù)邏輯是放在一個數(shù)據(jù)化的 Sever 上面，但 Serverless 沒有服務(wù)器，認(rèn)證模塊、DB、計(jì)算都是放在別人提供的服務(wù)上的，自身的客戶端只要將這些服務(wù)按照邏輯組合起來就可以了。
簡單來說，提供這個服務(wù)的廠商來幫你搞定 Sever，你只管邏輯把它跟客戶端串起來就可以，降低了自己寫 Server 的門檻。
在做計(jì)算的虛擬化的時(shí)候會購買大量的物理機(jī)，但是有很多物理機(jī)資源是空閑的，因?yàn)樽鎏摂M化產(chǎn)品，最核心的部分是怎么管理物理機(jī)資源，用戶申請到虛擬機(jī)的時(shí)候，怎么知道虛擬機(jī)分配到哪臺物理機(jī)上面是合適的。按照物理機(jī)的負(fù)載權(quán)重來隨機(jī)分配、按照一定比例分配都可以，但是每個人申請的虛擬機(jī)最后運(yùn)行效率是不一樣的，這就會導(dǎo)致物理機(jī)在運(yùn)行過程中負(fù)載有高有低，從而導(dǎo)致大量的剩余資源。
這個算法有沒有改進(jìn)的空間？如何把數(shù)以萬臺的服務(wù)器、大量的 CPU 和內(nèi)存資源壓榨出來？
需求：
?業(yè)務(wù)跑在虛擬機(jī)上，每次擴(kuò)容都要向資源部門申請資源
? 運(yùn)維部門部署和運(yùn)維工作量大
? 剩余資源如何以更便于使用的方式提供出來
虛擬化的問題：
? 隔離性好，但調(diào)度粒度過大
UCloud 的 IO 性能對比于業(yè)界的虛擬機(jī)要好，但是虛擬機(jī)的 IO 是托到本地盤而不是基于網(wǎng)絡(luò)盤的，這就對在線遷移提了很高的要求，因?yàn)榛诰W(wǎng)絡(luò)盤的虛擬機(jī)在線遷移只需要遷內(nèi)存和整個設(shè)備的狀態(tài)就可以了，而基于本地盤的在線遷移要把塊設(shè)備的數(shù)據(jù)全部遷移過去，所以如果磁盤很大的話，就會導(dǎo)致遷移速度很慢，調(diào)度虛擬機(jī)時(shí)非常困難，或者時(shí)間周期很長。
? 以資源為中心而不是以服務(wù)為中心
申請?zhí)摂M機(jī)部署服務(wù)本質(zhì)上還是以資源為中心的，要知道虛擬機(jī)的 ip，并且要部署、監(jiān)控它等等。
? ?戶需要關(guān)心 vm 的部署和監(jiān)控
好處：
?更細(xì)的粒度
? 更輕的調(diào)度
? 易于部署
? 計(jì)算資源做服務(wù)化打包，提供以服務(wù)為中心的視角 。如果一個程序打包成 Docker 的話，通過 Docker 為單位調(diào)度，調(diào)度的是這個服務(wù)，而不是資源。
? 跨語?。任何語言按照 Docker 的標(biāo)準(zhǔn)打包起來的話就變成一個通用的、方便移植的東西，對語言沒有任何限制。
?問題： Docker 隔離性問題，以 Docker 為粒度提供對外服務(wù)并不安全，如果它有問題可能損壞運(yùn)行環(huán)境。
?解決：采用 vm+ Docker 的模式 ，將算法打包成 Docker ， 以 restful 方式執(zhí)行算法。
產(chǎn)品架構(gòu)圖：
ULB4是內(nèi)網(wǎng)負(fù)載均衡，可以做到跨機(jī)房的容災(zāi)。
openresty的目的是用于做灰度發(fā)布，當(dāng)程序有更新的時(shí)候，把流量導(dǎo)到某個地方去。
虛線框是產(chǎn)品完整的邏輯，每個set 都是平等的，并且是每個是獨(dú)立的服務(wù)，其中一個掛了不會影響其他的服務(wù)，可以通過 set 去灰度一些重要功能：
API 負(fù)責(zé)對外提供服務(wù)；
TaskManger 負(fù)責(zé)調(diào)度；
Executor 則是每個虛擬機(jī)都部署的，用來執(zhí)行 Docker ；
產(chǎn)品名詞解釋
? Docker 鏡像：計(jì)算任務(wù)的算法打包方式，將 Docker 鏡像提交至 GeneralCompute 的鏡像倉庫，用于后面的計(jì)算任務(wù)提交
? 任務(wù)：通過用計(jì)算服務(wù)提供的 http api 提交，任務(wù)內(nèi)容包含：Docker 鏡像路路徑，算法輸入。任務(wù)的輸出由api 返回。任務(wù)分為同步任務(wù)及異步任務(wù)：
1） 同步任務(wù)
用于實(shí)時(shí)計(jì)算，客戶端提交任務(wù)后等待api返回任務(wù)結(jié)果。
2） 異步任務(wù)
用于離線長耗時(shí)的計(jì)算，客戶端提交任務(wù)后，api 返回任務(wù) id, 客戶端根據(jù)任務(wù) id 查詢?nèi)蝿?wù)狀態(tài)及結(jié)果。
服務(wù)使用方式：
用戶將服務(wù)打包成 Docker 并上傳到 Docker倉庫 ，通過HTTP API方式調(diào)用任務(wù)，拉起 Docker 完成計(jì)算，Docker 跑在 vm 集群中，位置和調(diào)度由 TaskManager 完成
好處：
忘掉資源，忘掉部署，專注算法
產(chǎn)品優(yōu)勢：
1）海量計(jì)算能力
十萬核級的計(jì)算能力，自動高效完成計(jì)算分布，你可以通過一套 api 享受到十萬核級別的計(jì)算能力。
2）以計(jì)算為中心
用戶無需要關(guān)心資源位置及環(huán)境部署，只需要專注自己的算法及通過 api 做任務(wù)編排就可以了。
3）靈活易用
以 Docker 方式打包自定義算法，支持 API 方式調(diào)用計(jì)算服務(wù)，易于集成到應(yīng)用的業(yè)務(wù)流程。paas 有個重要的問題沒解決，就是供應(yīng)商綁定的問題，docker 提供的方案就很大程度地解決了這個問題。
4）按需付費(fèi)
按實(shí)際消耗的計(jì)算資源計(jì)費(fèi)，無需付出非計(jì)算資源(內(nèi)存，磁盤)的費(fèi)用，無需擔(dān)心浪費(fèi)。 這可能是最吸引用戶的地方。
5）自動擴(kuò)容+高并發(fā)
可以同時(shí)提交多個API，同時(shí)跑多個算法，算法跑在不同的節(jié)點(diǎn)上，完全是并發(fā)的，但是隱含了一個限制，就是這個任務(wù)必須是無狀態(tài)的，這也是 FaaS 的要求。
但是 Docker 的優(yōu)點(diǎn)很明顯，缺點(diǎn)也很明顯，用戶在使用 Docker 的過程中不應(yīng)該追求最新的技術(shù)，應(yīng)該根據(jù)自己的需求出發(fā)。
u?le 是 UCloud 的類 S3 服務(wù)，用戶提供一張圖片，ufile 提供幾種圖片處理的算法，通過算法對圖片進(jìn)行縮略圖、格式轉(zhuǎn)換、旋轉(zhuǎn)、打水印等操作，再給用戶返回一張?zhí)幚砗玫膱D片。
需求：
? 實(shí)時(shí)性
? 跨語言的算法
? 大并發(fā)。ufile的用戶量很大。
? ?量的計(jì)算
實(shí)現(xiàn)：
將u?le的圖片處理算法打包成 Docker，基于數(shù)據(jù)流的實(shí)時(shí)計(jì)算，將輸入流重定向到Docker實(shí)例的標(biāo)準(zhǔn)輸入，圖片處理算法讀取標(biāo)準(zhǔn)輸入并將處理結(jié)果輸出到標(biāo)準(zhǔn)輸出，管理程序?qū)ocker標(biāo)準(zhǔn)輸出變成HTTP流返回給用戶。
普通實(shí)現(xiàn)圖解：用戶通過 ufile api 將圖片傳到 server 上面，發(fā)現(xiàn) URL 不一樣調(diào)用不同的算法把圖片處理完，再把圖片返回給用戶。
使用 Serverless 架構(gòu)實(shí)現(xiàn)圖解：把算法打包成 Docker 鏡像傳到鏡像倉庫里，通過 api 把圖片傳過來，api 可以指定算法對應(yīng)的鏡像，就把圖片返回去。
優(yōu)點(diǎn)：
? 節(jié)省了大量的物理機(jī)。
? 節(jié)省了大量的人力。不需要寫 server，只要寫鏡像，而且不用關(guān)心資源在哪里，和擴(kuò)容和看鏡像的問題。
OCR 識別的作用是把題目掃描成圖片，通過 opencv 和機(jī)器學(xué)習(xí)的方式識別題目的內(nèi)容。
需求：
? 每天 1600 萬的圖片處理
? 每張圖片處理時(shí)間 2~3s
? 算法優(yōu)化依賴特殊的 CPU 指令
實(shí)現(xiàn)：
將opencv及機(jī)器學(xué)習(xí)模型打包成 docker 鏡像，計(jì)算節(jié)點(diǎn)支持特殊 CPU 指令，并發(fā)執(zhí)?。
普通實(shí)現(xiàn)圖解：用戶把圖片傳給中控 Server ，中控 Server 是一個持久化的服務(wù)，里面的邏輯把圖片識別完返回物理機(jī)集群里，但是寫 Server 的門檻對于做機(jī)器學(xué)習(xí)的人員來說太高。
使用 Serverless 架構(gòu)實(shí)現(xiàn)圖解：將opencv及機(jī)器學(xué)習(xí)模型打包成 Docker 鏡像后就沒有 Server ，用戶直接把圖片通用的 api 傳過來即可，相當(dāng)于機(jī)器學(xué)習(xí)的模型在線化的服務(wù)。
優(yōu)點(diǎn)：
? 節(jié)省百臺物理機(jī)
? 算法優(yōu)化不用考慮并發(fā)，只需專注單張圖片的處理效率
上述就是小編為大家分享的基于 Docker的Serverless 架構(gòu)實(shí)踐如何理解UCloud通用計(jì)算產(chǎn)品的實(shí)現(xiàn)及其應(yīng)?了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
