网易对象存储NOS十周年：为什么能不被取代？（文末有福利）

谨以此文，献给曾经和现在为项目努力付出的小伙伴们，以及相信我们、陪伴项目共同成长的用户，并与业界就服务端产品如何保持生命力进行交流。

2012年10月30日，网易杭州研究院（以下简称杭研）上线了一款新的存储产品，当时兴致勃勃的研发团队，并没有预料到它会如何发展。

十年间，这款产品支撑了网易公司诸多业务的成长，见证了多款明星产品的发展，乃至独立上市。目前，它在网易云音乐、智慧企业、灵犀、传媒、LOFTER、邮箱、严选以及部分游戏等业务中仍然广泛使用。

这款产品，就是NOS，即网易对象存储服务（NetEase Object Storage）。

在软件行业里，尤其是互联网行业，一个项目能持续稳定运行10年极为不易。在行业快速变迁之下，首先能存活10年的互联网公司非常稀少，其次一个项目的架构和版本演进是否还能保持项目原来的模样也很难保证。而NOS不但稳定运行10年（当然也发生过各种各样的故障，但得益于团队小伙伴的技术实力最终都能迅速解决）并且保持架构、功能、存储引擎等持续在线升级，就显得更加尤为不易。

目前看来，NOS项目的生命力还是一如既往的顽强，再运行10年也基本毫无悬念。所以，这是一个值得纪念的日子。

—— 1 ——

NOS介绍

1.1 NOS能干什么？

NOS产品能力简要总结下：

• 用HTTP协议（核心接口兼容S3）存储各种文件（各类文本、图片、视频、压缩包、安装包、DB备份数据、各类访问频次很低的冷数据等），并支持对不同冷热程度的数据进行分级存储

• 通过CDN进行访问加速（包括上传加速、Web加速、下载加速等），对全国跨运营商或全球用户业务非常合适

• 支撑非常大规模的数据量和访问量

• 对图片和视频进行处理（格式转换、加水印、缩略、编解码、截帧等）

• 高可用高可靠低成本免运维的存储系统

1.2 为什么要做NOS？

最早成熟商用的对象存储服务是AWS在2006年提供的S3存储服务，所以目前各大厂商的对象存储产品基本都兼容S3接口协议。可以想象一下，如果没有类似S3的对象存储服务，海量文件要如何方便的存储及跨节点跨平台跨地域访问？很显然传统的存储设备如SAN、NAS、NFS系统等都无法胜任。S3存储系统基于HTTP协议+分布式存储自然就应运而生。

杭研也是2006年为了解决网易博客相册存储而开发的分布式存储系统DFS，后来基于DFS开发了SDFS存储引擎，再后来基于SDFS+DDB（分别存储文件的数据和元数据）开发了NOS。

1.3 NOS凭什么10年不被取代？

业界对象存储系统不论是公有云厂商、私有化部署供应商、开源软件等都有非常多的产品，并且对象存储一直以来都是公有云和私有化部署厂商重点热销产品，可以说是一片红海。那么NOS凭什么能在网易内部运行10年而不被取代？

• 成本：NOS提供相比业界竞品低得多的报价，以100PB总数据量为例（标准:低频=1:1），NOS存储价格（按NOS列表价折扣后的9折计算）是某主流云存储价格的8折左右；对于超大客户（低频存储10PB以上）NOS还有更低折扣。NOS项目存在的首要目标就是成本上要做到公有云标杆竞品的9折以下，公有云厂商基本每年都会进行价格调整，NOS也会持续跟进

• 稳定性：高效的SLA保障能力，近几年每年的SLA都达到预定的99.95%以上

• 服务：包括服务意识，服务能力，定开能力

对于私有化部署产品，NOS通过规模优势来达成更低成本，对于数据量不够大的业务，采购一套私有化部署的对象存储产品或者自己运维一套开源对象存储系统，相比直接使用NOS产品，有如下几个方面的问题：

