畅谈 | 从“软件”到“服务”——【对象存储】的发展历程(下)

栏目: 后端 · 发布时间: 5年前

内容简介:在《从“软件”到“服务”——【对象存储】的发展历程(上)》中,我们和大家在对象存储大规模普及之前,大量的数据存储和处理是怎么实现的。但这些方案大都专注于解决其中一类问题,缺少足够的普适性。那么对象存储出现后,究竟解决了什么问题?优势又为何呢?软件 V.S 服务

在《从“软件”到“服务”——【对象存储】的发展历程(上)》中,我们和大家在对象存储大规模普及之前,大量的数据存储和处理是怎么实现的。但这些方案大都专注于解决其中一类问题,缺少足够的普适性。那么对象存储出现后,究竟解决了什么问题?优势又为何呢?

1 .

软件 V.S 服务

跟上一篇提到的各个软件相比,对象存储与之最大的区别不在于实现的机制,而在于形态从软件到服务的一个大飞跃。在这儿我想用一个可能不太恰当的比喻来说这事——传统的体重计。

不管是电子的还是机械的,他只是一个工具,我们评价的标准更多是价格、准确度、易用性、量程。而互联网的体重计,能帮你记录你的体重变化曲线,你关心的可能更多是数据联动、可视化、以及根据你的体重给出的建议。当然,如果你真的对减肥有强烈的需求,那么找一个合适的教练,由教练来指导你的减肥流程才合适,而互联网体重计只是教练手中的一个 工具 而已。

服务跟软件相比,有几个大的不同点:

  • 首先是 自由演化 ——对象存储的客户可以只关心SLA,并不关心你实现SLA的手段,所以演化更自由;

  • 其次是使用服务完全不用关心 运维问题 ——运维问题完全交给服务提供商来解决;

  • 最后是采用服务形态后,业务的 架构方式 更灵活——比如控制面和数据面分离更轻松等。

作为一个部署在云端的服务,它的接口和实现是分离的,也就是说我可以在保持接口不变的情况下持续演化实现。我们可以想象一下第一次在 AWS S3 上传的数据还有一些直到今天也没有删除,但这些数据可能已经经历了很多代的硬盘(毕竟硬盘的寿命一般也就3-5年),以及很多代的存储引擎了。 这也是与传统存储软件不同的地方,传统存储软件如果大幅度更改了架构,那么通常是以一个新的存储软件的形式来出现。

背后的原因至少有两点:

  1. 不同存储引擎之间的平滑过渡和数据迁移难度很高,耗时很长,风险也很大,对于软件的使用者来讲根本不愿承受这些风险;

  2. 每个存储引擎都有自己的优缺点,如果是服务的提供方,还能接受新引擎的缺点,也能通过硬件或者使用其他方式来弥补,但作为软件来使用的话,部分喜欢老版本优点的用户会长期停留在老版本,这经常会导致社区的分裂。

2 .

传统存储  V.S  对象存储

存储类的软件 运维 永远是一个问题,磁盘的寿命一般是3~5年,在3副本的情况下,1PB存储需要300块10TB硬盘,5年总共260周,也就是说,平均每周都要进行一次以上的硬盘更换操作。而采用对象存储,对应的麻烦一般交给服务供应商来解决。服务供应商一般会选择将坏盘留在机架上,等服务器到期后一次性销毁,来降低运维成本。此外,为了避免单机架、单AZ(Available Zone,可用区,一般一个AZ对应一个机房,两个AZ之间间距不低于20km,且不高于100km)故障导致数据不可用,一般还会采用一些反亲和策略,比如同一数据的多个副本,放在3个机架上,并且至少两个不同的AZ来存储。

跟运维相关的 采购负担 也是使用存储软件的一个大难题,在很多业务刚开始推广时,并不知道需要多少存储和上传带宽。如果按照上限准备,势必造成大量的浪费。如果准备不足,一旦存储用满,客户无法上传,就是影响运营的超大事故。而使用对象存储,这些问题都不再存在。

