從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é)摿ΑH萜鞯母黝?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è)。

極客網(wǎng)企業(yè)會(huì)員

免責(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)鏈接。

2017-01-16
從Docker的轉(zhuǎn)變,談容器生態(tài)與微服務(wù)的發(fā)展
在收獲最初的贊揚(yáng)之后,領(lǐng)軍者 Docker 如今身陷非議:2016 年執(zhí)意壯大發(fā)展 Swarm 進(jìn)軍編排領(lǐng)域,似乎 Docker 公司一方面惹毛了很多強(qiáng)勁的編排領(lǐng)域玩家,另一方面也并沒(méi)有收獲預(yù)料之中的成果。

長(zhǎng)按掃碼 閱讀全文