1. 产品形态不够灵活，导致单位存储成本无法下降：为少量的数据搭建的私有化集群，很难同时支持多种产品形态如标准、低频、归档等，尤其是冷数据通常采用高密度（单机60盘甚至120盘）、大容量（单盘20TB）的存储机型，配合EC纠删码（分片数要足够多才能有更高的存储空间利用率）、服务器、硬盘的下电休眠等技术来实现更低的单位存储成本，搭建一个最小规模的高可用高可靠的集群就要十几台甚至数十台规模，容量可能远超10PB，单靠一项业务的数据永远填不满，沉没成本太高。简单来说就是规模效益无法实现，使用NOS则可以把公司大量业务的数据汇聚之后统一管理，统一考虑更低成本的存储架构，降低边际成本。

2. 无法享受降价红利：公有云厂商几乎每年都会降价，NOS也会及时跟进，这方面私有化部署集群一旦部署之后，成本就确定了无法下降。

3. 运维复杂：至少需要一个运维人员（可能半个人力投入），来处理日常的用户权限管理、配额管理、桶管理、限速限流等，以及容量规划、巡检、硬件故障处理、安全风险处理等等，如有大促等活动，还需要进行弹性资源的规划、申请、上线，以及大促期间的实时支持（前提是需要对象存储服务具备服务降级、弹性扩容等能力），另外还要有完备且可持续（不受人员变动影响）的故障处理能力、应急预案完善度，数据可靠性管控（如数据恢复期间的可靠性管理等）。

4. 故障/问题处理能力：系统稳定性是除成本之外最高优先级要保障的。无论使用成熟的商业产品还是用开源对象存储软件自己搭建集群，都面临故障处理的及时性、高效性等问题，成熟的商业软件相对好一些，但也有技术支持的及时性问题存在（即使购买7*24支持服务，也面临问题分析，权限申请等一系列问题）。如果是使用开源软件就面临更大的挑战，没有研发团队支持/兜底的开源软件，使用成本是最高的，一旦出现故障将面临无人可解决的尴尬境地。使用NOS的情况下，用户完全不需要考虑此类问题，全部由NOS研发和运维团队兜底解决。

5. 架构升级和定制化开发能力：无论是商业软件还是开源软件，架构升级都是一项很有挑战的事情，商业软件在维保一定时间后也会进入完全的维护阶段（不再支持升级，或者只能使用新版本部署新集群），开源软件更面临类似问题，由于不了解新版本新架构的问题和风险，定期升级几乎无法实现（除非有研发团队兜底）。定制化开发方面商业软件和开源软件都是不支持的（除非有研发团队支持）。NOS则会定期升级让业务享受到最新的架构成果，定制化开发也可以及时响应，这些成本其实都是NOS团队兜底没有额外收取的。

当然，即使有上面的这些优势，NOS项目还要不断探索、进化创新，跟业务在一起，持续保持竞争优势，才能走得更远。

—— 2 ——

NOS历史

2.1 这10年NOS都做了什么？ 

NOS之所以到2019年10月份才实现盈亏平衡，最大的原因就是之前的容量太少，无法实现规模效益，边际成本过高，这就带来两个问题：

• 边际成本无法持续降低：导致单TB存储成本无法下降，业务无法受益，相比竞品也没有价格优势

• 团队人员不稳：团队没有业务就没有发展，团队成员就没有发展，导致离职频繁，NOS系统的稳定性必然也会受到挑战

这里有个恶性循环，必须要业务和NOS团队共同努力将其打破，才能实现互利共赢： 

NOS团队的行动：

• 规模：则先做存量数据的升级，存量数据迁移后利旧服务器架构升级后再继续用来存新数据

• 成本：开发上线新的低价产品如低频存储，提升用户使用体验和数据可靠性，做好案例宣传，规模效益上来后给大客户降价，持续扩大规模，更利于技术创新，降低边际成本

• 团队：通过持续的业务发展来给团队增强信心，通过设定业界领先的技术挑战目标来体现人才价值获得成就感

私有云NOS集群容量增长曲线，其中低频、冷归档存储占比超过60%。公有云集群数据没有包括在内。

2.2 架构变化

十年来NOS整体架构总体做了多次较大的升级重构，模块/组件内的重构升级则更是多不胜数，这里仅介绍整体架构的变化情况。

2013年：架构雏形 

2015年：架构改进

随着业务数据量的增长和数据可靠性可用性要求提升，NOS开始引入多分区方案/NEFS三副本。 

