2015 年自己還只是一個容器的使用者，2016 年作為容器和云相關(guān)的開發(fā)者,，對容器生態(tài)圈也比較關(guān)注,，本文整體從生態(tài)圈角度分析了一下當前的各容器相關(guān)產(chǎn)品，作為個人年度總結(jié)（本來是打算年前發(fā)的,，可惜一直拖到年后了）,。
提到容器就不能不說 Docker。容器技術(shù)雖然存在了很長時間,，卻因 Docker 而火,。很長時間里,，很多人的概念里基本 Docker 就代表容器,。一次一產(chǎn)品經(jīng)理朋友問我做什么，我說做容器相關(guān),，她表示很不懂,，但說是 Docker ，她就明白了,，可見 Docker 之火,。這一年里，Docker 發(fā)布了幾個重要版本,。我們先回顧下 Docker 本來是什么,，再說它的變化。
前三點基本上都是容器相關(guān)或者延伸的,，唯獨第四點,，深受其他容器編排調(diào)度廠商的詬病。任何分布式的管理系統(tǒng),，都會在每個主機上安裝一個自己的 agent,，由這個 agent 管理該節(jié)點上的應(yīng)用進程。從這點功能上來說,，和 Docker daemon 是沖突的,，操作系統(tǒng)的 systemd，可以忽略不用就行,，但要用 Docker 容器的話,，離不開 Docker daemon 。設(shè)想一下,，如果你老板讓你管理一個團隊,，但任何管理指令都只能通過另外一個人來發(fā)出，你也會感覺不爽吧,？所以 Docker 和其他容器編排調(diào)度系統(tǒng)的沖突從開始就種下了,。感覺開始 Docker 團隊也沒思考這個問題，自己的 Swarm 也是用獨立的 agent,，但后來發(fā)現(xiàn)有點多余,，把 Swarm 的 agent 以及調(diào)度器內(nèi)置到 Docker daemon 不就行？何況 Docker daemon 本身已經(jīng)支持了 remote API,，并且這樣設(shè)計還是一個無中心的對等節(jié)點集群模式,，部署運維更方便。于是 Docker 的 1.12 內(nèi)置了 Swarm（準確的說是 SwarmKit）,，幾個命令就將多個單機版本的 Docker daemon 變成一個 cluster,，還支持了 service 概念（多個容器實例副本的抽象），1.13 支持了 stack 的概念（多個 service 的組合） 和 Compose（編排定義文件），基本上一個略完備的編排調(diào)度系統(tǒng)已經(jīng)成型,。 而這個變化,，也表明了和其他容器編排調(diào)度系統(tǒng)的決裂。本來 Docker 作為容器的一種,，大家都在上面基于容器搭建編排調(diào)度系統(tǒng),，還能和平共處。容器相當于輪子,，編排調(diào)度系統(tǒng)是車,，結(jié)果有一天造輪子的廠商說自己的幾個輪子直接拼接起來就稱為一輛車了，造車的廠商不急才怪,，這相當于發(fā)起了『降維』攻擊,。 有了編排調(diào)度系統(tǒng)，Docker 進而推出 Store 也是順理成章,。服務(wù)器端的應(yīng)用大多不是單個節(jié)點或進程的應(yīng)用,，需要將多個服務(wù)組裝,，一直以來大家都在尋找一種方式實現(xiàn)服務(wù)器端應(yīng)用的一鍵安裝和部署,。Docker 的應(yīng)用打包了編排文件以及鏡像定義，配合編排調(diào)度系統(tǒng)提供的標準環(huán)境,，再用 Store 作為應(yīng)用分發(fā),，意圖已經(jīng)非常明確。但感覺 Docker 這步走的略匆忙,，當前編排調(diào)度系統(tǒng)尚未成熟,，就著急推出更上一層的應(yīng)用，可能會拖累后面的演進,，不過這也應(yīng)該是受商業(yè)化的壓力所致吧,。 當然 Docker 出此決策，面臨的挑戰(zhàn)也是巨大的,。容器生態(tài)圈的割裂,，導致 Docker 得以一己之力重塑自己的生態(tài)圈。Docker 推出的容器網(wǎng)絡(luò)標準（libnetwork）不被其他廠商接受,，其他廠商也在降低對 Docker 的依賴程度（整個后面具體分析時會提到）,。Swarm 成熟度還不夠用在生產(chǎn)環(huán)境，它的網(wǎng)絡(luò)當前只支持 overlay,，尚不能支持自己的網(wǎng)絡(luò)插件標準,，編排文件的完備程度也不夠。存儲方面,，去年 Docker 收購了 Infinit （很早就關(guān)注 Infinit,，它一直宣稱要開源，但遲遲沒等到源碼，就聽到了它被 Docker 收購的消息）這家做分布式存儲的公司,。如果 Docker 在2017年解決網(wǎng)絡(luò)和存儲兩個分布式系統(tǒng)的痛點,，Swarm 的前景還是可期。 作為一個開發(fā)者,，我自己其實挺喜歡 Docker 的這種設(shè)計的,，雖然它推出的有點晚。這種模式符合開發(fā)團隊對容器的漸進式接納,。比如開始可以先將 Docker 當做一種制品包管理工具,，網(wǎng)絡(luò)用 host 模式，這種方式和在主機上維護部署多個應(yīng)用的進程沒有區(qū)別,，只是接管了依賴以及安裝包的維護,。然后當開發(fā)流程的打包機制改造完畢，開發(fā)人員的習慣逐漸改變,，這時候就可以引入 Docker 的網(wǎng)絡(luò)解決方案,，先改造應(yīng)用直接通過容器的網(wǎng)絡(luò)進行通信，但部署和調(diào)度都沿用原來的模式,。等這些都改造完,，運維也成熟了，然后開啟 Swarm 模式,，將應(yīng)用的部署和調(diào)度交給 Swarm,，基本上完成了應(yīng)用的容器化改造。這就像談戀愛一樣,，先約約會,，牽牽小手，然后（此處省略若干字）,，然后才是談婚論嫁,，考慮要不要做一輩子的承諾。而其他編排系統(tǒng)呢,，一上來就要用戶回答：你準備把你的一切以及后半生交付給我了么,？很多人就得猶豫了吧。 總結(jié)一下,，這一年,，Docker 已經(jīng)不是原來的 Docker，它代表一種容器方案,，一個系統(tǒng)軟件,，也代表一個商標，一個公司,，還代表一種容器編排調(diào)度系統(tǒng),。容器之戰(zhàn)剛剛開始,，三足鼎立，勝負未知,。但無論最后結(jié)果如何,，Docker 一初創(chuàng)公司，從開發(fā)者工具切入,，僅僅三年,，火遍全球技術(shù)圈，攪動整個服務(wù)器端技術(shù)棧,，進而涉足企業(yè)應(yīng)用市場,，攜用戶以抗巨頭，前所未有,。傳統(tǒng)的企業(yè)市場,，決策權(quán)多在不懂技術(shù)的領(lǐng)導，所以解決方案中對開發(fā)者是否友好,，不是一個關(guān)鍵點,，但從 Docker 以及國外最近的一些公司的案例（比如 slack，twilio 等）來看,，這一現(xiàn)象正在改變,，這表明了開發(fā)者群體的成熟和話語權(quán)的增加，企業(yè)應(yīng)用對開發(fā)者的友好程度將成為一個競爭的關(guān)鍵點,。 Kubernetes我在 2015 年底分析 Kubernetes 架構(gòu)的時候,，當時 1.2 版本尚未發(fā)布,。到現(xiàn)在已經(jīng)發(fā)布了 1.6 beta 版本了,。去年是 Kubernetes 爆發(fā)的一年，從社區(qū)文章以及 meetup 就可以看出來,。有很多文章已經(jīng)等不及開始宣布 Kubernetes 贏得了容器之戰(zhàn)了,。 Kubernetes 的優(yōu)勢是很多概念抽象非常符合理想的分布式調(diào)度系統(tǒng)，即便是你自己重新設(shè)計這樣一個系統(tǒng),，經(jīng)過不斷優(yōu)化和抽象,，最后也會發(fā)現(xiàn)，不可避免的慢慢向 Kubernetes 靠近,。 比如 Pod,，Service，Cluster IP,，ReplicationController（新的叫 ReplicaSets ）,，Label，以及通過 Label 自由選擇的 selector 機制,，以及去年引入的 DaemonSets 和 StatefulSets,。 DaemonSets 用于定義需要每個主機都部署一個，并且不需要動態(tài)遷移的服務(wù)，比如監(jiān)控的服務(wù),。Swarm 中尚未引入這種概念,，不過這種也可能會用另外的實現(xiàn)方式，比如插件機制,。通過 DaemonSet 定義的服務(wù)可以理解成分調(diào)度系統(tǒng)的 agent 擴展插件,。 StatefulSets（1.5 版本之前叫 PetSets）主要是為了解決有狀態(tài)服務(wù)部署的問題，它保證 pod 的唯一的網(wǎng)絡(luò)標志（主要是 pod 的 hostname,，ip 是否能保持不變?nèi)Q于網(wǎng)絡(luò)實現(xiàn)）的穩(wěn)定性,，不隨 pod 遷移重建而變化，另外支持了 PersistentVolume 規(guī)范,，封裝了已有的分布式存儲以及 IaaS 云的存儲接口,。 網(wǎng)絡(luò)方面，Kubernetes 推出 CNI（Container Network Interface） 網(wǎng)絡(luò)標準,。這個標準比較簡單,，只是約定了調(diào)用命令的參數(shù)，如果想擴展自己的實現(xiàn),，只需要寫個命令行工具放到系統(tǒng) path 下,，然后根據(jù) CNI 調(diào)用的參數(shù)來給容器分配網(wǎng)絡(luò)即可，可以用任何語言實現(xiàn),。它和 Kubernetes 基本沒有任何耦合,，所以也可以很容易被其他調(diào)度系統(tǒng)采用（比如 Mesos)。 從 Kubernetes 的演進可以看出,，谷歌對 Kubernetes 的期望在標準制定,，最核心的點是描述能力。官方文檔 What is Kubernetes?中有這樣一段描述：
它的目標不僅僅是一個編排系統(tǒng),，而是提供一個規(guī)范,，可以讓你來描述集群的架構(gòu)，定義服務(wù)的最終狀態(tài),，它來幫助你的系統(tǒng)達到和維持在這個狀態(tài),。這個其實和 Puppet/Ansible 等配置管理工具的目的是一致的，只是配置管理工具只能做達到某個狀態(tài),，沒法實現(xiàn)維持到這個狀態(tài)（沒有動態(tài)的伸縮以及故障遷移等調(diào)度能力）,，同時配置管理工具的抽象層次也比較低。它之所以選擇容器只是因為容器比較容易降低主機和應(yīng)用的耦合,，如果有其他技術(shù)能達到這個目的,，支持下也不影響它的定位。所以 Kubernetes 去年推出 CRI (Container Runtime Interface) 容器標準,，將 Kubernetes 和具體的容器實現(xiàn)進一步解耦,，一方面是對 Docker 內(nèi)嵌 Swarm 的一種反制,，另外一方面也是它的目標的必然演進結(jié)果。 正因為這樣,，它讓渡出了很大一部分功能給 IaaS 云（比如網(wǎng)絡(luò),，存儲），也不著急推出具體的解決方案,，也不著急兼容已有的各種分布式應(yīng)用,，發(fā)布兩年多還在專心在規(guī)范定義以及系統(tǒng)優(yōu)化上。Kubernetes 系出名門,，不擔心商業(yè)化的問題,，大家閨秀不愁嫁，無需迎合別人,，自然有人來適應(yīng)自己,。 當然理想是美好的，現(xiàn)實是當前已經(jīng)有大量的分布式系統(tǒng),，重復實現(xiàn)了許多 Kubernetes 已經(jīng)實現(xiàn)的功能,，或者集群機制是當前的 Kubernetes 的抽象概念沒有覆蓋到的，當前將這些系統(tǒng)運行到 Kubernetes 還是一件很難的事情（比如 redis cluster,，hadoop,，etcd，zookeeper,，支持主從自動切換的mysql集群等）,，因為任何抽象都是以損失個性化和特殊化為代價的。這里特別說下,，以前分析 Kubernetes 的時候有人反駁我這個說法,，我這里不是說 Kubernetes 上不能運行 zookeeper 這樣的服務(wù)，而是很難實現(xiàn)一鍵部署并且自動伸縮以及配置自動變更,，很多情況下還是需要手動操作接入,，比如官方的這個 zookeeper 例子。 CoreOS 為了解決這個問題,，推出了 operator的概念，給不容易通過 Kubernetes 當前的抽象描述的服務(wù)（有狀態(tài)服務(wù)或者特殊的集群服務(wù)）,，專門提供一個 operator,，operator 通過調(diào)用 Kubernetes 的 API 來實現(xiàn)伸縮，恢復,，升級備份等功能,。這樣雖然和 Kubernetes 的聲明式理念相沖突，也無法通過 kubectl 直接操作（kubectl 有支持插件機制的提案,，未來這種需求可能通過插件實現(xiàn)）,，也但當前也是一個可行的辦法,。 另外，Kubernetes 在大數(shù)據(jù)方面支和 Mesos 還有差距,。去年 Kubernetes 支持了 job 概念,，job 生成的 pod 執(zhí)行完成后立刻退出，原來的 service 可以理解成一個死循環(huán)的 job,。這樣,，Kubernetes 就具有了分發(fā)批量任務(wù)的能力，但還缺乏上層的應(yīng)用接口,。理論上,，將 Hadoop 的 MapReduce 移植到 Kubernetes，用 Kubernetes 替代底層的 Yarn 的資源調(diào)度功能,，也是可行的（只是開腦洞,，沒有具體分析）。有個打算整合 Yarn 和 Kubernetes 的項目已經(jīng)很久沒更新了,，這兩者的整合我不太看好,，兩個系統(tǒng)沖突嚴重,，是互相替代的關(guān)系,，不像 Mesos 和 Kubernetes 的整合（這個后面 Mesos 的段落會分析）。 部署復雜是 Kubernetes 一直被大家詬病一點,。2015 年我做測試的時候,，部署一套 Kubernetes 是一項很復雜的工作,。去年 Kubernetes 推出了 kubeadm，很大程度的降低了部署的復雜度,。當前 Kubernetes 除了 kubelet 需要直接在主機上啟動,，其他的組件都可以通過 Kubernetes 自己托管，一定程度上實現(xiàn)了『自舉』,，但易用度上和 Swarm 還是有差距,。 隨著 Kubernetes 的成熟，其他廠商開始制作自己的發(fā)行版,，比如 CoreOS,。CoreOS 原來的容器思路應(yīng)該是通過自己定制的容器操作系統(tǒng)，以及 etcd ,，將多個 CoreOS 主機合并成一個集群,，然后通過改造過的 systemd 充當 agent，上面再增加一個調(diào)度器,，就可以實現(xiàn)容器編排調(diào)度,，也是一種可行的思路，既然單機的服務(wù)進程管理可以通過 systemd,，將多個機器的 systemd 連接起來不就是一個分布式的服務(wù)進程管理,？但后來改變了策略,，估計是這種方案采納成本太高（用戶需要同時改變自己主機的操作系統(tǒng)以及應(yīng)用的部署習慣），所以當前的容器策略變?yōu)榱硕ㄖ?Kubernetes,，推出 tectonic,，CoreOS 改名為 Container Linux（應(yīng)該是為了避免產(chǎn)品和公司的名稱重疊，另外也透露出的一個信息是產(chǎn)品重心的變更）,，專注于主機操作系統(tǒng)（這個后面的操作系統(tǒng)部分會分析到）,。 總結(jié)一下，Kubernetes 經(jīng)過一年快速發(fā)展,，基本已經(jīng)非常完備,。原來的 kube-proxy 的性能問題（1.2 版本之前），也已經(jīng)解決,。建議原來處于觀望狀態(tài)的用戶可以入坑了,。不過在應(yīng)用的最終 package 定義上，Kubernetes 尚未推出自己的解決方案,，不確定這個是打算官方來搞,，還是讓度給發(fā)行版廠商，不過可以預計2017年肯定會有相關(guān)方案推出,。 Mesos如果說 Kubernetes 是為了標準而生,，那 Mesos 則是為了資源而生。它的理念是：
定義一個最小化的接口來支持跨框架的資源共享,，其他的調(diào)度以及執(zhí)行工作都委托給框架自己來控制,。 也就是說它的視角是資源視角，目標是資源共享,。這個和 Kubernetes 的目標其實是一體兩面,，一個從定義描述角度一個從資源角度。Mesos 其實是最早切入容器領(lǐng)域的,，但它的容器封裝的比較簡單,，只是用來做簡單的資源隔離，用戶一般沒什么感知,。有了 Docker 以后,，也引入了 Docker，但正如前面我分析的原因,，Mesos 上的 Docker 一直有點別扭,，于是 Mesos（準確的說應(yīng)該是 mesosphere DC/OS） 搞了一個 Universal container，改進了 Mesos 原來的容器,，支持了 Docker 的鏡像格式，這樣用戶可以在自己的開發(fā)環(huán)境中使用 Docker,，但生產(chǎn)環(huán)境中就可以直接切換到 Mesos 自己的容器上,，雖然可能有一些兼容性問題,，但鏡像格式這種變化不會太快，問題在可控范圍內(nèi),。 這也從另外一方面表明了 Docker 的鏡像格式基本上已經(jīng)成了一個事實標準,，一個容器解決方案能否切入整個生態(tài)圈的關(guān)鍵是是否支持 Docker 鏡像格式。當然 Mesos 成員對這點其實也有點抵觸,，在一些分享里強調(diào) Mesos 也支持部署其他類型的軟件包格式,，比如gzip等，尤其大規(guī)模服務(wù)器的場景,，從 Docker 倉庫拉取鏡像有瓶頸,。這點個人不太同意，大規(guī)模服務(wù)器場景,，從任何中心節(jié)點拉取任何格式的安裝包都會有問題,，所以 twitter 才搞 p2p 安裝包分發(fā)，但 Docker 鏡像也可以搞成 p2p 分發(fā)的,，只要有需求,，肯定有人能搞出來。 容器網(wǎng)絡(luò)方面,，原來 Mesos 的網(wǎng)絡(luò)解決方案就是端口映射,，應(yīng)用需要適應(yīng) Mesos 做修改，對應(yīng)用傾入性比較強,，通用性較差,，所以 Mesos 支持了 Kubernetes 發(fā)起的 CNI 網(wǎng)絡(luò)標準，解決了這個問題,。 Mesos 通過 framework 的機制,，接管了當前已經(jīng)存在的分布式系統(tǒng)的一部分職能，讓多個分布式系統(tǒng)共享同一個資源池變?yōu)榭赡?，容器編排也只?Mesos 之上的一種應(yīng)用（Marathon）,。這種方式的好處是讓整合復雜的分布式系統(tǒng)變?yōu)榭赡埽驗?framework 是編程接口,，靈活度也比較高,，很多不容易跑在 Kubernetes 上的復雜應(yīng)用，都可以在 Mesos 之上,，比如 Hadoop 等大數(shù)據(jù)相關(guān)的系列應(yīng)用,。 正因為 Mesos 和 Kubernetes 的目標正好是一體兩面，然后能力也可以互補,，所以很早就有人想整合 Kubernetes 和 Mesos,，將 Kubernetes 跑在 Mesos 之上，這樣 Kubernetes 接管容器編排調(diào)度，替代 Marathon,，Mesos 解決其他復雜的分布式應(yīng)用,，實現(xiàn)多種應(yīng)用的資源共享。但 kubernetes-mesos這個項目后來就不活躍了,，一方面是 Kubernetes 變化太快,，另外一方面估計是 mesosphere 發(fā)現(xiàn)和 Kubernetes 的競爭大于合作吧。后來 IBM 搞了個kube-mesos-framework放在 Kubernetes 孵化器里孵化,，不過當前尚不能正式使用,。個人感覺如果要真的很好整合，對 Kubernetes 和 Mesos 兩方都需要做很大改造,，但這個項目對生態(tài)圈來說是一個大變數(shù),，有可能打破三足鼎立的局勢。 Mesosphere 的 DC/OS 在 Mesos 基礎(chǔ)上搞了一個分布式應(yīng)用的 package 規(guī)范,。以前的應(yīng)用發(fā)布都只能發(fā)布面向單機操作系統(tǒng)的 package,，Mesosphere 通過 Marthon，鏡像以及配置文件,，定義了一套分布式的 package 規(guī)范,，用戶可以通過一個命令從倉庫（repo）上部署復雜的分布式應(yīng)用到 Mesos。這個和 Docker 的 Store 思路類似,。 總結(jié)一下,，Mesos 的優(yōu)勢是可定制性強，它誕生于 twitter 這樣的互聯(lián)網(wǎng)公司,，也比較受互聯(lián)網(wǎng)公司歡迎,。互聯(lián)網(wǎng)公司的基礎(chǔ)設(shè)施以及系統(tǒng)大多是自己研發(fā),，可以通過規(guī)范來要求自己的應(yīng)用適應(yīng)調(diào)度系統(tǒng),，所以對標準化和抽象能力的的需求不如資源共享強烈。它的缺點是周邊生態(tài)比較龐雜,，接口以及規(guī)范設(shè)計上,，沒有 Kubernetes 那么『優(yōu)雅』。 Rancher既然容器之上的編排系統(tǒng)已經(jīng)三足鼎立了,，各有所長了,，還有其他機會么？Rancher 嘗試了另外一個途徑,。它自己的定義是一種 IaaS,，一種基于容器的 IaaS。首先,，它通過容器降低了部署成本,，每個只需節(jié)點運行一個命令就能部署一套 Rancher 系統(tǒng)，相對于 OpenStack 這種復雜的 IaaS 來說就太容易了。其次,，它自己的定位是專門運行容器編排系統(tǒng)的 IaaS,，可以在上面一鍵部署 Kubernetes,，Docker Swarm,，Mesos。容器編排系統(tǒng),，直接運行到物理機上還是需要一些改造,，并且有升級和運維困難的問題，于是 Rancher 出來了,，希望抽象出一層非常薄的 IaaS 來解決這個問題,。 它的思路是既然現(xiàn)在三家紛爭，選哪一方都是一個艱難的決定,，那不如選 Rancher 好了,。Rancher 一方面可以讓幾種編排系統(tǒng)共存，另外一方面降低了以后的切換成本,，這個艱難的決定可以以后再做,。 另外它也推出了自己的應(yīng)用規(guī)范和應(yīng)用倉庫（App Catalogs），它的應(yīng)用規(guī)范也兼容其他的容器編排系統(tǒng)的定義文件,，相當于一個容器編排系統(tǒng)應(yīng)用的一個超集,。這樣和基礎(chǔ)設(shè)施相關(guān)的應(yīng)用可以用 Rancher 自己的規(guī)范，和業(yè)務(wù)相關(guān)的,，變化快需要動態(tài)伸縮的應(yīng)用可以放到容器編排系統(tǒng)中,，以后切換也不麻煩。 不過 Rancher 的這個產(chǎn)品假設(shè)的問題是,，假如以后容器編排調(diào)度系統(tǒng)是一家獨大,，那它的存在空間就會越來越小了。 容器平臺去向何方,？CaaS,，IaaS，PaaS,，SaaS,？有人把容器服務(wù)叫做 CaaS（Container as a Service），類似于當前 IaaS 平臺上的數(shù)據(jù)庫服務(wù)（RDB as a Service）等,，是 IaaS 之上的一種新的應(yīng)用服務(wù),。但個人認為 CaaS 其實是一個偽需求，用戶需要的并不是容器,，從來也沒有人把 IaaS 叫做 VaaS（VM as a Service）,，容器服務(wù)提供的是一種運行環(huán)境，并不是具體的服務(wù)。 容器編排調(diào)度平臺首先是一個面向開發(fā)者的的工具平臺,，它上面調(diào)度的是應(yīng)用,，這是和當前 IaaS 最大的區(qū)別。當前的 IaaS 主要面向的是管理者,，調(diào)度的是資源,，所以 IaaS 的使用入口主要是控制臺，雖然有 API,，但指令式的 API 使用復雜度要遠大于聲明式的 API,，并且 API 的使用者也多是運維工具，很少有融入業(yè)務(wù)系統(tǒng)的使用場景,。這是由當前 IaaS 云的歷史使命決定的,。云的第一步是讓用戶把應(yīng)用從自己的機房遷移到云上，只有提供可以完全模擬用戶物理機房的環(huán)境（虛擬機模擬硬件支持全功能的OS,，SDN網(wǎng)絡(luò),，云硬盤存儲），對應(yīng)用無侵入,，用戶的遷移成本才更低,。 但當這一步完成時，用戶就會發(fā)現(xiàn),，這樣雖然省去了硬件的維護成本,，但應(yīng)用的開發(fā)維護成本并沒有降低，認識到自己本質(zhì)的需求并不是資源,，而是應(yīng)用的運行環(huán)境,。這個需求有點像 PaaS，但原來的 PaaS 的問題是對應(yīng)用的侵入性太強,，并且和開發(fā)語言綁定,，能直接部署的應(yīng)用有限，用戶需要的是一種更通用的 PaaS,，可以叫（Generic Platform as a Service）,，這個詞是我生造的，就是一種基本可以部署任何復雜應(yīng)用的平臺服務(wù),，正好容器平臺可以承擔起這樣一種職責,。 容器平臺雖然都有各自的歷史背景和側(cè)重點，解決方案也不一樣,，但最終指向的目標卻是一致的,，就是屏蔽分布式系統(tǒng)的資源管理細節(jié)，提供分布式應(yīng)用的標準運行環(huán)境,，同時定義一種分布式應(yīng)用的 package,，對開發(fā)者來說降低分布式系統(tǒng)的開發(fā)成本,，對用戶來說降低分布式應(yīng)用的維護成本，對廠商來說降低分布式應(yīng)用的分發(fā)成本,?？偨Y(jié)一下，其實就是 DataCenter OS 或 Distributed OS,。DC/OS 這個詞雖然已經(jīng)被 Mesosphere 用在自己的產(chǎn)品上了,，但個人認為它是所有容器平臺的最終目標。當然,，這次容器浪潮是否能真的實現(xiàn)這個目標還不好說,，但至少現(xiàn)在看來是有希望的。 于是,， PaaS 會變成了 DCOS 之上的 devops 工具棧，當前很多 PaaS 平臺正向這個方向演進,。而 IaaS 就變成了給 DCOS 提供運行環(huán)境的服務(wù),，DCOS 接管了上層的應(yīng)用以及基礎(chǔ)服務(wù)。當然 IaaS 之上還有其他的 SaaS 模式的服務(wù)（由于 SaaS,，PaaS 的外延并沒有精確定義,，很多場景下，把面向開發(fā)者的 SaaS 模式的中間件叫做 PaaS 組件,，我的理解是通過軟件實現(xiàn)多租戶,，完全按量計費的服務(wù)都應(yīng)該屬于 SaaS，比如對象存儲,。這個要細說,，估計需要另外一篇文章，這里就不詳細分析了）,，SaaS 模式資源利用率最高,，對用戶的成本最低，用戶一般不會用獨立部署的服務(wù)去替換,。這樣一來,，格局就變成了用戶在 IaaS 之上部署一套 DCOS，需要獨立部署的服務(wù)以及自己開發(fā)的服務(wù)都運行在 DCOS 之中,，其他的能抽象成標準 SaaS 服務(wù)的中間件則優(yōu)先用 IaaS 提供的,。相當于 IaaS 將獨立部署的基礎(chǔ)設(shè)施服務(wù)，以及用戶自己的服務(wù)的部署和調(diào)度讓渡給了 DCOS,。當然,，最后 IaaS 本身是否會直接變成一種多租戶的 DCOS，由調(diào)度資源變成直接調(diào)度應(yīng)用,，也不是沒可能,，但這樣調(diào)度層會面臨非常大的壓力,，數(shù)據(jù)中心支撐的節(jié)點會受限，暫時看來兩層調(diào)度的可行性更大些,。 這對整個 IaaS 影響很大,，所以有人說對 AWS 造成威脅的可能不是 Google Cloud，而是 Kubernets（DCOS）,。但即便是 DCOS 成熟,，最后如何商業(yè)化還是有很大的變數(shù)。大家理想中的那個像 Apple 的 AppStore 的服務(wù)器端應(yīng)用市場,，最終會是由 DCOS,，SaaS，還是 IaaS 服務(wù)商提供,？DCOS 的優(yōu)勢是掌握了標準可以定義應(yīng)用規(guī)范,，SaaS 服務(wù)商的優(yōu)勢是直接面向最終用戶，可能占據(jù)企業(yè)應(yīng)用入口,，IaaS 服務(wù)商的優(yōu)勢是它掌控了應(yīng)用的運行環(huán)境,，無論在計費模式還是反盜版上都有很大優(yōu)勢。但在私有云領(lǐng)域,，IaaS 產(chǎn)品會面臨 DCOS 更大的沖擊,。私有云領(lǐng)域如果多租戶隔離的需求沒那么強烈的情況下，部署一套 DCOS 是一種更簡單高效的選擇,。 容器與虛擬機之爭從 Docker 技術(shù)成為熱門開始,，容器與虛擬機的爭論就從來沒有停止過。但去年一年,，大家的注意力逐漸轉(zhuǎn)移到上層,，容器和虛擬機的爭論算告一段落。這個主要是因為容器本身的外延在變化,。 容器,，首先它不是一個技術(shù)詞匯，它是一個抽象概念,。顧名思義,，就是裝東西的器皿，裝什么東西呢,？應(yīng)用,。 其實 J2EE 領(lǐng)域很早就使用了容器（Container）概念，J2EE 的服務(wù)器也叫做 web container 或者 application container,，它的目標就是給 Java web 應(yīng)用提供一種標準化的運行環(huán)境,，方便開發(fā)，部署,，分發(fā),，只不過這種容器是平臺綁定的,。 而 Linux 容器自誕生之初，就是一組進程隔離的技術(shù)的統(tǒng)稱,。隨著容器領(lǐng)域的競爭與演進,，Kubernetes 的 OCI （Open Container Initiative）標準推出，Docker,，Unikernels,， CoreOS 的 Rocket，Mesos 的 Universal container,，Hyper 的 HyperContainer（基于 VM 的容器解決方案） 等百花齊放,，容器的概念逐漸清晰，我們這里可以下個定義：
也就是說,，最早，大家認為容器是和虛擬機一樣的一種隔離技術(shù),，所以會拿容器和虛擬機做比較,，比較二者的隔離成本，隔離安全性,，但現(xiàn)在容器的外延變了,，和傳統(tǒng)虛擬機的本質(zhì)差異不在于封裝技術(shù)，而在于封裝的目標,，傳統(tǒng)虛擬機封裝的目標是操作系統(tǒng),，為操作系統(tǒng)提供虛擬化硬件環(huán)境，而容器封裝的目標是應(yīng)用進程,，其中內(nèi)嵌的操作系統(tǒng)只是應(yīng)用的依賴而已,。 另外一方面，基于虛擬機的調(diào)度系統(tǒng),，比如 OpenStack,，也可以將容器作為自己的調(diào)度系統(tǒng)的 compute_driver，也就是將容器當虛擬機使用,，用來降低虛擬機的隔離成本,。所以容器與虛擬機之爭本質(zhì)上是調(diào)度理念之爭，而不是隔離技術(shù)之爭,。 容器對操作系統(tǒng)的影響Docker 沒出現(xiàn)之前,，服務(wù)器端的操作系統(tǒng)基本是傳統(tǒng) Linux 大廠商的天下,，Ubuntu 好不容易通過自己的桌面版的優(yōu)勢贏得一席之地，一個創(chuàng)業(yè)公司試圖進入這個領(lǐng)域基本是沒有機會的,，但 Docker 的出現(xiàn)帶來了一個契機,。這個契機就是一個操作系統(tǒng)需要考慮自己的目標是管理硬件還是管理應(yīng)用。如果是管理硬件,，也就是運行在物理機上的操作系統(tǒng),，目標就是提供內(nèi)核，管理好硬件（磁盤,，網(wǎng)絡(luò)等）,，而應(yīng)用層的事情交給容器，這樣硬件層的操作系統(tǒng)不需要考慮各種應(yīng)用軟件棧的兼容問題,，降低了操作系統(tǒng)的維護成本,。如果是管理應(yīng)用，那就可以放棄對硬件層的管理,，專心維護軟件棧,。所以這個領(lǐng)域能冒出幾家創(chuàng)業(yè)公司的產(chǎn)品試水：
操作系統(tǒng)的演進和更替是一個長期的工程，基本上得伴隨著硬件的淘汰,，所以至少五到十年的演進,，著急不得，但可以期待,。 關(guān)于技術(shù)類創(chuàng)業(yè)的思考技術(shù)類創(chuàng)業(yè),，要思考清楚自己的機會是在市場還是在技術(shù)生態(tài)圈里占領(lǐng)一席之地。當然前者要比后者容易,，后者最終也得變?yōu)槭袌龅膽?yīng)用才能盈利,，而即便是在技術(shù)生態(tài)圈中取得地位也不一定能找到商業(yè)模式,，不過后者的潛力要大于前者。國內(nèi)的創(chuàng)業(yè)一般傾向與前者,，而國外則多傾向與后者,，所以國內(nèi)同質(zhì)化的競爭比較激烈，而在差異化的生態(tài)構(gòu)建方面則缺少建樹,。主要是因為國內(nèi)的技術(shù)積累以及普及度和國外還有差距,，還屬于追隨者，只有追隨并趕超之后才會有創(chuàng)新,，這個和 2C 領(lǐng)域的類似,，2C 領(lǐng)域最近越來越少 C2C（Copy To China） 模式成功的案例了，2B 領(lǐng)域肯定還需要些年,，不過感覺應(yīng)該也不遠,。 個人認為，2017 年容器編排調(diào)度領(lǐng)域的競爭會上升到應(yīng)用層面,，DCOS 之上的多語言應(yīng)用框架（比如 微服務(wù)框架,，Actor 模型框架），各種已有應(yīng)用和基礎(chǔ)設(shè)施的容器化,，標準化,，讓已有應(yīng)用變?yōu)樵圃–loud Native）應(yīng)用，等等,。 當然,，理想和現(xiàn)實之間是有鴻溝的。一波一波的技術(shù)變革,，本質(zhì)上其實都是在試圖將開發(fā)和運維人員從瑣碎的，重復的,，無聊的任務(wù)中解放出來,，專注于有創(chuàng)意的領(lǐng)域。但變革最難變革的是人的思維方式和做事習慣,，以及應(yīng)對來自組織的阻礙,。你說云應(yīng)該就是按需的，動態(tài)的,，自服務(wù)的,，但用戶的運維部門就喜歡審批開發(fā)人員資源申請，于是云變成了一個虛擬機分配系統(tǒng),。你說資源應(yīng)該動態(tài)調(diào)度,，應(yīng)用混合部署有利于提高資源利用率，但用戶的安全部門要求應(yīng)用的業(yè)務(wù)必須分層,，每層必須需要部署到獨立的服務(wù)器上,，跨層調(diào)用的端口還需要申請,。所以技術(shù)變革最后要落地成商業(yè)模式，首先要通過技術(shù)理念的傳播去改變用戶的思維方式以及組織體系,，當然這肯定不可能是一蹴而就的,，是一個長期的，反復過程,，其次要等待業(yè)務(wù)需求的驅(qū)動,，當業(yè)務(wù)增長導致軟件復雜度到一定規(guī)模的時候，自然會尋求新技術(shù)來解決復雜性,。 結(jié)語寫了這么多,，有人會問，我還是沒能確定到底選擇哪一家合適??？未來是不可預測的，但是可以創(chuàng)造的,。當你做出選擇的那一刻,，你希望的未來就向你靠近了一步。 想更多了解容器及相關(guān)技術(shù),，可掃碼訂閱王淵命個人公眾號「午夜咖啡」,，其定位是「工具 · 架構(gòu) · 成長 · 思考」，不但有深度的技術(shù)文章,，也有對社會事件分析及個人成長的思考,。 |
|
|
