本文作者：联想凌拓架构师 | 原创 |原始出处
(原始文章出处，您也可以点击文后长链接)
本文旨在探讨，当您计划或准备开始采用对象存储来替代您现有的数据存储服务时（SAN或者NAS），我们从对象存储产品的架构开始，从使用的角度、应用程序集成的角度、数据存储的角度共同探讨，对象存储在具体应用场景中，应当重视或者避免的一系列问题，以满足新的数据使用形态。
**为什么需要对象存储？**
这是一个会必然被提及的话题，在我每一次的业务场景咨询过程中，通常得到的答复是：
当前的目录结构对于数据检索的能力提出的很大的挑战，听说对象的检索效率很高，我们希望尝试利用对象存储替换现有的架构；
预期的数据存储量可能到达PB级，以现有的架构来看，很难满足未来的预期需要，所以我们需要尝试利用对象存储替换现有的架构；
我们希望利用全新的分布式架构来改造我们的数据中心，分布式架构是未来的发展趋势，我们必须顺应潮流；
诚然，这些因素确实是考虑采用对象存储架构的一部分理由，人们也总是期望采用一种方法来解决所有问题。然而，结果却往往是适得其反，每一次新技术的引入，都会带来新的问题。
所以，我写这篇文章的期望就是，能够理性的看待对象存储这样一个不算很新的新技术，在褪去了技术热词的加持之后，审慎的评估您的应用架构与使用场景，最终选择真正合适的数据存储架构，毕竟不论是过去还是未来，数据的存储形态从来不曾，也永远不会只存在一种形态。
**对象存储的前世今生**
协议之争
要探讨对象存储的业务场景，就有必要先讲一讲对象存储的前世今生，有据可考的对象存储行业标准产生在2010年，由SNIA提出的CDMI协议。然而极度讽刺的是，这个本有希望成为像FC、iSCSI、NFS、SMB一样的标准协议的协议，仅仅只存活了5年，业界也只有NetApp的StorageGRID短暂的支持过这个协议，自2016年开始，AWS S3成为了事实上的行业标准。
而在2010年之前，对象存储的协议类型呈现的是百花齐放的格局。几乎各个对象存储的软件供应商都有自己的协议封装。
而CDMI在其中最大的贡献是，确立了RESTful API在这个细分行业的地位。因此在今天，不论是AWS S3、Azure Blob、IBM COS还是Google GCS全部都采用了RESTful API作为接口，且全部都提供了S3的兼容协议，用来适配事实上的行业标准。
而国内的公有云或国内外的对象存储能力的提供商，无一例外的，均提供与S3兼容的协议来适配“行业标准”。
对象存储的上古时代
在磁带库之后，市场上迫切的需要一种高性能，且相对廉价的数据归档设备，而在那个年代，出现了大量的基于磁盘介质的数据备份归档解决方案。从血缘关系上来说，对象存储其实是从带库、VTL、归档存储这条脉络中发展而来的。它是融合了带库的容量特征以及VTL、归档存储的性能特征，来满足数据高速增长的前提下，所带来的数据合规性要求，以及归档数据的可访问性要求。
在早期的对象存储应用场景中，也仅是适用于冷数据的备份，或者数据归档的场景，对象存储被备份和归档平台很好的封装在了软件后端，利用备份、归档平台与前端应用的agent生态提供备份和归档的数据存储服务。
也正是这个场景特征，决定了在对象存储的架构设计上的视角。
**一致性和性能的悖论**
讨论对象存储，就一定跳不开一致性设计和性能两个因子。这也是常常被拿出来探讨和分析的两个话题。
在正式的讨论之前，我想先明确一下关于数据一致性的几个级别，自低而高分别是。
弱一致性：
在数据更新后，系统不承诺读取的数据是最新的结果，也不承诺需要多长的时间能够读取到最新的结果。
最终一致性：
在数据更新后，系统不承诺读取的数据是最新的结果，但是最终会读取到最新的结果。
强一致性：
在每一次数据更新后，都会承诺读取的数据永远都是最新的。
（为了不混淆整个行文的逻辑，这里不做顺序一致性的介绍和讨论。）
最终一致性，其实算是弱一致性的一个特殊形态，它不是即时的更新数据，但是也不是无期限的，永远不去强调一致性。
弱一致性其实广泛的存在于分布式架构的组织中，拿人来举例子，在一个组织中，每个人的工作细节和进度还有结果，在同事之间是不需要全部了解的。这就是一个典型弱一致性场景，如果每个人要做的每件事都需要通告给全组织的其它人确认，那么效率就大大的被降低了。
其实我们在一个分布式的事务处理架构上也存在这样的问题，尤其是一个面向海量数据处理的事务架构中，如果每一个节点都需要保持强一致性的话，那么沟通的成本就会淹没效率的河堤。从而使整个集群的效率大大降低。
那么为了确保在一个分布式集群中的事务处理的效率（这个效率包括延迟和吞吐）。尤其是一个超大规模的分布式集群架构的时候，放弃一部分的一致性诉求就成为了解决方案之一。当然除此之外，还有比如提升单个节点事务处理能力的方案，或是提供更快速的介质，降低数据的可用性和持久性等等方法来提升事务的处理的效率。但是，同样在每一种方案的背后，都意味着要放弃一些其它能力。
我们前面谈到了，对象存储的血缘是从数据备份和数据归档的场景中而来，成本其实是很重要的一环，所以在S3、Swift、CDMI、Blob等等的协议设计中，统统采用的思路都是通过放弃强一致性来满足成本和性能的需要。
当然有些分布式文件系统仍然能够强调强一致性，比如GPFS、StorNEXT、OneFS、HDFS等等，但是请记住，这些实现的规模不同、采用的协议接口不同、成本也不相同。但是这些都不是我们今天想要讨论的主题。
接下来我想谈谈关于分布式文件系统的性能问题，采用横向的扩展，从某些程度上，确实是可以提供线性的性能扩展，请注意我用的是某些程度。但是我们通常在考虑性能问题时，都是站在强一致性的前提下思考问题的。往往我们会忽略对象存储的最终一致性特性。
我们把数据的写入到可见分为三个阶段，upload阶段，commit阶段，可见阶段。
在强一致性性的文件系统中，commit阶段和可见阶段的延迟小到几乎可以忽略不计，小于1ms，相当于upload结束数据即可见。
但是在最终一致性的文件系统中，commit阶段和可见阶段的延迟是不确定的。因此当数据被upload完成之后，应用能够对数据处理的时间也是不确定的。
如果我们只是单纯的去考虑upload的所花费的开销，分布式架构的对象存储系统确实能过够提供更好的并行事务处理能力，这也是绝大多数的对象存储软件供应商所宣称的性能价值。
这种价值传递确实从一定程度上促进了对象存储平台的发展，但是这种片面的价值传递，其实是对于用户来说是非常不负责任的。
**对象存储的实现架构**
还是回到对象存储本身的架构中来，无论是采用那种协议、还是某个软件供应商提供的对象存储系统，其实都跳脱不开两层架构。
在协议接口之下，是一套多事务处理的并行框架，通俗一点讲，就是一套用户态的分布式文件系统，在这套分布式文件系统之下还有一层内核态的文件系统，没错就是我们日常看到的XFS、ext4、btrfs、bluestor等等。
我们在这里为了方便讨论，将两层架构分别起一个名字，access node和data node：
（这个名字是为了方便我们接下来的讨论，并不特指某一产品的特定称谓，虽然HCP和COS都有去采用access node和data node这样的名字来定义它们的节点，但是请不要带入这些产品进入我们的探讨。）
Access node，即是用户态的分布式文件系统节点，它负责metadata的调度，以及处理数据在跨data node分布时的方法。此外，access node实际也是对象协议的接口，承载RESTful API的指令；
Data node，即是内核态的底层文件系统，所有的data最终会落在data node的介质上保存。
当然不同的供应商，在提交产品时，最终呈现给用户的硬件产品形态是不同的，有些供应商是将access node和data node拆分为两个不同的硬件节点；有些则是将两种node装载在一个硬件节点中。但是无论硬件形态上的如何变化，都跳脱不开这样两层的架构。
Metadata和data
我们在讨论数据存储时，总是会提到metadata元数据和data 数据；metadata是表达数据的数据，就好像是数据的索引一样，首先它表示的数据存放的位置，其次它能够提供数据本身的一些属性信息，比如名称、权限等等。
在强一致性的系统中，metadata和data具备原子属性；即两者不可分割，一荣俱荣、一损俱损。在整个数据写入的过程中，也是需要等双因子完全commit之后，才变为可见阶段。在写入操作过程中，任意因子的写入失败，都将造成整个数据的写入失败。
而在最终一致性的系统中，为了避免多节点之间相互commit的开销，所以就打破了这种原子性；即metadata和data可以分别commit，最终由access node的分布式文件系统来确认metadata和data的关联属性。
这当中就有可能出现一个有意思的场景，比如metadata已经被access node commit，但是data虽然已经写完了，但是本身还没有被commit（在队列中等待处理），那么在对象的文件系统层面，这个数据是可以被索引的，但是索引的位置为空，会向应用程序返回一个404错误，表示没有找到这个数据。
采用这种异步处理方式的好处是，可以极大的提升每个node的吞吐能力，即上一章节提到的性能效率，数据先快速的沉淀到data node中，释放access node的session会话，这样在同样的单位时间内，可以传输的数据量就更多。所有的metadata和data通过一个队列机制，来延迟处理相互之间的匹配关系。当然代价就是数据的可见，或者说可供访问的时间被延长；
如果作为不强调Near-time的batch场景，或者以吞吐为优先的HPC、视频影像归档场景来说，对象无疑是提供了一个很好的廉价解决方案。
read-after-write一致性级别
但是，在企业级的应用场景中，对于数据非即时性访问的场景毕竟是绝少数。为了适配更广泛的业务场景，AWS在2011年提出了read-after-write的一致性级别。
这里又要谈到数据操作的三种类型：create、update和remove。
在强一致性的系统中，对于这三种类型的操作都是即时可见的。
但是在最终一致性的系统中，这三种类型的操作都不是即时可见的。
而read-after-write就是在最终一致性的系统中，来提供create操作的强一致性，代价是整个数据写入的session会话的时间被拉长了，对于前端发生写入的应用程序来说，事务处理的时间大约需要增加2秒的延迟。而这两秒延迟带来的优势是，create数据时的原子性。
尽管数据在进行update和remove操作时，仍然不提供原子性。但是create操作的原子性能力极大的拓宽了对象存储的应用场景，使得即时数据处理的场景采用对象存储成为了可能，当然对于数据本身有大量update操作的业务仍然不适合采用对象存储。
API的重要性
大多数人都热衷于讨论分布式架构的优势，却很少去正视API的重要性，这种忽略在有些时候甚至是刻意的。如果从最终项目实现的角度来说，其实API的能力远比架构体系重要的多。
S3和swift
S3和Swift可以说是当前市场上事实上的对象协议标准，当然不同的公有云厂商的自有对象存储也会提供自己的协议标准供用户选择。
如果从广泛的市场角度去观察，向S3标准兼容的产品是最多的，不论是公有云亦或者是非云的对象软件提供商。这里面除了S3本身的技术活跃度之外，Amazon也确实是对象存储使用场景的行业引导者。
而提到S3就不得不提到S3的兼容性问题，可以很现实的讲，除了Amazon自己，没有人能够100%的兼容S3协议，每个兼容S3协议的产品之间，能够提供的兼容能力也是不尽相同的。甚至在同一个API下标头的支持能力也不相同。所以在选择采用对象存储进行业务对接的时候，首先应当评估S3的API接口能力是否符合业务流程的需求，以及在协议层之外的替代解决方案。
而swift现在更多的是作为openstack中cinder的后端pool存在的，基于swift的业务开发非常少见。同时，swift在openstack平台上又需要面临与ceph的竞争，虽然Swift也是一个顶级项目，但是这两年一直处在一个不温不火的状态。
相对来说，swift提供的API相对简单，也相对稳定，这几年几乎没有变化，又因为是开源，以及属于openstack体系，所以相对来说各个供应商的API支持能力都差不多。但是相关的场景开发案例和模型太少了，很难寻找到一个合适的参考架构。
从整个协议层面的生态来说，S3已经成为了事实上的行业标准。
Bucket和Object
Bucket是S3对于接入资源的一个描述，在swift中这个资源的描述被称为Container，在Azure中被称为Blob。不论称谓如何，它都是一个作为对象存储的一个资源挂载点存在的，就好像NFS协议中Export的目录挂载点一样。
在Bucket上我们是能够进行很多操作的，除了创建、删除Bucket之外，我们也能通过API实现诸如内容列表查询、ACL访问控制权限控制这样基本的操作；也能提供诸如将bucket变为一个静态页面网站、对于account流量计费、使用资源审计、跨域资源访问等等的高级操作（注意：这些API不是所有供应商都能够完整提供，很多API实际上都是从AWS自身的业务角度开发出的API）。
Object，是文件在对象存储中的最小存储单元，之所以称之为单元，是因为一个object其实是由多个部分组成的，除了system metadata和data之外，还有user metadata、tag这些元素组成。
Object通过富集的metadata，实现对file的快速操作，大量的条件检索和数据范围分类实际上是通过metadata中的user metadata和tag来实现的。在应用的角度，要实现这部分的具体需求，首先应调研供应商对于object API的支持情况。同时，需要评估metadata搜索引擎的实现框架，是否能够满足业务对于规模化数据处理的需要。
Key和前缀
在对象存储中，是没有目录的概念的，一个对象的名称被称为key。Key是用来表述对象的最基本的一元表达式，如果要实现类似于目录的一元数据管理结构，对象存储提供了object前缀表达式，来满足对于一元数据的分类管理。它的表达式与目录结构相似：前缀\key。
但是与目录结构不同的是，所有的前缀实际上都是一个object的扩展名称，而不是一个单独的挂载点。即如果你想访问多个有相同前缀的object，无法向使用文件系统那样，先登录到某个目录的挂载点，然后直接对其中的文件进行访问。这是object与文件在数据访问方式上的最大区别。
因此，在考虑进行基于对象平台的业务系统改造时，即便是仅采用一元数据分类的方法，仍然需要考虑相关code的实现方法，避免不必要的错误。
ACL和角色
对象存储提供了一个多元的数据访问控制框架，通过角色与ACL的交叉组合，实现不同用户在单一桶，多个桶之间的数据交互性访问，这在复杂的业务流程系统设计中，是非常重要的应用场景。
首先，角色是数据的最终访问者，所有的数据访问都是基于角色来控制的，我们创建一个用户，给予这个用户相应bucket和object的操作权限。这和传统的NFSv4或SMB并没有什么本质上的不同。
而ACL是提供跨bucket拥有者数据访问的功能，例如，如果存储桶拥有者允许其他账户上传对象，则对这些对象的权限只能由拥有此对象的账户使用对象ACL加以管理。
在多租户数据访问时，ACL提供了更好的数据交互访问体验。比如有内外网数据交互访问时，可以采用ACL与角色的双重权限定位，来满足数据访问的需求。但是在有数据合规性要求的前提下，请审慎评估ACL在系统中的作用。
对象存储的适用场景
在今天看来，大部分的文章中谈到的对象存储适用场景都是模糊的，除了极个别的有着成熟解决方案的场景外，大部分的场景落地都存在一些问题，或多或少的需要对现有的应用程序进行改造。
数据的备份和冷归档场景
对象作为一个海量存储系统，实际上最早的业务场景就是来自于数据的备份和冷归档，这个在前文中已经有所提及。
采用对象来替代VTL、TL的解决方案也是最成熟的，不论你的前端备份工具是NBU或者Commvault，Veeam等等。都绝大部分数据备份和归档管理工具，都可以支持将S3作为后端的存储池，来存储备份/归档的数据。
本身备份或者冷归档的数据就不是一个需要实时update或者GET的数据，而且S3在吞吐能力上确实比VTL的虚拟驱动器要来的优秀，成本上更是低到令人发指（专指公有云），所以成为时代的宠儿一点也不奇怪。
在相当长的一段时间里，数据备份和冷归档是对象存储的唯一应用场景。
HPC超算场景
从传统上来说，这是一个Lustre、GPFS或者BeeGFS这类文件系统的天下，最不济也是NFS的场景，至于我为什么会在对象的第二个场景中提到HPC，原因在于今天从HPC的使用角度，或者IO的角度来说，对象的特性是适合的。请注意我说的是从对象的特性角度来说，它是比较适合HPC这种场景的。
我们先来探讨一下HPC的运行的流程，不论你是做仿真还是模拟的操作，首先都需要打包一个作业文件到HPC平台，根据作业内容，HPC会进行运算，最终结果则会合并输出到存储节点中。
通常来说对于HPC的输出结果并没有实时访问的需求，因此对象存储的最终一致性高吞吐的特性，是十分适合这个场景的。我们完全可以将一致性级别降低到最终一致性，来获得更高的IO吞吐为结果输出服务。此外，对象的低成本特性在规模化的HPC场景中，也能为降低TCO提供很好的帮助。
当然这还是一个较为新兴的对象应用场景，目前来看主要是公有云厂商在利用这个架构提供数据存储服务，对于传统的On-Prem 的HPC架构来说，还是相对少见。但是我觉得这不失是一个对象存储新的发力场景。
Big Data数据分析场景
今天看大数据分析场景已经是一个非常庞大的生态了，包括的内容非常多，包括过去的数仓应用，今天狭义上我们讲的Hadoop，以及现在非常火的流式数据处理，其实都属于大数据的范畴。
对于对象存储来说，大数据分析的场景也是一个非常成熟的应用场景。
从大数据分析的整个生态架构上来说，Hadoop已经成为了事实上的大数据分析的PaaS平台。现在Hadoop上能够扩展的生态达到了180多个应用集，而且这个数字还在不断的增加。所以今天把Hadoop和Big Data Analysis划等号也不是不可以。
回到数据层面，对于大数据分析场景来说，数据集是非常重要的生产资料，但是当前Hadoop所提供的HDFS，却已经成为了实施大数据战略的组织的负累。
HDFS的3 copies + name node的架构， 真的可以讲是槽点多多，无限增长的分析数据犹如饕餮一般的蚕食着磁盘空间，而三倍快乐的HDFS，更是加重了企业对于磁盘容量的需求。
对于多数企业而言，在算力充足的前提下，不得不为容量需求去为算力买单。不论是从业务的角度来说，还是从中长期成本来说，这都是不合算的。大量的算力被浪费在了对容量的需求上。而本身的业务量和种类并没有增加多少。
而name node的HA方法，也导致这个数据架构的业务连续性保证并不可靠。关于整个大数据分析的架构，我们完全可以单列一篇文章来讨论，所以我们还是回到对象存储的话题。
对象很大的一个特点就是采用了EC的技术，同时支持storage classes的生命周期管理，这就为整个数据填埋场景提供了非常科学的数据管理体系。
首先是storage与computer进行了解耦，容量的扩充不在需要为算力买单。
其次，EC的技术为长期数据填埋的场景节省了大量的存储空间。
对于热的贴源数据和冷的填埋数据，又可以利用生命周期管理的策略，实现数据的分层，将热点数据采用多副本，高性能节点存储，对于历史填埋数据，采用低性能介质和EC的方式存储。同时可以设置一个远期的生命周期策略，将过期的填埋数据从对象平台中自动删除，实现存储平台的空间自洽。
当然，在Hadoop的场景下，你是没有办法抛开HDFS去直接对接对象的。好在AWS提供了S3对接HDFS的SDK——S3a。（其实在S3a之前，也有过对接HDFS的方法，比如S3n的SDK等等）。
和HPC场景不同的是，Hadoop会不断的去touch HDFS中的文件，因此在采用S3时，需要使用read-after-write的一致性级别来确保应用的正常（实际上hadoop会去不断的去找metadata，也就是object的HEAD）。
Web和移动应用场景
这些场景和企业级的应用相对较远，比较典型的比如：电商网站中的配图、抖音短视频、今日头条app之类的应用。
相较于传统企业，广电行业的融媒体平台是一个非常常见的应用场景。从本质上来说，融媒体就是一个传统媒体互联网+的产物，所以它还是一个互联网侧的业务场景类型。
当然在传统企业级场景中，也有类似的业务场景，比如说企业网盘。在这个场景下，其实对象是很适合的。实现的方法也有很多种，比较简单的就是直接利用S3 Browser做为客户端，实现数据的上传和共享。
另外就是在S3前端和一些网盘应用做对接，对接的方式也有好多种，比如利用API对接就是一种方法，还有就是利用S3fs，封装成一个类似NFS的mount point，挂载给操作系统使用。因为本身企业网盘不是一个对IO和延迟要求很严格的场景，所以可以采用简单的方法实现快速的集成。
企业网盘的应用场景就非常广泛了，它主要替代的也是传统FTP的应用场景，这里我就不多作复述了。
需要慎重评估的业务场景
ECM企业内容管理
这是这两年，各个行业比较愿意去尝试改造的业务场景，在实施这类场景的改造前，其实是需要审慎的评估整个ECM平台的业务流程的。
前文我已经阐述过，对象不是一个强一致性的文件系统，所以如果ECM内的文件操作逻辑是比较频繁的，有大量的擦改写操作的时候，一定要非常慎重的去评估和梳理整个业务的流程。
一般来说，要确认几件事情：
首先是ECM对于文件的操作是一次性的，还是会有后续的多次操作，比如转格式之后，是不是后续有一系列的电子签注的操作；
第二点，要确认这个后续BPM操作是异步批量的，还是动态实时的；对于不同的处理方式，在改造时，就需要设计不同的应用访问延迟，来避免404、500这类的报错。
第三点，需要评估开发团队有没有能力对现有的ECM架构做改造，或者完全基于对象存储来重新构建新的ECM平台；
第四点，综合成本是否符合预期。
这是在很多对象相关的项目过程中，我整理出的一套方法论，可以比较快速的梳理出业务是否具备改造的条件。当然类似的场景还有很多，比如一些ESB总线上的数据转储，如果有计划采用对象存储，也是需要对现有的应用做评估的。
这种应用类型会比较个性化，因为其实说白了都是框架，具体这套框架是怎样在组织中服务的，业务逻辑是怎么样的，这个是需要和业务侧的同事一起讨论和明确的。
所以这类业务的存储改造会变得很复杂，它可能是可行的，也可能是不可行的，只有在前期做足了功课，才能确保最终项目的成功。
对象存储不适用的业务场景
大体上来说，交易型的业务场景就完全不适合对象的应用。除了OLTP这一类，还包括一些对于文件有频繁操作的业务类型，比如EDA类的场景，会有频繁的交互擦改写操作，又有文件共享的需求，这种就不是对象存储能满足的场景。
还有对于访问延迟要求很低的业务，且这种低延迟是不可妥协的，也不适合采用对象存储，因为commit一个object的时间对于这类业务来说太慢了。
对象存储供应商的选择
究竟是NAS还是对象
在探讨到底该选什么样的对象产品之前，我觉得应该优先思考，到底是采用NAS好还是对象好的问题。
实际上两者确实有大量的业务重叠场景，这也是存储市场大量新兴的对象存储供应商寻找市场突破口的方向。
从使用者的角度来说，首先应该是考虑代价问题，而不是什么架构先进性的问题。对于一个全新的业务需求，也许我们可以更轻松的，不带包袱的去拥抱对象；但是对于一些既有的应用平台，要去尝试更改为对象存储的时候，就需要慎重的考虑，代价是否是可以承受的，而且是愿意承受的。
对于多数组织和系统而言，实际上NAS在运维和管理的难度上都更小；体系也更成熟，对于应用的适配几乎没有难度。非常适合于code能力较弱，或者完全依靠ISV提供应用迭代的组织。
至于扩展性，目前的NAS架构看，几十个PB的容量，上千亿个inode是不成问题的。所以不见得对象就是唯一的解决方案。对象也不是组织解决数据长久保存的万能神药。实现的途径其实有很多种。
举几个简单的例子：
在渲染农场这种业务类型下，对象和NAS同样适用，但是如果你想获得更快的结果输出，那么请选择NAS。
在大数据分析场景下，对象和NAS也同样适用，但是如果你想获得更好的性能提升，请选择NAS。
我想表达的是，所有的架构选择，都是为业务服务的，业务的目标决定了架构的堆栈。上面举得这些例子，不代表对象不好，或者NAS更好，而是我们需要从业务的角度出发，去梳理到底采用那种架构是最适合的，鞋子好不好穿只有脚知道。
该如何选择对象存储的供应商
Public Cloud & On-Premises
合规性、成本这是两个主要的参考指标。
从成本的角度来说，目前公有云提供的对象介质是所有存储形态中最便宜的，独特的租用方式，按容量和流量的双计费对于用户来说，无疑是有巨大的吸引力的。这其实也很大程度上促进了对象存储业务场景的发展。
从合规性的角度来讲，又不是所有的数据都可以上云，虽然云供应商能够从合同规约中提供私密性的保证，但这在绝大多数用户看来，都只是一个君子协定，完全需要行业的自律来满足要约的保障。所以，这也是一个公有云存储发展目前面临的一个巨大问题。
对于组织来说，其实就是在合规性和成本之间作平衡的一个过程。对于绝大数行业来说，尝试公有云提供的服务是一个不错的选择。
但是对数据合规性有着严格要求的组织而言，公有云确实在法规上存在一些限制，以及对公有云行业的行业自律性的担忧。
对于当前传统企业来说，大部分情况下，还是更愿意采用On-Premises的方法来建设自己的对象存储平台。但是这也会显著降低对象存储的成本优势。
尤其在一些几百TB、一个PB左右的小规模的环境中，其实On-Premises方式构建对象平台的成本优势不是那么凸显的。组织仍然需要支付不菲的硬件成本和软件成本，来满足数据存储的需要。
一体机 & 软件
从我的角度来说，如果最终选择On-Premises的方式构建对象存储平台，我会更倾向于采用一体机的方式来构建生产系统。通常情况下，平台供应商会对一体机做更多的工程测试，这对于生产环境来说，会提供更多的可靠性保证。
而初期进行开发验证的环境，我更倾向于采用软件的平台。
所以在考量一个供应商能力的时候，我会综合的评估，它能够提供哪些部署方式，满足组织在不同阶段时期的需要，以更好的控制综合成本。
我更倾向于能够同时提供多种部署方案的供应商，这会向组织提供更为灵活的架构中远期规划，比如在边缘处可以采用更低成本的软件方式，在中心处则强调系统的可靠性，采用一体机的方式构筑。
Multi Site支持
这也是我非常看重的一个特性，在多数组织中，构建对象存储平台时，都会考虑两地三中心，或者多中心的建设规划，那么对于Multi Site的支持，就变得至关重要。
除了基本的Bucket Sync特性之外，在有些环境中还需要将一个Cluster部署在多个Site中，根据组织的合规性需要，将数据分布在不同的站点，这些能力是和组织的战略规划息息相关的，在供应商选择时，也需要慎重的评估对于多站点支持的能力和特性，是否同时满足组织阶段性的需要，和中长期的需要。
容错机制
这其实是一个我不太愿意讨论的话题，在多数情况下，对于object的容错级别其实应该是由业务决定，而不是产品决定。容错机制这也是一个相对复杂的问题，在考虑容错机制时，又得考虑延迟的开销，容量的开销，对于吞吐的影响等等。
从今天的供应商能力来看，你没有办法去评价到底谁的容错机制会更好，因为一切都只能是站在理论角度去看技术的实现，从这个视角去审视的时候，它大多数情况下又不是从业务角度出发的。
比如EC小文件归并这种特性，你不能说它就是个优秀的解决方案，因为在面对小文件时，如果从性能的角度出发，多副本明显对业务的性能提升更大。但是你也不能完全否认这个特性，毕竟它确实解决了小文件EC性能开销的问题。
很多人喜欢掉入到一个架构陷阱，追逐可以同时坏几块盘，可以同时坏几个节点这样的设计上。诚然这些都可以变成可量化的招标指标，但是我们真的有认真的考虑过这些指标对于业务性能和可靠性的价值提升吗？
于我而言，一个分布式的架构，我可能会更关心的是它能够提供的可靠性有多少个9，数据可用性有多少个9。当故障发生后Data Rebuilding、reHash这些后端操作，会对业务会产生多大的影响。这些因素都是在架构设计前我会反复思考的内容，只有清晰了这些线条，才能判断出最终的架构是否是合适的。
所以我的结论还是，从业务的需求出发，选择合适的容错机制。每个供应商都有它的特点，我们只需要选择符合我们业务需求的能力就可以了。
逃不过的真香定律
我们再回过头来，看看最初的问题：
提升检索性能所需要付出的代价，真的低于预期的收益吗？请审慎的评估你的业务流程，如果答案是肯定的，那么大胆的放手去做吧！！
现有的架构真的不能满足PB级的数据存储需要，且替代方案只有对象一种方式吗？如果答案是肯定的，那么大胆的放手去做吧！！
组织内的所有业务都适合用对象存储来改造吗？如果答案是肯定的，那么大胆的放手去做吧！！
当您读到这里时，应该已经在内心深处飞快的对现有的架构做了一个基本的评估，那么您已经走在了正确的道路上，我写这篇文章的目的，其实就是希望大家更客观，更科学的使用对象存储，不要盲目冒进，也不要对新事物缺乏信心。
我想对那些技术的狂热者说：静下心来，回头看看你的NAS平台，你会发现它挺香的。
我也想对那些技术保守者说：可以多看看新的东西，对象存储它确实挺香的。
不管是SAN也好、NAS也好、对象也好，都是数据存储的一种形态和方式，只有选择合适的平台，才能更好的为数字化转型服务。
[阅读原文，请点击如下链接]：
欢迎您关注联想凌拓：https://lenovonetapp.com/
官方微信二维码：
官方B站二维码：
