從Docker的轉(zhuǎn)變，談容器生態(tài)與微服務(wù)的發(fā)展

編者按：容器技術(shù)目前已經(jīng)成為技術(shù)圈內(nèi)的“常識(shí)”，但是容器生態(tài)能否健康發(fā)展仍然任重道遠(yuǎn)。在收獲最初的贊揚(yáng)之后，領(lǐng)軍者 Docker 如今身陷非議：2016 年執(zhí)意壯大發(fā)展 Swarm 進(jìn)軍編排領(lǐng)域，似乎 Docker 公司一方面惹毛了很多強(qiáng)勁的編排領(lǐng)域玩家，另一方面也并沒(méi)有收獲預(yù)料之中的成果。12月14日，Docker 計(jì)劃將其關(guān)鍵容器運(yùn)行模塊之一 Containerd 貢獻(xiàn)給開(kāi)源社區(qū)。

在周暉先生看來(lái)，這意味著 Docker 的重心將回歸到容器技術(shù)本身，或已放緩其在編排領(lǐng)域的步伐。一直從事 PaaS 和容器技術(shù)研究的周先生還認(rèn)為，不管怎樣，Docker 都是一家有著特色的優(yōu)秀公司，Docker 成功地將容器技術(shù)理念深入人心，并且也增加了業(yè)界對(duì) PaaS 的認(rèn)識(shí)和信心。以下文章來(lái)自于 InfoQ 對(duì) Pivotal 大中華區(qū)云計(jì)算首席架構(gòu)師周暉的采訪整理。

誕生與興起：Docker 贏得聲譽(yù)

容器技術(shù)被傳頌并深入人心，是因?yàn)?nbsp;Docker；但是，其實(shí)技術(shù)積累由來(lái)已久，早期的容器技術(shù)是 Google、IBM 等公司貢獻(xiàn)出來(lái)的，Pivotal 也發(fā)展了 Warden 容器技術(shù)，這些公司都專(zhuān)注于在各自的常規(guī)業(yè)務(wù)中，并沒(méi)有重點(diǎn)投入容器技術(shù)；而 Docker 很好地將容器技術(shù)單獨(dú)形成項(xiàng)目產(chǎn)品推向社區(qū)。

為什么有同樣技術(shù)潛力的公司，會(huì)有如此迥異的產(chǎn)品決策？我認(rèn)為是因?yàn)橹埸c(diǎn)不一樣或者說(shuō)基因不同，大公司著眼于規(guī)?；钠髽I(yè)應(yīng)用，比如 Pivotal 把容器技術(shù)內(nèi)置在 PaaS 技術(shù)中，然后以完整的解決方案的形式提供出來(lái)。結(jié)合自身例子來(lái)看，其實(shí) Warden 比 Docker 早，但是 Pivotal 從成立的第一天起，就是面向企業(yè)級(jí)的，產(chǎn)品代碼模塊很完整，Warden 容器的代碼量很可能少于整體 Cloud Foundry 的千分之一，單獨(dú)拿出來(lái)對(duì)企業(yè)客戶(hù)意義不大，并且目標(biāo)客戶(hù)也不需要知道那么底層的技術(shù)細(xì)節(jié)，他們需要更專(zhuān)注于業(yè)務(wù)創(chuàng)新。

而 Docker 公司具有開(kāi)發(fā)者基因：Docker 的產(chǎn)品很適合開(kāi)發(fā)者，快速升級(jí)以滿(mǎn)足新的功能需求，完全不用管和前面版本的兼容性，就像有故障重啟 Windows 那么簡(jiǎn)單，但是你讓客戶(hù)去重啟他們生產(chǎn)系統(tǒng)的 Linux 就不會(huì)那么輕易了，并且 Docker 對(duì)開(kāi)發(fā)者簡(jiǎn)單易用。Cloud Foundry 提供的容器是黑盒子，對(duì)運(yùn)維人員來(lái)說(shuō)簡(jiǎn)單易用，無(wú)需關(guān)注容器細(xì)節(jié)，甚至都不需要直接操作容器；而 Docker 是白盒子，隨意增添組合特性，對(duì)于技術(shù)fans 很有價(jià)值。同樣 Docker 也有很多很棒的設(shè)計(jì)，舉例說(shuō)明，鏡像倉(cāng)庫(kù)，誰(shuí)都可以把自己做好的 Docker 鏡像上傳上去，目前Docker的鏡像倉(cāng)庫(kù)有海量的鏡像，這符合互聯(lián)網(wǎng)的分享精神并因此發(fā)展壯大。所以 Docker 之所以發(fā)展起來(lái)，可以說(shuō)他摸到了市場(chǎng)的脈絡(luò)。

因此除了自身優(yōu)秀和容器界技術(shù)成熟之外，另外一個(gè)因素是 Docker 生逢其時(shí)。2013年Docker 誕生之時(shí)，正值企業(yè)應(yīng)用轉(zhuǎn)向互聯(lián)網(wǎng)應(yīng)用高速發(fā)展時(shí)期，應(yīng)用小型化微服務(wù)化的需求正好是其用武之地，也就是適應(yīng)了今天流行面更廣的微服務(wù)的一個(gè)方面---應(yīng)用部署到容器中運(yùn)行。

變形發(fā)展：急于盈利，引起生態(tài)圈的利益沖突

Docker 在2016這一年做了讓生態(tài)圈反感的事情：通過(guò)之前收購(gòu)一些公司大張旗鼓地發(fā)展 Swarm，集中發(fā)力集群編排管理。

容器生態(tài)中有兩個(gè)領(lǐng)域：一類(lèi)是容器本身的領(lǐng)域，另外一類(lèi)編排集群管理領(lǐng)域。這兩個(gè)領(lǐng)域雖然會(huì)有重疊的部分不完全獨(dú)立，但是基本上各有各的發(fā)展方向，靶向用戶(hù)不同。

