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

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

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

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

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

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

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

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

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

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

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

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

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

OCI 負(fù)責(zé)的 RunC 是非常小的運(yùn)行核，其目的在于提供一個(gè)干凈簡單的運(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è)級別應(yīng)用中，并因此具有不同的發(fā)展目標(biāo)：RunC 不是要提供多少種工具，而是要非常穩(wěn)定。 接下來需要做的是可能是添加完善一些功能，比如將 Docker 鏡像導(dǎo)進(jìn)來，與各種插件更好地結(jié)合（動(dòng)態(tài)化即插即用），熱啟動(dòng)和遷移。這些功能是企業(yè)需要的，但是對開發(fā)者沒什么作用。以熱遷移為例，從一臺虛擬機(jī)遷移到另外一臺虛擬機(jī)，但是開發(fā)者可能本來就一臺機(jī)器并沒有這個(gè)需要。

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

在 RunC 早期，Docker 是主要貢獻(xiàn)者（在我看來，如果 Docker 不參與 RunC 的發(fā)展就意味著和容器生態(tài)圈決裂）；后來隨著各大廠商對 RunC 大幅貢獻(xiàn)代碼，RunC 的代碼貢獻(xiàn)者越來越多樣化，Docker 所占比例在持續(xù)下降。通過不斷迭代，RunC 一定會(huì)越來越成熟，它已經(jīng)在生產(chǎn)環(huán)境中開始積累技術(shù)了，Cloud Foundry 已經(jīng)有不少全球重量級客戶在用內(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 對 Docker 的替代的威脅。

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

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

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

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

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

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

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

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

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

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

1、Containerd 的開源

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

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

2、DataCenter “錢”途未卜

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

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

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

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

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

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

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

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

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

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

容器集群也還有很大的發(fā)展空間，集群的概念和應(yīng)用集群微服務(wù)化剛剛興起，在實(shí)際生產(chǎn)中會(huì)發(fā)現(xià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)用容器化，需要用到插件，但這類應(yīng)用并不是容器化的最主流應(yīng)用,是典型的1：9現(xiàn)象。就是90%的容器應(yīng)用不需要插件，10%的應(yīng)用需要插件，但是插件帶來相當(dāng)大的復(fù)雜性。應(yīng)用容器化只須在需要哪種功能時(shí)就使用哪種相應(yīng)的插件即可。不過目前各個(gè)廠商對插件的定義和理解并不完全一樣，除去共識的網(wǎng)絡(luò)、存儲(chǔ)等插件，其他的尚模糊。比如 Docker 對插件有自己的理解，哪些是插件，是否放到運(yùn)行環(huán)境里面；Mesos 對插件的解讀范圍就更廣，所以將插件標(biāo)準(zhǔn)化的想法在我看來還是不太容易。

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

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

Docker興起，加力了 PaaS 的推廣

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

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

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

放眼未來，PaaS 和 CaaS 可以各自輝煌

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

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

和 CaaS 不同， PaaS（Heroku、Cloud Foundry等）把應(yīng)用相關(guān)的復(fù)雜度屏蔽，只需一鍵部署應(yīng)用即可運(yùn)行起來，無需關(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í)它對DevOps 仍然有一定難度：Dockerfile / Compose 的書寫一般是運(yùn)維人員在做的事情，而Docker鏡像打好了需要交給開發(fā)人員，并沒有辦法做的很完美，很多地方?jīng)]有辦法完全固定，比如開發(fā)人員發(fā)現(xiàn)需要更改一個(gè)應(yīng)用服務(wù)器的端口這么簡單的一件事情，這可能就涉及到一系列的腳本的改寫，但這個(gè)事情到底是運(yùn)維人員來做還是開發(fā)人員來做？運(yùn)維人員來做那就不是 DevOps 了，如果開發(fā)人員來做，開發(fā)人員又很難具備運(yùn)維人員的腳步編程技巧。而這一點(diǎn) Heroku 和 Cloud Foundry 已經(jīng)注意到了，并通過構(gòu)建包徹底分離了運(yùn)維人員和開發(fā)人員的分工。