采用对象存储后,我们可以更方便地引入控制流和数据流分离。以一个UGC(User-generated content,用户生成内容,比如抖音、快手)类型的图片或者短视频网站为例,如果控制流和数据流不分离,那么为了提供用户访问网站的体验,我们需要租赁优质的多线BGP机房,这类机房的带宽成本非常昂贵,而图片和短视频的带宽需求巨大(主要是上传所需的带宽和CDN回源所需的带宽),造成总成本过高。如果把图片/短视频相关的上传和CDN都挪到对象存储服务商,只把控制相关的部分保留在昂贵的多线BGP机房。首先是上传基本免费,如果租赁同一个服务商的CDN,CDN回源费用也可以打折,而上传、下载的质量保证则由服务商去做保证, 在获得足够质量的同时能大幅度节省费用。 由于对象存储一般提供各类回调功能和转码功能,所以你 原有的功能需求一般也能通过架构微调来满足。

除此之外,对象存储服务还能 提供完全无缝的迁移方案 ,利用镜像存储等功能,可以做到在 迁移时,终端用户完全无感知。 比如从原始存储站点A迁移到对象存储B,一般步骤如下:

在B上配置镜像存 储,保证在对象存储无法取到文件时,可以去原始存储站点A读取, 保证服务可用

开始测试B站点,确保功能没有问题

通过DNS调整,灰度部分用户的下载到对象存储站点B,确认功能正常

从A站点到B站点做离线的批量迁移,保证绝大部分数据在B站点存在

切换全部下载到B站点

切换全部上传到B站点,此后A站点进入只读

最后再做一遍A站点数据的全量迁移和校验

最后清理A站点所用的资源

当然实际情况可能会更复杂,比如还涉及到图片转码等功能的迁移。

3 .

对象存储在中国的特色扩展 

图片和音视频处理算是很有中国特色的一个对象存储的扩展了, 这也 中国的对象存储发展跟富媒体网站的兴起时间重叠有一定的关系。 基于对象存储的富媒体处理的好处不仅仅在于简化了使用流程,免除了客户自己维护图片转码集群负担,还大幅度降低了图片相关的安全风险。众所周知,图片相关的 libjpeg, libpng 等库是安全漏洞的重灾区,UGC类的业务很难避免黑客上传恶意图片来攻击。对象存储的供应商能使用的手段也不仅仅是紧盯CVE及时升级,还包括了使用容器来加固转码引擎,定期清理容器来避免APT攻击等手段。

畅谈 | 从“软件”到“服务”——【对象存储】的发展历程(下)

综上所述,采用对象存储,跟采用存储软件相比,最主要的收益来自于运维负担、采购风险转移给了对象存储供应商,其次的收益还包括更灵活的架构于使用方式。其实对象存储的功能还有很多,如果对象存储兼容常用的 S3 协议的话,对应的生态也很强大,不仅有大量的工具,常见的框架一般也有S3的支持。

畅谈 | 从“软件”到“服务”——【对象存储】的发展历程(下)

畅谈 | 从“软件”到“服务”——【对象存储】的发展历程(下)

RECOMMEND

推荐阅读

畅谈 | 从“软件”到“服务”——【对象存储】的发展历程(下)


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Ruby元编程(第2版)

Ruby元编程(第2版)

[意] Paolo Perrotta / 廖志刚 / 华中科技大学出版社 / 2015-8-1 / 68.80

《Ruby元编程(第2版)》在大量剖析实例代码的基础上循序渐进地介绍Ruby特有的实用编程技巧。通过分析案例、讲解例题、回顾Ruby类库的实现细节,作者不仅向读者展示了元编程的优势及其解决问题的方式,更详细列出33种发挥其优势的编程技巧。本书堪称动态语言设计模式。Ruby之父松本行弘作序推荐。一起来看看 《Ruby元编程(第2版)》 这本书的介绍吧!

MD5 加密
MD5 加密

MD5 加密工具

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具