第一領(lǐng)域是 Docker 最開(kāi)始在做的內(nèi)容，面向開(kāi)發(fā)者、小型企業(yè)或者個(gè)人版嘗試測(cè)試，直接應(yīng)用在大型企業(yè)中的還是比較少，最多是一個(gè)部門(mén)級(jí)別的應(yīng)用（數(shù)量級(jí)一般為個(gè)位數(shù)）；用于開(kāi)發(fā)和測(cè)試，在生產(chǎn)中用的比較少（設(shè)計(jì)時(shí)也沒(méi)有考慮到生產(chǎn)的復(fù)雜性）。

第二領(lǐng)域的領(lǐng)軍代表是 Mesos、Kubernetes 和 Cloud Foundry，或者說(shuō)現(xiàn)在的 CaaS。在企業(yè)中的應(yīng)用，這個(gè)派系更適合做成云，管理的是大規(guī)模的應(yīng)用運(yùn)行生產(chǎn)環(huán)境。

兩者的定位是不一樣的，但是第二類(lèi)集群管理具有更多、更早的盈利空間；經(jīng)過(guò)多輪融資后的 Docker 對(duì)盈利愿望比較強(qiáng)烈，因?yàn)槿萜鞅旧黹_(kāi)源很難掙錢(qián)，都是不掏錢(qián)的客戶(hù)，所以希望打入企業(yè)級(jí)的容器集群管理市場(chǎng)來(lái)盈利?？墒?Swarm 等一系列舉動(dòng)被視為捆綁競(jìng)爭(zhēng)，非但沒(méi)有讓人對(duì)其技術(shù)刮目相看，反而損還他與生態(tài)圈內(nèi)其他廠商的關(guān)系。在今年7月底，Google Kubernetes 布道師 Kelsey Hightower 和 Docker的 CTO Solomon Hykes在 Twitter 上發(fā)生了激烈爭(zhēng)論，爭(zhēng)論的主題是要不要用 RunC 或其他容器來(lái)取代 Docker 引擎以及 OCI 的意義。

被迫妥協(xié)：共同研發(fā)的 RunC 意味著什么？

Docker 一開(kāi)始就一家獨(dú)大，并且并不是一種開(kāi)放的態(tài)姿態(tài)在做，所以很早之前 Google 就投資了 CoreOS 來(lái)做競(jìng)爭(zhēng)的容器--Rocket。那時(shí)是三家鼎立：Docker/Rocket/Warden，為了避免慘烈的競(jìng)爭(zhēng)，大家終于統(tǒng)一意見(jiàn)，決定成立 OCI 做統(tǒng)一的容器運(yùn)行時(shí)---RunC，OCI 成立后加入了大約50家廠商。出于對(duì) Docker 封閉化商業(yè)式發(fā)展的擔(dān)心，OCI 商討出這種方案：以 RunC 為核心重新構(gòu)建生態(tài)圈，并且通過(guò)插件來(lái)弱化容器在 CaaS 生態(tài)圈的重要性。

OCI 負(fù)責(zé)的 RunC 是非常小的運(yùn)行核，其目的在于提供一個(gè)干凈簡(jiǎn)單的運(yùn)行環(huán)境，他就是負(fù)責(zé)隔離 CPU、內(nèi)存、網(wǎng)絡(luò)等形成一個(gè)運(yùn)行環(huán)境，可以看作一個(gè)小的操作系統(tǒng)：現(xiàn)在 OCI 只負(fù)責(zé)這些，尚未擴(kuò)大到更大的范圍，其實(shí)這樣是小而美的，這樣的是業(yè)界所最需要的。

當(dāng)然， RunC 的生態(tài)發(fā)展就會(huì)局限在企業(yè)級(jí)別應(yīng)用中，并因此具有不同的發(fā)展目標(biāo)：RunC 不是要提供多少種工具，而是要非常穩(wěn)定。 接下來(lái)需要做的是可能是添加完善一些功能，比如將 Docker 鏡像導(dǎo)進(jìn)來(lái)，與各種插件更好地結(jié)合（動(dòng)態(tài)化即插即用），熱啟動(dòng)和遷移。這些功能是企業(yè)需要的，但是對(duì)開(kāi)發(fā)者沒(méi)什么作用。以熱遷移為例，從一臺(tái)虛擬機(jī)遷移到另外一臺(tái)虛擬機(jī)，但是開(kāi)發(fā)者可能本來(lái)就一臺(tái)機(jī)器并沒(méi)有這個(gè)需要。

因?yàn)?nbsp;RunC 是 Docker 的一個(gè)子集，所以單純從代碼量上來(lái)講，RunC 只占 Docker 的百分之幾。相比而言，Docker 有豐富工具，更貼近于開(kāi)發(fā)者。這也是為什么很多個(gè)人開(kāi)發(fā)者并不知道 RunC，因?yàn)镽unC的使用者都是 Mesos、K8S 和 Cloud Foundry 這類(lèi) CaaS 廠商。

在 RunC 早期，Docker 是主要貢獻(xiàn)者（在我看來(lái)，如果 Docker 不參與 RunC 的發(fā)展就意味著和容器生態(tài)圈決裂）；后來(lái)隨著各大廠商對(duì) RunC 大幅貢獻(xiàn)代碼，RunC 的代碼貢獻(xiàn)者越來(lái)越多樣化，Docker 所占比例在持續(xù)下降。通過(guò)不斷迭代，RunC 一定會(huì)越來(lái)越成熟，它已經(jīng)在生產(chǎn)環(huán)境中開(kāi)始積累技術(shù)了，Cloud Foundry 已經(jīng)有不少全球重量級(jí)客戶(hù)在用內(nèi)置 RunC 容器，經(jīng)歷的很多坑的 bug 修補(bǔ)已經(jīng)回饋到 RunC 源碼中去了。

