葉理燈，UCloud計算增值研發部經理。負責 UCloud 計算增值業務産品及研發，專注面向企業的雲計算産品的研發及營運。擁有10年網際網路研發經驗，先後任職于騰訊、盛大雲等網際網路公司，從事海量分布式背景系統研發及營運。
一、計算的進化
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 圖檔處理
ufile 是 UCloud 的類 S3 服務，使用者提供一張圖檔，ufile 提供幾種圖檔處理的算法，通過算法對圖檔進行縮略圖、格式轉換、旋轉、打水印等操作，再給使用者傳回一張處理好的圖檔。
需求：
• 實時性
• 跨語言的算法
• 大并發。ufile的使用者量很大。
• 海量的計算
實作：
将ufile的圖檔處理算法打包成 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産品
版權聲明：本文為CSDN部落客「weixin_33785972」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：https://blog.csdn.net/weixin_33785972/article/details/92065486