2018年：产品形态完善升级

丰富产品形态，引入低频存储，做好各类存储引擎的管控。 

2020年以来：数据可靠性和用户体验优化

• 认证：增加降级功能，增强数据认证的稳定

• CDN：OSS专线回源方案，给所有业务线进行降本

• 直传：利用海外CDN能力，降低延时和带宽能力

• 数据生命周期管理：增强数据的转存性能，提升存储空间利用率

• 富媒体：与视频云团队共建富媒体视频方面的能力

• 存储引擎拓展：兼容三副本，低频，Ceph，S3，OSS等主流存储

• 产品形态：新增归档、冷归档类型

2.3 怎么保持10年稳定运营？

以下从NOS视角总结了一些关键因素。事实上，这些因素也是杭研其他优秀技术产品的立身之本，更是杭研孵化的企业服务业务网易数帆能够获得不同行业300多家大中型客户认可的重要原因。

持续创新（从1到1.1再到10）

具体的技术细节这里不打算讲，这里简单举几个业务场景使用NOS的变化。

如果你在10年前存入了一个文件到NOS系统，那么你的这个文件所在的机房、服务器、硬盘、存储引擎类型应该已经发生了多次变更，引擎的迭代升级、存储服务器优化选型是我们一直在默默进行的。但是对业务来说文件还是那个文件，他一直都在NOS里，看起来没有任何变化。

另外你在10年前上传和访问文件的路径、带宽、时延等和现在上传肯定也是不同的，海外用户感受会尤其明显，我们对直传、分块上传、CDN加速上传、BGP 3线加速、静态BGP、OSS回源等方面做了架构演进，这一切都是为了改善用户体验和降本。

你在10年前上传一张图片到NOS，如果你要对它添加水印，甚至为了防止盗图添加肉眼不可见的盲水印，或者根据不同的设备进行分辨率、图片格式的自适应适配，那需要你在上传之前本地先处理好才行，现在则只需要在访问图片的时候加入不同的参数即可实时生成所需图片。

你在10年前如果要做冷热数据分等级存储，也是做不到的，只有3副本可选（在没有EC低频方案之前还做了2副本方案），现在你可以把不同冷热程度的数据存到标准、低频、归档、冷归档这些NOS存储类型中，做到按需存储，成本最优。

诸如此类的创新和功能、架构升级，这10年来从未间断，我认为更难能可贵的是这些变化对业务基本都是透明无感的，这一点非常重要但也极具挑战，业界更普遍的做法通常是新业务用新系统，老业务用老系统，逐步完成新老切换，而NOS则一直只有一套系统在生产环境运行。

我相信未来还会有更多贴合用户需求的创新能力加入到NOS中。

注重长期规划（与用户在一起）

什么叫长期规划？我的理解是，架构设计要考虑未来3~5年的业务增长和相关诉求，另外还要结合业界竞品的发展情况来综合考虑当前的开发规划。

举例，最开始的时候NOS只有几台机器，架构也都是耦合在一起，当2013年易信业务上线后，大量的请求直接打爆了NOS服务。之后的架构就开始解耦，并且在各类方案设计的时候就会考虑可扩展性和可用性。

再比如，SDFS引擎上线多年后，出现了各种各样的问题，已经不太能适应新的硬件和业务需求，于是NOS团队就规划设计了新的NEFS引擎。再之后业务对更低成本的低频存储的诉求越来越强烈，新的EC纠删码引擎也开始规划落地，目前低频存储已经占据NOS近70%的存储量。一个新引擎的发布上线到完成可靠性可用性验证，通常需要至少1年的观察期，2年左右才敢大规模推广使用，这些都需要长期持续性的规划完善。

另外，每个团队都面临人员变动情况，NOS也不例外，也有一些组件因为其复杂度和处于维护状态导致新接手的同学无法深入内部实现细节，导致了一些线上故障发生后没能第一时间解决掉（甚至没能提前发现并规避），但至少团队一直在做这方面的长期规划，每个腐化组件都有排期下线或负责掌控人员的安排，最终所有组件都要在团队掌控之中。