我們看 PaaS / CaaS 的區(qū)別和各自的市場，PaaS 的思路基于應(yīng)用平臺，而 CaaS 并不限于應(yīng)用平臺，因此它也并不能理解應(yīng)用平臺的問題；所以兩者面對的市場還不太一樣，如果著眼于應(yīng)用平臺那 PaaS 比較好，如果是希望把各種資源管理起來，當(dāng)做虛機(jī)使用，通過容器實(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)境的選擇），開發(fā)框架（比如服務(wù)動(dòng)態(tài)注冊、發(fā)現(xiàn)和調(diào)用等）。業(yè)內(nèi)很多人只重視到了第一部分，而忽略了第二部分，比如 Docker 微服務(wù)化最常見的就是微服務(wù)的動(dòng)態(tài)發(fā)現(xiàn)和調(diào)用則幾乎完全依靠第三方平臺來實(shí)現(xiàn)，如 ZooKeeper、Consul 等，但是這些工具的缺點(diǎn)是當(dāng)集群達(dá)到一定量之后就會(huì)出現(xiàn)不穩(wěn)定的問題，而且平臺要適應(yīng)各種代碼需求有困難，我認(rèn)為程序的事情歸程序來解決，而不是平臺。最佳實(shí)踐是采用程序框架從根本上解決問題，比如 Netflix 就進(jìn)行了徹底的改造，他們的服務(wù)注冊、發(fā)現(xiàn)、治理、限流都是通過程序框架(也即后來的 Spring Cloud )來實(shí)現(xiàn)的，經(jīng)受了大規(guī)模的應(yīng)用考驗(yàn)。用平臺解決代碼層面問題是有缺陷的，因?yàn)槠脚_解決的是平臺問題，不能包攬代碼的工作；代碼框架是解決代碼的問題：服務(wù)注冊發(fā)現(xiàn)更適合在代碼層面實(shí)現(xiàn)。

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

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

下一個(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)境—容器的問題，又解決了框架的問題— Spring  Cloud 和 Spring Boot，下一步就是數(shù)據(jù)的問題了，而且數(shù)據(jù)服務(wù)化還沒有完全成熟。其實(shí)一個(gè)技術(shù)成為熱點(diǎn)的時(shí)候就是它的對應(yīng)技術(shù)方案即將成熟又未成熟之時(shí)，容器和微服務(wù)成為業(yè)界注意力中心的時(shí)候都是這樣，也就是大家對它將懂未懂，最需要了解的時(shí)候，這種狀態(tài)就是技術(shù)熱點(diǎn)狀態(tài)。

以今年火爆的微服務(wù)為例，SpringBoot 很早就開始有研發(fā)；2014 年以產(chǎn)品形式出現(xiàn)，但是當(dāng)年月下載量是十萬級別，而今年單月的下載量就可以上千萬，兩年不到增長百倍，這就是熱點(diǎn)。根據(jù)數(shù)據(jù)服務(wù)化的相關(guān)開源項(xiàng)目在社區(qū)的反饋和貢獻(xiàn)量來看，現(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ù)化，這三類技術(shù)正在逐步達(dá)到生產(chǎn)可用.。因?yàn)榇蠹易鐾陸?yīng)用之后就開始考慮數(shù)據(jù)怎么辦，數(shù)據(jù)按照傳統(tǒng)方式來做是肯定沒有問題的，但是應(yīng)用微服務(wù)之后，要求數(shù)據(jù)要和微服務(wù)應(yīng)用對應(yīng)，原來的巨石應(yīng)用分拆為微服務(wù)了，那原來的大一統(tǒng)的大型數(shù)據(jù)庫，也要根據(jù)微服務(wù)進(jìn)行拆分，拆分之后要分析數(shù)據(jù)是用傳統(tǒng)的 SQL 數(shù)據(jù)庫，還是新的 NoSQL，或是緩存加持久化。所以我認(rèn)為這個(gè)就是將來熱點(diǎn)。以 Spring Data 為例，它負(fù)責(zé)數(shù)據(jù)抽象，至于最后落到哪類數(shù)據(jù)庫 MySQL、Oracle 甚至是 NoSQL 類的 MongoDB 的技術(shù)細(xì)節(jié)，開發(fā)者不必關(guān)心，到部署的時(shí)候再綁定，這就要求數(shù)據(jù)能夠服務(wù)化。

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

未來之路

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

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

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

嘉賓簡介

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

生成海報(bào)

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