正如最初設(shè)想的，容器已經(jīng)成為無狀態(tài)型微服務(wù)的最佳載體。容器的敏捷、靈活、小開銷，與微服務(wù)是絕配。因此，容器與DevOps琴瑟和諧，成為近十年的最熱門技術(shù)，就像裝上了火箭發(fā)動機一樣。

與此同時，“無狀態(tài)”的負面性，也開始呈現(xiàn)。真正的應(yīng)用也用容器，但應(yīng)用都是有狀態(tài)的。而且，大多數(shù)應(yīng)用存在兩種存儲形式，數(shù)據(jù)交換和存檔采用第一種，(多種形式的)持久性存儲，運行中的應(yīng)用實例和臨時庫則用第二種，臨時性存儲。

容器vs. 虛擬機

與虛擬機不同，應(yīng)用在無狀態(tài)容器上運行時，實例是不會持久化的，一旦因任何原因出錯，不可能恢復(fù)。應(yīng)用可以訪問容器所在主機的存儲，但除非容器及其載體也在虛擬機上，否則極易觸發(fā)安全隱患。反觀虛擬機，若當(dāng)前主機上的實例出故障，虛擬機可以快速重啟另一主機上的實例。這一點是容器不被主流IT接受的最主要原因。

行之有效的微服務(wù)/小程序架構(gòu)，需要數(shù)據(jù)在容器間移動，或者在數(shù)據(jù)所在地實例化容器服務(wù)，這樣通常更快。從敏捷和靈活性來看，確實需要一種跨容器的數(shù)據(jù)狀態(tài)載體。

現(xiàn)在，應(yīng)用可在各種平臺上構(gòu)建存儲，從對象到塊存儲，從SAN到超融合。對于想完全取代hypervisor的容器而言，滿足廣泛的存儲方案是完善生態(tài)的必經(jīng)之路。

要說的是，不同玩家，理解上頗有一些哲學(xué)上的微妙差異。Hypervisor玩家嚷嚷著支持無狀態(tài)容器，是因為有狀態(tài)容器可能會終結(jié)hypervisor。一些容器玩家支持無狀態(tài)容器，也許是“原教旨主義”的體現(xiàn)——在容器的發(fā)展早期，“無狀態(tài)”是其區(qū)分hypervisor的一個重要賣點。

大多數(shù)容器用戶非常喜歡容器的敏捷、易用性。再加上一臺服務(wù)器能跑3-5倍多實例(相比虛擬機)的事實，簡直讓DevOps玩家到愛不釋手的地步。因此，為容器增加持久性存儲功能，一定是其產(chǎn)品變革的首選項。實際上，行業(yè)內(nèi)的變化完全符合這一預(yù)期。

容器存儲，是一個亂象叢生，百家爭鳴的新領(lǐng)域，各家都在積極推出自己獨特的方案，彼此互不相容。這雖然讓用戶頭疼，但也正說明這一市場方興未艾。

產(chǎn)品和供應(yīng)商

讓我們來看看形形色色的容器存儲方案。Portworx PWX允許容器掛載共享型的彈性塊存儲。StorageOS在此基礎(chǔ)上，還搭載各種類型/協(xié)議的外部存儲，并提供壓縮。Rancher Labs強項是本地存儲，同時支持跨服務(wù)器的數(shù)據(jù)遷移。微軟Windows Server提供面向OS內(nèi)核和Hyper-V實例的共享解決方案。

另外，ClusterHQ使用Flocker，一種開源產(chǎn)品，允許創(chuàng)建跨容器甚至主機的共享存儲空間。Flocker本由VMware提供支持，且能與EMC、NetApp等主流供應(yīng)商產(chǎn)品集成，但ClusterHQ選擇完全自主開發(fā)，因此就拒絕了VMware的強力支撐。

容器的核心層軟件堆棧也有動靜。Kubernetes 1.6及更高版本，允許按需存儲和多種存儲類型，包括所有主流云計算方案底層的StorageClass對象，OpenStack協(xié)議簇，VMware vSphere以及三大公有云服務(wù)供應(yīng)商。超融合系統(tǒng)也秘而不宣地整合容器存儲，相信Nutanix等供應(yīng)商不久就會公布升級計劃。

有趣的是，容器開發(fā)者們喜歡說“持久性數(shù)據(jù)”，而非“持久性存儲”。我一向覺得，傳統(tǒng)視野里的文件系統(tǒng)概念，在當(dāng)前的對象存儲、軟件定義存儲/微服務(wù)、細粒度容器虛擬化等新思潮面前，已經(jīng)過時了。技術(shù)演變的結(jié)果也許就是，一個全新的細粒度存儲。

NVDIMM的出現(xiàn)，這股變革熱潮也許將更迫切。幾年之內(nèi)，NVDIMM就會將塊存儲單元從4KB降到單字節(jié)級，因此當(dāng)前的容器存儲很可能完全不適應(yīng)未來的需要，而持久性數(shù)據(jù)(存儲)才是一個正確的選擇。