Docker 的運(yùn)行內(nèi)核雖然是從 1.11 支持 RunC 的，但是 Docker 的心態(tài)是很復(fù)雜的：一方面作為 OCI 成員必須支持 RunC，但是另一方面他會(huì)擔(dān)心 RunC 對(duì) Docker 的替代的威脅。

危機(jī)解讀： 適合Docker公司的路在何方？

坦率而言，我認(rèn)為 Docker 進(jìn)軍編排界并沒(méi)有優(yōu)勢(shì)，因?yàn)樗狈ζ髽I(yè)級(jí)基因。

Docker 更適合在容器本身的技術(shù)，今年 Docker 力推 Swarm，把資源花在了集群管理上，這其實(shí)并不是 Docker 技術(shù)的初心。當(dāng)時(shí) Docker 迅速流行是因?yàn)楹?jiǎn)單易用，而后來(lái)走卻想把太多東西塞到 Docker 中。

在從目前適用場(chǎng)景選擇來(lái)看，一般而言，使用 Docker Swarm 的都是小企業(yè)的小規(guī)模應(yīng)用，而大企業(yè)采用的都是 Mesos、K8S 或 Cloud Foundry。（當(dāng)然有極少的案例采用了 Docker 的 Swarm，但是從比例而言這并不具普遍性）。因?yàn)樽畛醯脑O(shè)計(jì)來(lái)源就不一樣，前者是從開(kāi)發(fā)者角度設(shè)計(jì)，而 Mesos、K8S 和 Cloud Foundry 是從企業(yè)中來(lái)，有很多企業(yè)運(yùn)維的實(shí)戰(zhàn)積累。

Docker 也就是小幾百人的公司，并不算巨頭公司，做企業(yè)級(jí)市場(chǎng)比較吃力，而做中小企業(yè)或是個(gè)人用戶(hù)市場(chǎng)這種思路更適合 Docker 的盈利模式。在我看來(lái)，不論國(guó)內(nèi)國(guó)外，做企業(yè)級(jí)市場(chǎng)一定需要很多銷(xiāo)售去和企業(yè)用戶(hù)打交道聊需求，項(xiàng)目實(shí)施的時(shí)候往往要根據(jù)客戶(hù)的需求做定制，要知道每個(gè)企業(yè)用戶(hù)的需求是不一樣的，沒(méi)有辦法進(jìn)行完全統(tǒng)一的標(biāo)準(zhǔn)化，那定制化的需求就需要一定規(guī)模的人力投入，每個(gè)項(xiàng)目都需要一定的人員資源投入，小公司很難做這種投入。在我看來(lái)，小作坊做企業(yè)用戶(hù)還是面臨很大的挑戰(zhàn)。

從企業(yè)級(jí)需求來(lái)看，比如企業(yè)一個(gè)考慮就是，一定要前后版本兼容，否則就無(wú)法升級(jí)。而這恰恰是 Docker 不 care，比如個(gè)人用戶(hù)可以隨時(shí)重啟機(jī)器，開(kāi)發(fā)者在遇到問(wèn)題可以重啟，在企業(yè)級(jí)的思路不是這樣的。Docker 的思路并不是做企業(yè)級(jí) IT 應(yīng)用系統(tǒng)的思路，所以如果應(yīng)用到企業(yè)級(jí)應(yīng)用中一定會(huì)遇到問(wèn)題。至于很多互聯(lián)網(wǎng)公司在應(yīng)用 Docker，很多互聯(lián)網(wǎng)公司也是在摸索，包括自己做 Docker 集群管理的不少，但自己做 Docker 集群管理的基本都開(kāi)始開(kāi)始轉(zhuǎn)向 K8s、Cloud Foundry、Mesos 這些專(zhuān)業(yè)的容器集群管理軟件了，這是很明顯的趨勢(shì)，那么這些互聯(lián)網(wǎng)企業(yè)當(dāng)初花資源做的集群管理基本就是被廢棄，即使現(xiàn)在沒(méi)轉(zhuǎn)的遲早要轉(zhuǎn)型到 CF(Cloud Foundry) / K8s / Mesos。對(duì)于企業(yè)客戶(hù)來(lái)說(shuō)，這種試錯(cuò)是得不償失的，因?yàn)槠髽I(yè)客戶(hù)沒(méi)有這么多人去研究開(kāi)發(fā)容器集群管理軟件。但對(duì)互聯(lián)網(wǎng)公司來(lái)說(shuō)，這個(gè)試錯(cuò)是可以接受的，畢竟養(yǎng)這么多工程師其中有一部分就是通過(guò)不斷的、或大或小的試錯(cuò)而優(yōu)化技術(shù)的。

Docker 為什么最初發(fā)展那么快，因?yàn)槭敲嫦蜷_(kāi)發(fā)者，個(gè)人用戶(hù)或者中小企業(yè)，這是他興旺起來(lái)的市場(chǎng)。起步于個(gè)人消費(fèi)者市場(chǎng)，卻又想立刻切入企業(yè)級(jí)市場(chǎng)必然會(huì)有很多水土不服，這種背離最初的起源的做法并不是很明智，我認(rèn)為面向個(gè)人消費(fèi)者其實(shí)才是 Docker 的固有基因。

