正如最初设想的，容器已经成为无状态型微服务的最佳载体。容器的敏捷、灵活、小开销，与微服务是绝配。因此，容器与DevOps琴瑟和谐，成为近十年的最热门技术，就像装上了火箭发动机一样。

　　与此同时，“无状态”的负面性，也开始呈现。真正的应用也用容器，但应用都是有状态的。而且，大多数应用存在两种存储形式，数据交换和存档采用第一种，(多种形式的)持久性存储，运行中的应用实例和临时库则用第二种，临时性存储。

　　容器vs. 虚拟机

　　与虚拟机不同，应用在无状态容器上运行时，实例是不会持久化的，一旦因任何原因出错，不可能恢复。应用可以访问容器所在主机的存储，但除非容器及其载体也在虚拟机上，否则极易触发安全隐患。反观虚拟机，若当前主机上的实例出故障，虚拟机可以快速重启另一主机上的实例。这一点是容器不被主流IT接受的最主要原因。

　　行之有效的微服务/小程序架构，需要数据在容器间移动，或者在数据所在地实例化容器服务，这样通常更快。从敏捷和灵活性来看，确实需要一种跨容器的数据状态载体。

　　现在，应用可在各种平台上构建存储，从对象到块存储，从SAN到超融合。对于想完全取代hypervisor的容器而言，满足广泛的存储方案是完善生态的必经之路。

　　要说的是，不同玩家，理解上颇有一些哲学上的微妙差异。Hypervisor玩家嚷嚷着支持无状态容器，是因为有状态容器可能会终结hypervisor。一些容器玩家支持无状态容器，也许是“原教旨主义”的体现——在容器的发展早期，“无状态”是其区分hypervisor的一个重要卖点。

　　大多数容器用户非常喜欢容器的敏捷、易用性。再加上一台服务器能跑3-5倍多实例(相比虚拟机)的事实，简直让DevOps玩家到爱不释手的地步。因此，为容器增加持久性存储功能，一定是其产品变革的首选项。实际上，行业内的变化完全符合这一预期。

　　容器存储，是一个乱象丛生，百家争鸣的新领域，各家都在积极推出自己独特的方案，彼此互不相容。这虽然让用户头疼，但也正说明这一市场方兴未艾。

　　产品和供应商

　　让我们来看看形形色色的容器存储方案。Portworx PWX允许容器挂载共享型的弹性块存储。StorageOS在此基础上，还搭载各种类型/协议的外部存储，并提供压缩。Rancher Labs强项是本地存储，同时支持跨服务器的数据迁移。微软Windows Server提供面向OS内核和Hyper-V实例的共享解决方案。

　　另外，ClusterHQ使用Flocker，一种开源产品，允许创建跨容器甚至主机的共享存储空间。Flocker本由VMware提供支持，且能与EMC、NetApp等主流供应商产品集成，但ClusterHQ选择完全自主开发，因此就拒绝了VMware的强力支撑。

　　容器的核心层软件堆栈也有动静。Kubernetes 1.6及更高版本，允许按需存储和多种存储类型，包括所有主流云计算方案底层的StorageClass对象，OpenStack协议簇，VMware vSphere以及三大公有云服务供应商。超融合系统也秘而不宣地整合容器存储，相信Nutanix等供应商不久就会公布升级计划。

　　有趣的是，容器开发者们喜欢说“持久性数据”，而非“持久性存储”。我一向觉得，传统视野里的文件系统概念，在当前的对象存储、软件定义存储/微服务、细粒度容器虚拟化等新思潮面前，已经过时了。技术演变的结果也许就是，一个全新的细粒度存储。

　　NVDIMM的出现，这股变革热潮也许将更迫切。几年之内，NVDIMM就会将块存储单元从4KB降到单字节级，因此当前的容器存储很可能完全不适应未来的需要，而持久性数据(存储)才是一个正确的选择。

　　责任编辑：DJ编辑