最后，对于业务提出的定制化开发需求，NOS团队也不是无脑接受，也要跟业务对齐需求的必要性、合理性和普适性，只有满足这几点的需求我们才会安排开发，如果NOS开发了太多的与特定业务强绑定的特殊功能，那么项目的长期可维护性就会受到极大挑战，过不了几年就会被各种腐化组件搞得尾大不掉，如果一个团队长期维护很多腐化组件，成员的稳定性也就非常难以保证，毕竟谁也不愿意做无用功，干没意义的工作，成员不稳定最终的后果就是NOS服务的不稳定。

不让同类故障发生第二次

故障总是会发生，软件开发的读者应该可以理解我这句话的意思。第一次发生一个未知故障，总能找出来各种各样的原因，回溯出来各种各样的临时的、长期的解决方案。要考核一个团队的系统维护能力，可以观察他们能否保证同类故障只发生一次，我认为这是非常简单且有效的手段。

只要你能保证同类故障不发生两次，那故障就会越来越少（不能保证不出故障），这也是NOS团队的目标和行动思路。

历任功臣的努力（热爱）

另外比较关键的一点是，NOS的历任开发和QA同学都抱着对项目负责的态度在做事情，尽量少挖坑。虽说有些周边项目组件摊子铺的有点多有点大，但是都在可控范围内，也是基于当时的架构和业务需求状况做出的合理决策。NOS团队对核心存储业务相关改造都是非常谨慎的，也保证了NOS的持续稳定运行。举例来说，NEFS存储引擎上线就经历了半年以上的验证期，在此期间业务的数据是同时存在SDFS和NEFS集群中的，相当于6副本，从而保证新引擎的数据可靠性。这部分的成本其实是NOS项目承受了的，类似的引擎升级等操作还有EC低频引擎。

我之前做过很长时间的云计算平台OpenStack开发维护，与做存储相比，计算平台最大的故障就是停机，业务中断，一旦故障恢复，业务就可以继续恢复运行。而存储平台则不一样，最大的故障是数据丢失，数据丢失的后果可想而知，可能导致业务永远无法恢复到故障前的状态。因此存储团队的同学每次做大的架构升级都如履薄冰、如临深渊，遇到故障的第一个问题通常都是会不会导致数据丢失。在数据可靠性方面，NOS的历任团队同学都是值得称赞的，目前NOS还没有发生过较大规模的数据丢失问题。

2.4 NOS功臣访谈

前面提到NOS的历任功臣，有几位还网易工作，只是换了部门和岗位，包括小歪、木心、静山和QA倾城等。他们如何回忆NOS的过去，对NOS的未来有何期待？

2.4.1 小歪

参与了最初版本NOS的开发上线，并负责NOS项目多年。

Q：负责NOS项目期间有哪些印象深刻的里程碑节点？

SDFS和NOS可以说是伴随我们团队成长的项目，从2010年开始做SDFS到2015年NOS基本成型离开团队，无论是在开发和架构等技术能力，还是在基层团队管理和项目管理等管理能力上，都有了很大的提升。这中间经历的影响深刻的事件有很多，总结成几个“最”来描述：

• 最艰难的时刻：无疑是易信上线后的大故障，造成所有NOS用户断断续续不可用，抢修大约8小时才完全恢复，惊得团队每个人一身冷汗；

• 进步最大的时段：针对易信故障我们进行了全面的架构梳理、完善的性能测试、完备的故障演练，使得NOS的SLA在未来几年内基本在线；

• 最顺利的规划：从最开始只提供存储服务，到实现了图片&音视频等富媒体处理，再到针对公司互联网业务特点对接CDN&实现C端用户上传加速。

Q：你对NOS的未来有何期待或建议？

总的来说是一句话“保下限，拉上限”，守住不出现系统性服务不可用或数据丢失的下限，进一步拉升在“降本、优化用户体验、数据应用场景”等方面的上限。

2.4.2 木心

比来小歪稍微晚一点加入NOS项目，也是负责NOS多年，富媒体服务、NEFS引擎的核心贡献者之一。

Q：负责NOS项目期间有哪些印象深刻的里程碑节点？

• 2015年底：开始独立负责NOS整块业务线，压力有点大，网易所有的互联网的对象存储几乎都在上面。