那怎樣才是 Docker 更好的盈利模式呢？在我看來(lái)，Docker 可以在鏡像倉(cāng)庫(kù)上發(fā)力，做成類(lèi)似蘋(píng)果 AppStore 的模式。Docker的優(yōu)勢(shì)在于他有鏡像的入口(互聯(lián)網(wǎng)最關(guān)注的幾個(gè)價(jià)值點(diǎn)之一)，他應(yīng)該把鏡像市場(chǎng)運(yùn)營(yíng)好，第三方在使用鏡像的時(shí)候進(jìn)行付費(fèi)。比如 MySQL 鏡像，網(wǎng)上不說(shuō)一萬(wàn)種也有一千種；但是哪個(gè)鏡像好用還真考驗(yàn)用戶(hù)，如果用戶(hù)用的不好，也沒(méi)有反應(yīng)并改進(jìn)的渠道，其實(shí)這樣也不利于 MySQL 鏡像的持續(xù)發(fā)展，如果 Docker 能夠?qū)ψ约簜}(cāng)庫(kù)市場(chǎng)的高質(zhì)量 MySQL 鏡像收費(fèi)，然后分成給做 MySQL 鏡像的公司，做 MySQL 鏡像的公司也可以根據(jù)客戶(hù)的反饋進(jìn)行不斷優(yōu)化，做到生產(chǎn)可用；那么用戶(hù)應(yīng)該是樂(lè)意付租金費(fèi)用的，畢竟自己花費(fèi)成本做一個(gè)生產(chǎn)可用的 MySQL 鏡像成本不低，這有很大的經(jīng)濟(jì)價(jià)值。Docker 可以與 MySQL 等廠商進(jìn)行利潤(rùn)分成的模式擴(kuò)展，就比較容易盈利了。

迷途知返：Docker 公司重拾初心？

經(jīng)過(guò)激烈的碰撞，現(xiàn)在 Docker 又回歸到自己擅長(zhǎng)的老本行中，將視線從編排界收回到容器技術(shù)。

1、Containerd 的開(kāi)源

12月13日，Docker 開(kāi)源了Containerd(https://containerd.io)，它是為 RunC 提供接口并進(jìn)行鏡像的管理。非常有意思的是 Docker 沒(méi)有把 Containerd 貢獻(xiàn)給 Apache/Linux 之類(lèi)的基金會(huì)，或是直接貢獻(xiàn)給 RunC，而是單獨(dú)開(kāi)源，這個(gè)態(tài)度很是微妙，體現(xiàn)了對(duì) RunC一定的防范，目前有 AWS、Google，IBM、Microsoft 和阿里云等作為初始成員，會(huì)為項(xiàng)目提供貢獻(xiàn)和維護(hù)人員。 我對(duì)這個(gè)舉措解讀為 Docker 對(duì)容器技術(shù)的回歸，并且是對(duì)16年?duì)幷摰恼壑?，他希望生態(tài)更加開(kāi)放，更良性的發(fā)展，降低業(yè)界對(duì) Docker 封閉的擔(dān)心，同時(shí)也是通過(guò) Containerd 作為橋梁，讓大家更多地關(guān)注回 Docker，抵消因?yàn)樯鷳B(tài)分裂對(duì)Docker 帶來(lái)的不利影響。

在我看來(lái)，這其實(shí)也不失為一種對(duì) RunC 的堤防措施，讓大家在使用 RunC 同時(shí)也不忘記 Docker；開(kāi)源的舉措也可以一定程度緩和關(guān)系（不過(guò)，我認(rèn)為 Docker 并不會(huì)把Containerd 交給 RunC 方運(yùn)營(yíng)）。

2、DataCenter “錢(qián)”途未卜

今年年初的時(shí)候做了 DDC （Docker Data Center），其目的是為了向客戶(hù)收費(fèi)。但是，目前無(wú)法找到這個(gè)項(xiàng)目的營(yíng)收數(shù)字，單從 DDC 和 Docker 開(kāi)源部分來(lái)說(shuō)，沒(méi)有太大的差別，商業(yè)價(jià)值還無(wú)法確認(rèn)。

3、與阿里云合作的全面合作

Docker 選擇重量級(jí)的公司合作其實(shí)是一個(gè)明智的選擇，雖然這對(duì)做 Docker 鏡像倉(cāng)庫(kù)公有服務(wù)的小公司確實(shí)不是好消息。大公司的好處有人力和財(cái)力，而且 Docker 的商務(wù)版(DDC)未來(lái)要放在國(guó)內(nèi)公有云上，阿里有這樣的基礎(chǔ)設(shè)施，可以在初期承受大量客戶(hù)免費(fèi)試用的投入，在 IaaS 公有云生產(chǎn)級(jí)別也更可靠。

當(dāng)然，有人歡喜有人憂(yōu)，此番合作還意味著：Container as a Service 公有云的市場(chǎng)就已經(jīng)定型了，做 Docker 鏡像倉(cāng)庫(kù)公有市場(chǎng)對(duì)創(chuàng)業(yè)公司關(guān)閉了。

4、Swarm 還會(huì)繼續(xù)，但前景不明

Docker 還會(huì)把 Swarm 繼續(xù)支持下去，但是編排領(lǐng)域的有很多細(xì)分的市場(chǎng)，Swarm 的發(fā)展目標(biāo)應(yīng)該會(huì)是小規(guī)模的集群；而且 Docker 的發(fā)展重心還是會(huì)回到容器本身，因?yàn)橹挥芯珜?zhuān)容器本身技術(shù)，才會(huì)凸顯 Docker 獨(dú)特的優(yōu)勢(shì)。做編排的話，從社區(qū)熱度、貢獻(xiàn)人數(shù)、發(fā)布頻率可以看出，Swarm 應(yīng)該是會(huì)被其他競(jìng)爭(zhēng)對(duì)手的光環(huán)所淹沒(méi)。

Docker 重新考慮在做的就是揚(yáng)長(zhǎng)避短：既然短處不能補(bǔ)成長(zhǎng)處，那么就需要回歸繼續(xù)發(fā)揚(yáng)長(zhǎng)處。

避免競(jìng)爭(zhēng)誤入歧途，容器生態(tài)仍有藍(lán)海

