第1期 2021/01/15
公有云之Docker應(yīng)用處理能力評測
“云”是企業(yè)在數(shù)字化轉(zhuǎn)型過程中，繞不開的一個主題。即便有些企業(yè)表示，近期不會上云，也只是不會將業(yè)務(wù)部署到公有云上。隨著企業(yè)舊有軟、硬件系統(tǒng)的更替，也勢必要從傳統(tǒng)數(shù)據(jù)中心向私有云數(shù)據(jù)中心進行轉(zhuǎn)變。這時候想或不想上云的企業(yè)都會面臨業(yè)務(wù)如何在云端進行部署的問題。下面就讓我們看一下通過Docker打包后的Web應(yīng)用在十大公有云上的應(yīng)用處理能力表現(xiàn)。
遭到棄用的Docker與方興未艾的容器
通過今年的公有云調(diào)研發(fā)現(xiàn)，通過容器技術(shù)將舊有或新業(yè)務(wù)進行打包，并在云上進行部署，已經(jīng)成為當前企業(yè)關(guān)注的熱點。然而在寫稿之前又收到一個消息，“Kubernetes 中已棄用了 Docker 支持”！在震驚之余，又感到可以理解，畢竟開源是當前軟件開發(fā)的大趨勢，而Docker由開源項目變成公司商標，甚至連鯨魚logo使用也需要授權(quán)的狀態(tài)，實在與開源軟件的宗旨大相違背。也真是由衷的佩服Docker，明明有很多種活法，但非要活成令人討厭的樣子，既然讓人討厭，就別怪被人踢到一邊了。
即便讓人討厭，也并不妨礙企業(yè)在生產(chǎn)環(huán)境中，大量使用經(jīng)典 Kubernetes+ Docker 方案，同時在一些業(yè)務(wù)場景中也有單獨使用 Docker 的情況。未來即使Docker可能會被拋棄，但是通過容器鏡像將應(yīng)用打包，并在云上進行業(yè)務(wù)部署的趨勢，并不會因此受到過大影響。畢竟Docker也僅僅是Linux容器的一種打包應(yīng)用方式。去掉Docker部分直接對Linux容器進行調(diào)用，對于未來容器應(yīng)用部署而言未必是一件壞事。
容器在公有云上的應(yīng)用能力表現(xiàn)
然而利用容器將應(yīng)用進行打包后，在公有云平臺上進行部署，是否會對應(yīng)用處理能力產(chǎn)生過大影響呢？為了了解這個問題，至頂網(wǎng)懂云帝繼續(xù)沿用2019年公有云Web應(yīng)用測試方案，對十大公有云廠商云主機上部署由Docker打包的Web應(yīng)用性能同樣進行了測試。
在本次測試中，同樣采用在服務(wù)器端，用ab同時保持50個用戶訪問（ab參數(shù)-c 50）并建立1萬連接和間隔數(shù)分鐘后再發(fā)起同時保持50個用戶訪問并建立10萬連接的方式，對公有云主機上用Docker部署的Web應(yīng)用通過高并發(fā)的方式進行應(yīng)用處理能測試。并選用Apache AB所提供的請求速率Requests/s結(jié)果進行統(tǒng)計。在得出測試結(jié)果后，再與去年公有云主機Web應(yīng)用測試結(jié)果相比對，看一下通過Docker鏡像打包后，Web應(yīng)用的最大處理能力是否出現(xiàn)下降，對比結(jié)果如下：
不出所料的是，通過Docker將應(yīng)用進行打包，在公有云主機上進行部署后，應(yīng)用處理性能或多或少都會有所下降。但其中下降最嚴重的Azure云主機，居然從去年的87.97-92.67下降到了37.16-36.83，Web應(yīng)用性能下降了一倍還不止。這樣的結(jié)果就有些難以令人理解了。
此外還有UCloud，Web應(yīng)用性能非但沒有下降，反而還有大幅度的提升。詢問原因有以下兩點，一是UCloud對云主機上容器處理性能進行了大幅優(yōu)化，另一個原因是去年是對UCloud云主機Braodwell的CPU進行的測試，但今年云主機CPU已經(jīng)換成了Cascadelake，處理性能也比去年有所增長。
不過從橫向?qū)Ρ葴y試結(jié)果來看，即便在今年選擇處理器中，其他家也基本選擇的是最新Cascadelake處理器，但UCloud云主機的Docker處理性能依然處于最高水平，可見其Docker應(yīng)用優(yōu)化，確實是卓見成效。
公有云主機Docker部署情況分析
Docker在公有云上部署，應(yīng)用處理的性能還會有所降低，那么容器的優(yōu)勢到底是什么？舉個我們在云主機上部署的例子，大家就很容易理解了。
今年雖然受到疫情的影響，但是至頂網(wǎng)的業(yè)務(wù)卻反而比去年更加飽滿。不然作者也不會在2020跨年的時間，還在辛苦的趕著測試的稿子。今年的公有云測試，也是我們懂云帝幾個抽空擠時間來完成的。但是和19年進行公有云主機環(huán)境搭建時完全不同。那時候，是我催著樂樂同學(xué)，找時間搭一下公有云測試環(huán)境。而今年是他主動催我來做測試。并不是因為樂樂同學(xué)的事情少，而是因為在Docker下搭測試環(huán)境實在是太簡單了。
某位同學(xué)只需要把云主機建起來之后，把上面這幾行代碼一粘貼，然后就可以催著我做測試了。這也是頭一次讓我見識到搭測試環(huán)境比跑測試的時間還短的情況。
由此可知，在如此便捷的應(yīng)用部署能力面前，少許應(yīng)用處理性能的損失，就顯得那么的微不足道了。當然微軟的Azure云部署應(yīng)當除外，但我相信Azure也應(yīng)當會很快將這個問題給解決一下的。
后Docker時期的容器發(fā)展
在原定計劃中，還有一項通過Kubernetes對公有云上Docker進行管理的體驗，可惜（xing hao）還沒找到時間進行，就已經(jīng)傳來“Kubernetes 中已棄用了 Docker 支持”的消息。于是在2020年的公有云測試中，將不再進行Docker的管理控制能力測試了，但是未來容器的將如何進行發(fā)展，我們懂云帝還是會繼續(xù)進行關(guān)注。在新的2021年將會邀請一些技術(shù)專家一起進行一下座談，好好探討一下Docker模式的未來前景，容器技術(shù)未來將如何發(fā)展，企業(yè)應(yīng)用要如何才能通過容器更好的將業(yè)務(wù)進行打包，并在云端部署。
總而言之，充滿坎坷的2020年已經(jīng)過去了，在充滿希望的2021年，我們相信萬事皆有可能！
本文章選自《數(shù)字化轉(zhuǎn)型方略》雜志，閱讀更多雜志內(nèi)容，請掃描下方二維碼