• 2016年：某天凌晨3点，PE打来打电话说，一个预期的运维操作，导致NOS写入整体100%失败，一起处理了2个小时依然没有恢复，心想着如果到了上班时间还未恢复，接下来可能就是血雨腥风。所幸后面一顿骚操作就恢复了，这可能是NOS历史上最惊险的一夜。

• 2016年：对象存储开始做公有云产品化工作。正儿八经产品化相比一个内部服务来说，无论从功能和架构都提出了更高的要求，NOS整体从日志、运维、架构等整体相比于之前有了很大的升级，有一种鸟枪换炮的感觉。

• 2018年：传媒产品由于进行较为严格的成本管理，对NOS的成本提出异议，开始逼NOS降价。这是典型的业务倒逼技术成长的经典案例，这一年NOS开始快马加鞭基于Ceph Rados引擎的EC纠删码方案构建低频存储产品来帮业务降低存储成本。

这要感谢传媒的鲶鱼行为，如果不是当初的逼宫，从成本看NOS可能已经完全没有竞争力，而作为技术负责人这是一件挺耻辱的事情。

Q：你对NOS的未来有何期待或建议？

接下来继续踏踏实实服务好用户，持续保障产品的稳定性和竞争力。保持存储产品线的重要核心基本素质—踏实，严谨。

2.4.3 静山

多年来一直负责NOS的运维工作，SLA的扛把子，目前仍在负责NOS运维，对NOS历次故障如数家珍，对NOS开发的bug修复和新特性方案总能提出金点子，设计方案的终极把关者，具有一票否决权。

Q：负责NOS项目期间有哪些印象深刻的里程碑节点？

NOS项目初始就对运维很重视，第一个部署文档是当时的项目leader大饼哥亲自写的，写得很详细，现在还是杭研内部运维类文档的范本。

作为运维，对NOS印象比较深的都是一些事故^_^，比如NEFS之前出现过线上bug，当时团队开发和运维一起小黑屋找了很久，先分析日志，确定方向，开发线下验证，共同解决问题。这样的例子还有很多，都是靠团队的力量一路过关斩将，创造出现在稳定可靠的NOS基本特质。

Q：你对NOS的未来有何期待或建议？

期待NOS能在保持稳定的同时，性能和可扩展性再上一个台阶，适配更多的应用场景。进一步确立在存储领域“场景通用，使用可靠，成本经济”的市场定位。

2.4.4 QA倾城

做了近6年NOS的QA工作，也对NOS近几年的质量管理标准和流程做了大量工作，近两年除核心数据面变更、存储引擎的升级和新的存储产品形态（如归档、冷归档等）需要专门的测试人力外，其余NOS日常测试工作基本已经实现完全自动化，节省了大量测试人力并提升了版本发布效率和质量。

Q2：负责NOS项目期间有哪些印象深刻的里程碑节点？

印象比较深刻的节点和事件有：

• 公有云的上线以及转到维护和自动化回归测试能力完善，再也不用QA跟着开发、运维同学一起在凌晨上线了

• NEFS新三副本系统上线以及后续的Ceph各种存储产品形态的上线，为NOS支撑更多业务、节约更多成本打下了基础

• NOS存储的数据量在近3年翻了一番，大大超出了我的想象（因为我入职的时候各大核心产品基本都已经都用上NOS了，年数据量增长率其实并没有支撑容量翻倍的趋势），也让我对NOS以后的发展更有信心了

印象比较深刻的用户主要是传媒事业部，他们是NOS降本动力最大的来源，也是NOS能在公司内部推广起来的标杆用户，用户的压力就是NOS的动力。 

Q：你对NOS的未来有何期待或建议？

希望技术上有更深层次革新，多了解业界发展情况，多了解业务诉求，在低成本、高可用、高可靠方面能引领行业发展。

—— 3 ——

NOS现状

目前NOS团队有5位研发小伙伴和数位非全职DBA运维同学，团队小伙伴们个个身怀绝技。团队核心目标我理解有3点：

• 为业务提供高质量、高可靠、低成本的对象存储服务

• 对外商业化模式探索，保持盈亏平衡和长期可持续运营

• 持续的技术创新，做好技术预研储备，更好的服务业务

核心业务模块主要分为3大块：