上文提到了 Docker 與阿里云合作對(duì)國(guó)內(nèi)一些創(chuàng)業(yè)公司造成了影響。我還想談?wù)勎覍?duì)容器創(chuàng)業(yè)的一些建議：首先我不認(rèn)為在 Docker 之上進(jìn)行定制出 CaaS 是有市場(chǎng)做法，創(chuàng)業(yè)公司如果一定要局限于 Docker 創(chuàng)業(yè)，可以考慮在 Docker 生態(tài)圈中，還有那些技術(shù)空白點(diǎn)，然后專(zhuān)攻一點(diǎn)成為特色（這是國(guó)外容器創(chuàng)業(yè)公司常見(jiàn)的做法，Docker 也收購(gòu)了很多此類(lèi)的優(yōu)秀公司）。

那么容器生態(tài)的創(chuàng)業(yè)還有哪些藍(lán)海領(lǐng)域呢？除了上文提到的容器類(lèi)技術(shù)和編排集類(lèi)，其實(shí)還有插件技術(shù)，這可以看做是兩者的交集部分。插件技術(shù)是很多樣化的，比如網(wǎng)絡(luò)、存儲(chǔ)，并且有很大的發(fā)展?jié)摿ΑＨ萜鞯母黝?lèi)插件在2017年將會(huì)有較大、較快的發(fā)展，這塊目前還屬于拓荒地帶，經(jīng)常可以看到技術(shù)進(jìn)展，比如存儲(chǔ)插件就超過(guò)10類(lèi)，而且很不成熟，如果能做統(tǒng)一化或是成熟后、簡(jiǎn)化，都可以成為很有價(jià)值的技術(shù)。以網(wǎng)絡(luò)插件為例，Docker 有 CNM 標(biāo)準(zhǔn)，CoreOS、Mesos、Cloud Foundry 有 CNI 標(biāo)準(zhǔn)，當(dāng)然這兩種標(biāo)準(zhǔn)從技術(shù)上講還是有很多不兼容的地方，接下來(lái)的發(fā)展是兼容還是統(tǒng)一，還是一強(qiáng)一弱導(dǎo)致弱勢(shì)方自然淘汰，需要走一步看一步。而至于存儲(chǔ)，目前主要由很多存儲(chǔ)廠商主導(dǎo)，根據(jù)自己的存儲(chǔ)特性研發(fā)的存儲(chǔ)插件，種類(lèi)多且復(fù)雜，在何種情況下使用何種插件很考驗(yàn)用戶(hù)對(duì)存儲(chǔ)插件的理解能力。這些外圍的插件還有較大的發(fā)展空間。

容器集群也還有很大的發(fā)展空間，集群的概念和應(yīng)用集群微服務(wù)化剛剛興起，在實(shí)際生產(chǎn)中會(huì)發(fā)現(xiàn)還有很多問(wèn)題需要解決：比如功能尚不完善、可靠性和穩(wěn)定性有待提高。

那插件為什么目前還不是 OCI 標(biāo)準(zhǔn)所關(guān)注的呢？OCI 目前關(guān)注的是 RunC，以一個(gè)更小的核心給業(yè)界；而插件是 RunC 補(bǔ)充，提供了很好擴(kuò)展方式：RunC 作為運(yùn)行環(huán)境，很多環(huán)境是不需要插件就可以運(yùn)行，比如大部分的 Java/Web 微服務(wù)應(yīng)用，反倒是傳統(tǒng)應(yīng)用容器化，需要用到插件，但這類(lèi)應(yīng)用并不是容器化的最主流應(yīng)用,是典型的1：9現(xiàn)象。就是90%的容器應(yīng)用不需要插件，10%的應(yīng)用需要插件，但是插件帶來(lái)相當(dāng)大的復(fù)雜性。應(yīng)用容器化只須在需要哪種功能時(shí)就使用哪種相應(yīng)的插件即可。不過(guò)目前各個(gè)廠商對(duì)插件的定義和理解并不完全一樣，除去共識(shí)的網(wǎng)絡(luò)、存儲(chǔ)等插件，其他的尚模糊。比如 Docker 對(duì)插件有自己的理解，哪些是插件，是否放到運(yùn)行環(huán)境里面；Mesos 對(duì)插件的解讀范圍就更廣，所以將插件標(biāo)準(zhǔn)化的想法在我看來(lái)還是不太容易。

但是，對(duì)于網(wǎng)絡(luò)插件，業(yè)界認(rèn)識(shí)都比較統(tǒng)一，因?yàn)槭瞧毡樾枨?，并且?yīng)用的多是VPN隧道技術(shù)。如果對(duì)這類(lèi)插件進(jìn)行統(tǒng)一標(biāo)準(zhǔn)化，可以便于相互之間的通用。

另外，為什么不建議小型創(chuàng)業(yè)公司考慮企業(yè)級(jí)的完整版 CaaS？和 Docker 的情況類(lèi)似，這需要有企業(yè)技術(shù)經(jīng)驗(yàn)積累、規(guī)?；肆拓?cái)力的持續(xù)投入。舉個(gè)例子，在某次競(jìng)標(biāo)，一家銀行在招標(biāo)，當(dāng)時(shí)的要求就是廠商可以自我證明可以存活三年，說(shuō)明企業(yè)客戶(hù)對(duì)創(chuàng)業(yè)公司能否存活三年還是有疑慮的。

Docker興起，加力了 PaaS 的推廣

Docker 到來(lái)前，PaaS 主要在企業(yè)級(jí)市場(chǎng)，并不為公眾所知。PaaS 分成公有云和私有云市場(chǎng)。國(guó)內(nèi)公有 PaaS 云市場(chǎng)的很多廠商基本上成為了先烈，主要問(wèn)題在持續(xù)投資無(wú)法實(shí)現(xiàn)正向現(xiàn)金流，因?yàn)楸藭r(shí) PaaS 主要面向開(kāi)發(fā)者，向開(kāi)發(fā)者收費(fèi)有難度，而向開(kāi)發(fā)者/中小企業(yè)提供 IaaS 的市場(chǎng)則發(fā)展比較好。不同的是，國(guó)外最早 Heroku 、Salesforce 等在做公有云的 PaaS 比較成功，在比較長(zhǎng)時(shí)間的實(shí)踐中積累了很多 PaaS 的模型和經(jīng)驗(yàn)，后來(lái) Cloud Foundry 當(dāng)時(shí)也吸取了當(dāng)時(shí)兩者很多很好的實(shí)踐經(jīng)驗(yàn)。

