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