• 数据存储服务：目前NOS已支持标准、低频、归档、冷归档共4种存储产品形态，价格依次降低，业务可根据自身需求和数据访问频次等选择使用，另外包括周边的直传、SDK、上传加速、生命周期管理服务、数据清理服务等等

• 富媒体服务：包括图片的实时处理、与视频云共建的视频转码等的处理服务
  

• CDN服务：基于融合CDN产品提供

另外还有周边的统计计费服务、运维大盘、监控平台等。

团队近期的工作目标主要分为如下几个方面：

• 降本增效：包括NOS内部降本（高密存储机适配、集群整合利旧、空间利用率提升、集群性能提升、富媒体算力混部等），以及业务方的成本优化（保持盈亏平衡的前提下NOS产品对业务降价）

• 技术创新：引入或自研新的存储技术，改进或重构NOS周边服务，提升NOS的业务服务能力和稳定性，持续降本

• 业务支撑：业务需求的定制化开发，保障用户体验和使用便利性

• 业务拓展：包括内部新业务的拓展接入，外部商业化机会的探索，寻求更大的发展空间

当前NOS项目面临的挑战主要是存储的数据量和资源池还不够大，有些创新技术需要一定的数据量和IDC基础设施支撑才能落地，比如自研归档或者冷归档方案，最小规模的集群就需要数十PB才能填满，如数据量不足则会造成极大浪费，新技术带来的成本节约和空间浪费相比显得非常得不偿失，目前NOS的各种创新可以算得上是螺丝壳里做道场。

—— 4 ——

NOS未来

业界对象存储的发展方向非常广泛，比如存算分离的存储底座（大数据/数据湖、AI训练、分布式文件系统等），以及数据库（ClickHouse）、监控（Prometheus）、日志（Elasticsearch）等的冷数据存储底座，有一统存储江湖的趋势。

对象存储自身的发展方向如智能数据分层、基于Serverless的富媒体处理、单位存储成本优化等。

NOS结合自身情况，未来1~3年的初步规划主要是：

• Curve×NOS：打造AI训练、ES/CK等业务场景下冷热数据存储最佳组合

• 智能数据分层：更加智能易用的数据生命周期管理能力，帮业务分析并完成数据冷热存储的智能转换，节约更多成本

• 性能优化：提升整体带宽、降低上传下载时延，优化用户体验和服务能力

• 灾备能力增强：为灾备能力要求更高的业务提供跨地域的数据高可用高可靠能力

• 自研归档增强：结合新的IDC条件、新型硬件、软件创新等条件提升自研归档方案的竞争力

• 第三次机房搬迁准备：IDC机房搬迁准备工作，要跨越几千里进行在线数据迁移，比前两次的同城搬迁的挑战要高出很多；当然这也是一个绝佳的系统架构升级机会，新的集群部署规划，新的IDC设施更能支撑NOS的创新应用和落地。

路漫漫其修远兮，吾将上下而求索。期待NOS的下一个十年与公司各大业务线共同成长，早日达成EB级数据存储量，为公司节约更多成本。

作者简介：王盼，网易杭州研究院云存储团队负责人，Curve开源社区PMC

---

彩蛋：网易杭研NOS请我喝咖啡

感谢读者的阅读。以下为NOS团队提供的三道选择题，扣“网易杭研NOS请我喝咖啡，暗号+（你选择的答案）”转发本文到朋友圈，并于11月1日前截图发送至本公众号，答案完全正确且点赞排名最高的10位读者，将获得NOS团队送出的咖啡券一张。

1. NOS的产品形态不包括哪个？

A. 标准存储  B. 低频存储  C. 高性能块存储  D. 归档存储

2. 大家使用过的网易服务中，下列哪个可能不包括NOS的直接支撑？

A. 网易严选商品介绍  B. 网易云音乐Mlog  C. 网易体育新闻  D. 阴阳师游戏副本

3. NOS能够稳定运营十年，主要原因不包括以下哪项？

A. 不让同类故障发生第二次  B. 注重长期规划  C. 第一时间引入最新技术  D. 确保低成本

获奖名单将于本周后续文章中公布。小编也会在后台联系获奖者颁发奖品。欢迎大家积极参与！