Docker 的流行促進(jìn)了大家對(duì) PaaS 的認(rèn)知，當(dāng)然也有了 CaaS 的興起（如果進(jìn)行更嚴(yán)格的定義的話，Docker 是屬于 CaaS 的），把 PaaS 從企業(yè)級(jí)市場(chǎng)的認(rèn)知擴(kuò)展到了開(kāi)發(fā)者市場(chǎng)。很多人是先接受并理解了Docker，才開(kāi)始關(guān)注思考 PaaS。這是因?yàn)?nbsp;PaaS 只是針對(duì)企業(yè)級(jí)用戶(hù)，很難形成普遍的知名度；而Docker是面向開(kāi)發(fā)者的，開(kāi)發(fā)者使用了 Docker 之后向團(tuán)隊(duì)推薦，團(tuán)隊(duì)再向上層同步信息，是一種自下而上的傳播。

私有云市場(chǎng)的 PaaS 最早是互聯(lián)網(wǎng)公司在無(wú)意識(shí)的做，后來(lái)Pivotal進(jìn)入市場(chǎng)，逐步定義了 PaaS 完整的架構(gòu)，我們最早的商業(yè)客戶(hù)是在 2013 年底，那時(shí)Pivotal需要向客戶(hù)從 0 開(kāi)始講解私有云的概念，而現(xiàn)在對(duì)于技術(shù) fans 的客戶(hù)，只需要說(shuō) PaaS 是在 Docker 的基礎(chǔ)上做了那些技術(shù)工作即可。

放眼未來(lái)，PaaS 和 CaaS 可以各自輝煌

PaaS 和 CaaS 兩者有重合的部分，但是也有不同的側(cè)重：CaaS 是提供一個(gè)容器，里面是跑應(yīng)用跑數(shù)據(jù)庫(kù)等都可以；而 PaaS 更關(guān)注的是應(yīng)用，要對(duì)應(yīng)用進(jìn)行監(jiān)控，要有應(yīng)用框架、通用的應(yīng)用功能如 Session 集中管理、日志服務(wù)、路由服務(wù)等。

PaaS 通過(guò)構(gòu)建包來(lái)一鍵部署應(yīng)用，這樣的做法極大的簡(jiǎn)化了應(yīng)用的安裝部署，也是遵循DevOps 的理念。相反，Docker 讓開(kāi)發(fā)者去寫(xiě)復(fù)雜的腳本部署應(yīng)用，比如目前DockerFile 和 Docker Compose，這對(duì)于開(kāi)發(fā)者而言很痛苦乃至不可行的環(huán)節(jié)，這要求的不是業(yè)務(wù)編碼技能，而是對(duì)應(yīng)用服務(wù)器、對(duì)操作系統(tǒng)腳本的編程技能。CaaS 不限于應(yīng)用平臺(tái)，它也不專(zhuān)注于解決應(yīng)用平臺(tái)問(wèn)題，所以它也不善于解決應(yīng)用平臺(tái)的問(wèn)題。

和 CaaS 不同， PaaS（Heroku、Cloud Foundry等）把應(yīng)用相關(guān)的復(fù)雜度屏蔽，只需一鍵部署應(yīng)用即可運(yùn)行起來(lái)，無(wú)需關(guān)注應(yīng)用環(huán)境的安裝環(huán)節(jié)，還有應(yīng)用故障自動(dòng)恢復(fù)、自動(dòng)彈性伸縮、灰度發(fā)布等使得應(yīng)用運(yùn)維可以全自動(dòng)化?；氐?Docker 而言，其實(shí)它對(duì)DevOps 仍然有一定難度：Dockerfile / Compose 的書(shū)寫(xiě)一般是運(yùn)維人員在做的事情，而Docker鏡像打好了需要交給開(kāi)發(fā)人員，并沒(méi)有辦法做的很完美，很多地方?jīng)]有辦法完全固定，比如開(kāi)發(fā)人員發(fā)現(xiàn)需要更改一個(gè)應(yīng)用服務(wù)器的端口這么簡(jiǎn)單的一件事情，這可能就涉及到一系列的腳本的改寫(xiě)，但這個(gè)事情到底是運(yùn)維人員來(lái)做還是開(kāi)發(fā)人員來(lái)做？運(yùn)維人員來(lái)做那就不是 DevOps 了，如果開(kāi)發(fā)人員來(lái)做，開(kāi)發(fā)人員又很難具備運(yùn)維人員的腳步編程技巧。而這一點(diǎn) Heroku 和 Cloud Foundry 已經(jīng)注意到了，并通過(guò)構(gòu)建包徹底分離了運(yùn)維人員和開(kāi)發(fā)人員的分工。

我們看 PaaS / CaaS 的區(qū)別和各自的市場(chǎng)，PaaS 的思路基于應(yīng)用平臺(tái)，而 CaaS 并不限于應(yīng)用平臺(tái)，因此它也并不能理解應(yīng)用平臺(tái)的問(wèn)題；所以?xún)烧呙鎸?duì)的市場(chǎng)還不太一樣，如果著眼于應(yīng)用平臺(tái)那 PaaS 比較好，如果是希望把各種資源管理起來(lái)，當(dāng)做虛機(jī)使用，通過(guò)容器實(shí)現(xiàn)，那 CaaS 比較好。

關(guān)于 Docker 和微服務(wù)

