Docker、kubernetes、微服務、SpringBoot/Cloud...好亂！到底要不要學？

阿新 • • 發佈：2018-12-26

Docker、微服務日益火熱的今天，相信標題上這些名詞大家都不陌生。但也相信有很多同學並不夠清楚他們的概念，不理解它們的關係，也可能有這樣的疑惑：不知道跟我有沒有關係？要不要學習？怎麼去學習？學哪些東西？沒關係，今天我們就從頭捋捋，讓大家都能得到自己的答案。
Docker誕生於2013年，之後就是迅速串紅、火的已經發燙。它為什麼會火呢？有什麼牛x的技術嗎？並沒有，docker的技術都是linux核心早已存在的技術，像LXC呀，cgoup呀，namespace呀，都是很早就存在的。那docker有啥高明的地方？很重要的一個就是image，它定義了一個交付標準，早期docker官網首頁的三個最大的單詞：build，ship，run。詮釋了docker和核心：image的構建，image的傳輸，image的執行。docker就是定義並且實現了這些標準。那為什麼直到2013年docker才出現呢？以前怎麼沒有人有這樣的想法？其實想法一直都有，只是docker出現的時機更好，往往決定性的因素並不是技術本身，而是網際網路的發展，市場的需要。
時至今日-2018年，Docker已歷經5年發展，Docker公司揭露了今年最新的Docker年度資料報告，至今在Docker上的容器映象下載次數已經超過了370億次，容器化的應用有高達350萬個，目前在LinkedIn網站上的Docker相關職缺也有15,000個。全球活躍的Docker使用者社群已有200多個，包括臺灣也有。
隨著docker、容器的日漸成熟，容器編排的問題就凸顯出來，大量的容器怎麼去管理，怎麼排程，怎麼啟停都成了迫切需要解決的問題。有需求就有人去解決，ApacheMesos、kubernetes、docker swarm陸續登場，大有三足鼎立之勢，而隨著各自的發展，到了2017年下半年，google的親兒子kubernetes的呼聲越來越高，社群也更加活躍、成熟。2017年底，docker swarm和ApacheMesos陸續宣稱支援kubernetes，預示著容器編排大戰的結束，kubernetes已然成為容器編排領域的事實標準。
服務編排框架的成熟，使得容器的管理越來越方便、高效，容器帶來的好處也隨之凸顯：提升資源利用率節省成本、更高效的持續整合，持續交付、解放運維、快速擴縮容，應對突發流量...
服務編排框架的成熟也讓微服務的概念得以落地，同時也催生了java界微服務化的方案，像SpringBoot，SpringCloud。然而服務編排一定是對微服務的編排嗎？也就是我們容器裡執行的一定是微服務嗎？不是的，我們可以執行任何服務，我們現有的業務可以不做任何改造就執行到容器中，讓kubernetes去管理、排程。至於微服務呢，只是有了kubernetes，讓微服務變得容易管理了。讓我們有條件把服務拆分的足夠小，足夠簡單。再也不用擔心運維管理的複雜了。瞭解了docker，服務編排，微服務的關係，我們在看看他們在企業的落地情況。
下面是數人云2018年初做的it行業系統調查報告
這張圖縱向的是系統更新頻率，其中網際網路行業的更新頻率最高，有92%的服務要每月都更新，並且其中一定有很多的服務要一個月更新多次。

這張圖統計的是目前企業it系統支撐所存在的問題。我們看兩個比重最大的問題，一個是系統的複雜性越來越高，一個是運維管理複雜。在傳統單體架構或者SOA架構下，應用如果頻繁升級更新，開發團隊會非常痛苦。為什麼呢？企業的業務系統經過多年發展，系統往往會非常龐大，複雜性越來越高，要改動其中任何一小部分，都需要重新部署整個應用，敏捷開發和快速交付根本無從談起。還有傳統企業在長期的IT建設過程中，往往會使用到不同的技術，這導致技術棧之間差異很大，統一的管理和運維變將得非常複雜。隨著這樣一些問題越來越凸顯，企業向微服務架構轉型的需求也越來越強烈。

這張圖是目前微服務架構在企業的落地情況：有6%的企業已經部分引入了Spring Cloud開發框架。另外，9%的受訪企業採用了Dubbo等其他微服務框架。此外，還有51%的企業在考慮往雲原生方向轉型，包括公有云、私有云。由此可見，絕大部分企業是有架構轉型的需求的。

這張圖是2017年docker的使用情況。在接受調研的企業中，在生產環境中採用Docker的比例為9%，測試環境使用達22%。而且規模越大的企業，尤其是伺服器規模在500臺以上的，是Docker容器的主要採用者。另外，正在考慮評估中的佔到被調研企業的一半以上。企業的關注度急劇升高，Docker使用正在快速普及。而容器和微服務相輔相成，他們成熟的時間點也非常契合。