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

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

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

誕生與興起：Docker 贏得聲譽

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

坦率而言，我認為 Docker 進軍編排界并沒有優(yōu)勢，因為他缺乏企業(yè)級基因。

Docker 更適合在容器本身的技術，今年 Docker 力推 Swarm，把資源花在了集群管理上，這其實并不是 Docker 技術的初心。當時 Docker 迅速流行是因為簡單易用，而后來走卻想把太多東西塞到 Docker 中。

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

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

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

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

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

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

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

1、Containerd 的開源

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

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

2、DataCenter “錢”途未卜

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

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

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

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

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

Docker 還會把 Swarm 繼續(xù)支持下去，但是編排領域的有很多細分的市場，Swarm 的發(fā)展目標應該會是小規(guī)模的集群；而且 Docker 的發(fā)展重心還是會回到容器本身，因為只有精專容器本身技術，才會凸顯 Docker 獨特的優(yōu)勢。做編排的話，從社區(qū)熱度、貢獻人數(shù)、發(fā)布頻率可以看出，Swarm 應該是會被其他競爭對手的光環(huán)所淹沒。

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

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

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

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

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

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

但是，對于網(wǎng)絡插件，業(yè)界認識都比較統(tǒng)一，因為是普遍需求，并且應用的多是VPN隧道技術。如果對這類插件進行統(tǒng)一標準化，可以便于相互之間的通用。

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

Docker興起，加力了 PaaS 的推廣

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

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

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

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

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

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

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

我們看 PaaS / CaaS 的區(qū)別和各自的市場，PaaS 的思路基于應用平臺，而 CaaS 并不限于應用平臺，因此它也并不能理解應用平臺的問題；所以兩者面對的市場還不太一樣，如果著眼于應用平臺那 PaaS 比較好，如果是希望把各種資源管理起來，當做虛機使用，通過容器實現(xiàn)，那 CaaS 比較好。

關于 Docker 和微服務

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

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

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

下一個技術熱點： 數(shù)據(jù)微服務

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

為何認定是技術熱點？

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

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

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

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

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

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

未來之路

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

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

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

嘉賓簡介

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

生成海報

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