我認(rèn)為將 Docker 等同于微服務(wù)是一個(gè)誤導(dǎo)性的看法。微服務(wù)由兩個(gè)組成部分：運(yùn)行環(huán)境（運(yùn)行于容器中是很好的運(yùn)行環(huán)境的選擇），開(kāi)發(fā)框架（比如服務(wù)動(dòng)態(tài)注冊(cè)、發(fā)現(xiàn)和調(diào)用等）。業(yè)內(nèi)很多人只重視到了第一部分，而忽略了第二部分，比如 Docker 微服務(wù)化最常見(jiàn)的就是微服務(wù)的動(dòng)態(tài)發(fā)現(xiàn)和調(diào)用則幾乎完全依靠第三方平臺(tái)來(lái)實(shí)現(xiàn)，如 ZooKeeper、Consul 等，但是這些工具的缺點(diǎn)是當(dāng)集群達(dá)到一定量之后就會(huì)出現(xiàn)不穩(wěn)定的問(wèn)題，而且平臺(tái)要適應(yīng)各種代碼需求有困難，我認(rèn)為程序的事情歸程序來(lái)解決，而不是平臺(tái)。最佳實(shí)踐是采用程序框架從根本上解決問(wèn)題，比如 Netflix 就進(jìn)行了徹底的改造，他們的服務(wù)注冊(cè)、發(fā)現(xiàn)、治理、限流都是通過(guò)程序框架(也即后來(lái)的 Spring Cloud )來(lái)實(shí)現(xiàn)的，經(jīng)受了大規(guī)模的應(yīng)用考驗(yàn)。用平臺(tái)解決代碼層面問(wèn)題是有缺陷的，因?yàn)槠脚_(tái)解決的是平臺(tái)問(wèn)題，不能包攬代碼的工作；代碼框架是解決代碼的問(wèn)題：服務(wù)注冊(cè)發(fā)現(xiàn)更適合在代碼層面實(shí)現(xiàn)。

當(dāng)然，微服務(wù)還有一個(gè)更關(guān)鍵的問(wèn)題：如何對(duì)服務(wù)進(jìn)行合理的分解和定義，不是說(shuō)巨石應(yīng)用隨便按模塊拆分就可以了。經(jīng)常會(huì)有人問(wèn)，微服務(wù)對(duì)業(yè)務(wù)進(jìn)行升級(jí)以后多個(gè)模塊如何一起部署，問(wèn)這個(gè)問(wèn)題就是微服務(wù)沒(méi)有做好，學(xué)了微服務(wù)的形，沒(méi)有學(xué)到微服務(wù)的實(shí)質(zhì)，最終微服務(wù)的效果也會(huì)大打折扣。問(wèn)這個(gè)問(wèn)題的根源在于微服務(wù)解耦的不好，沒(méi)有遵循微服務(wù)分解的方法論。如果微服務(wù)分解的好，那很大程度上是可以單獨(dú)部署而不會(huì)影響其他模塊。

微服務(wù)做好了以后怎么運(yùn)維？故障發(fā)現(xiàn)、自動(dòng)恢復(fù)，根據(jù)業(yè)務(wù)請(qǐng)求量的彈性伸縮等等這些工作，要么通過(guò) PaaS 去自動(dòng)實(shí)現(xiàn)，要么自主研發(fā)實(shí)現(xiàn)，但是這樣工作量很大。最終，微服務(wù)的價(jià)值在于讓開(kāi)發(fā)人員只關(guān)注業(yè)務(wù)邏輯代碼，不用關(guān)注非功能性相關(guān)的技術(shù)問(wèn)題，這些技術(shù)問(wèn)題交由微服務(wù)框架和運(yùn)行環(huán)境來(lái)解決，而且微服務(wù)最終要能通過(guò)平臺(tái)實(shí)現(xiàn)運(yùn)維自動(dòng)化，就是未來(lái)的熱點(diǎn)“ NoOps ”，目前的 ServerLess，Serverless 不是目的，目標(biāo)是 NoOps。前幾年談 NoOps，大家總覺(jué)得太遙遠(yuǎn)，其實(shí) PaaS + 微服務(wù)，使得 NoOps 越來(lái)越近。

下一個(gè)技術(shù)熱點(diǎn)： 數(shù)據(jù)微服務(wù)

容器是 2015 年最大的熱點(diǎn)，但是 2016 年容器的熱度在下降；2016 年的熱點(diǎn)是微服務(wù)；2017 年我認(rèn)為是數(shù)據(jù)的微服務(wù)化。

為何認(rèn)定是技術(shù)熱點(diǎn)？

之所以認(rèn)為數(shù)據(jù)服務(wù)在 PaaS、CaaS 上的框架這個(gè)會(huì)成為新的熱點(diǎn)，是因?yàn)椋菏紫冗@個(gè)技術(shù)是微服務(wù)的延續(xù)，而且是必然的延續(xù)，微服務(wù)已經(jīng)解決了運(yùn)行環(huán)境—容器的問(wèn)題，又解決了框架的問(wèn)題— Spring  Cloud 和 Spring Boot，下一步就是數(shù)據(jù)的問(wèn)題了，而且數(shù)據(jù)服務(wù)化還沒(méi)有完全成熟。其實(shí)一個(gè)技術(shù)成為熱點(diǎn)的時(shí)候就是它的對(duì)應(yīng)技術(shù)方案即將成熟又未成熟之時(shí)，容器和微服務(wù)成為業(yè)界注意力中心的時(shí)候都是這樣，也就是大家對(duì)它將懂未懂，最需要了解的時(shí)候，這種狀態(tài)就是技術(shù)熱點(diǎn)狀態(tài)。

