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%的服務要每月都更新，並且其中一定有很多的服務要一個月更新多次。

Spring boot，Spring cloud，Docker，Kubernetes微服務