以今年火爆的微服務(wù)為例，SpringBoot 很早就開(kāi)始有研發(fā)；2014 年以產(chǎn)品形式出現(xiàn)，但是當(dāng)年月下載量是十萬(wàn)級(jí)別，而今年單月的下載量就可以上千萬(wàn)，兩年不到增長(zhǎng)百倍，這就是熱點(diǎn)。根據(jù)數(shù)據(jù)服務(wù)化的相關(guān)開(kāi)源項(xiàng)目在社區(qū)的反饋和貢獻(xiàn)量來(lái)看，現(xiàn)在也快達(dá)到了同樣的臨界點(diǎn)。

并且，創(chuàng)建大數(shù)據(jù)應(yīng)用仍很痛

現(xiàn)在做大數(shù)據(jù)應(yīng)用，需要裝很復(fù)雜的大數(shù)據(jù)環(huán)境。如果將其服務(wù)化，只需要點(diǎn)擊創(chuàng)建即可，使用者不必關(guān)心后面的 GreenPlum、Hadoop 等是怎么安裝部署的。Hadoop 那么多組件，一個(gè)個(gè)安裝太麻煩了。

目前我們做的數(shù)據(jù)服務(wù)化的技術(shù)儲(chǔ)備包括大數(shù)據(jù)服務(wù)化、數(shù)據(jù)服務(wù)化、流數(shù)據(jù)服務(wù)化，這三類(lèi)技術(shù)正在逐步達(dá)到生產(chǎn)可用.。因?yàn)榇蠹易鐾陸?yīng)用之后就開(kāi)始考慮數(shù)據(jù)怎么辦，數(shù)據(jù)按照傳統(tǒng)方式來(lái)做是肯定沒(méi)有問(wèn)題的，但是應(yīng)用微服務(wù)之后，要求數(shù)據(jù)要和微服務(wù)應(yīng)用對(duì)應(yīng)，原來(lái)的巨石應(yīng)用分拆為微服務(wù)了，那原來(lái)的大一統(tǒng)的大型數(shù)據(jù)庫(kù)，也要根據(jù)微服務(wù)進(jìn)行拆分，拆分之后要分析數(shù)據(jù)是用傳統(tǒng)的 SQL 數(shù)據(jù)庫(kù)，還是新的 NoSQL，或是緩存加持久化。所以我認(rèn)為這個(gè)就是將來(lái)熱點(diǎn)。以 Spring Data 為例，它負(fù)責(zé)數(shù)據(jù)抽象，至于最后落到哪類(lèi)數(shù)據(jù)庫(kù) MySQL、Oracle 甚至是 NoSQL 類(lèi)的 MongoDB 的技術(shù)細(xì)節(jié)，開(kāi)發(fā)者不必關(guān)心，到部署的時(shí)候再綁定，這就要求數(shù)據(jù)能夠服務(wù)化。

數(shù)據(jù)服務(wù)化具體的實(shí)現(xiàn)可能還是先從主流互聯(lián)網(wǎng)應(yīng)用數(shù)據(jù)庫(kù)(比如 MySQL， PostgreSQL)開(kāi)始，然后逐漸覆蓋各種實(shí)現(xiàn)，比如 Redis 實(shí)現(xiàn)、MongoDB 實(shí)現(xiàn)等。在解決完功能問(wèn)題之后，要解決性能問(wèn)題、安全問(wèn)題，整個(gè)就會(huì)變成一個(gè)很大的熱點(diǎn)；最開(kāi)始還是先面向開(kāi)發(fā)者慢慢擴(kuò)展到企業(yè)層面。

未來(lái)之路

在最開(kāi)始，業(yè)內(nèi)容易把云和大數(shù)據(jù)搞混，認(rèn)為 Hadoop 就是云；后來(lái)慢慢理解其實(shí)是兩種涇渭分明不同的技術(shù)。而現(xiàn)在，大數(shù)據(jù)的進(jìn)一步發(fā)展又離不開(kāi)云計(jì)算能力：大數(shù)據(jù)處理最后給哪個(gè)應(yīng)用使用，如何獲得大數(shù)據(jù)信息價(jià)值以及提供給誰(shuí)，需要經(jīng)過(guò)應(yīng)用平臺(tái)把大數(shù)據(jù)的能力體現(xiàn)出去。從這個(gè)應(yīng)用的角度來(lái)看，我認(rèn)為大數(shù)據(jù)應(yīng)用需要落在 PaaS 上。另外，云有很好的彈性能力，所以云可以更好地支持大數(shù)據(jù)的彈性計(jì)算。

不過(guò)這新結(jié)合的難度要大于之前的熱點(diǎn)技術(shù)容器和微服務(wù)，如果說(shuō)這后兩者解決的是點(diǎn)問(wèn)題，那大數(shù)據(jù)和PaaS的結(jié)合則是面的問(wèn)題，PaaS本身就是個(gè)很大的面。點(diǎn)點(diǎn)結(jié)合比較容易，但是面和面結(jié)合難度就會(huì)比較大，我估計(jì)需要 3-5 年或者更長(zhǎng)時(shí)間才能逐步發(fā)展成熟。

——————————————————————————————————－

嘉賓簡(jiǎn)介

周暉，Pivotal大中華區(qū)云計(jì)算首席架構(gòu)師，有著豐富的 PaaS 云實(shí)際建設(shè)經(jīng)驗(yàn)，負(fù)責(zé)過(guò)國(guó)內(nèi)某知名銀行已經(jīng)生產(chǎn)上線一年的 PaaS 云的架構(gòu)設(shè)計(jì)和部分功能的實(shí)現(xiàn)，參與過(guò)某超算 PaaS、某超市電商 PaaS、某電力 PaaS 等項(xiàng)目的建設(shè)。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來(lái)自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請(qǐng)進(jìn)一步核實(shí)，并對(duì)任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對(duì)有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁(yè)或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書(shū)面權(quán)利通知或不實(shí)情況說(shuō)明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開(kāi)相關(guān)鏈接。