内容简介:在《从“软件”到“服务”——【对象存储】的发展历程(上)》中,我们和大家在对象存储大规模普及之前,大量的数据存储和处理是怎么实现的。但这些方案大都专注于解决其中一类问题,缺少足够的普适性。那么对象存储出现后,究竟解决了什么问题?优势又为何呢?软件 V.S 服务
在《从“软件”到“服务”——【对象存储】的发展历程(上)》中,我们和大家在对象存储大规模普及之前,大量的数据存储和处理是怎么实现的。但这些方案大都专注于解决其中一类问题,缺少足够的普适性。那么对象存储出现后,究竟解决了什么问题?优势又为何呢?
1 .
软件 V.S 服务
跟上一篇提到的各个软件相比,对象存储与之最大的区别不在于实现的机制,而在于形态从软件到服务的一个大飞跃。在这儿我想用一个可能不太恰当的比喻来说这事——传统的体重计。
不管是电子的还是机械的,他只是一个工具,我们评价的标准更多是价格、准确度、易用性、量程。而互联网的体重计,能帮你记录你的体重变化曲线,你关心的可能更多是数据联动、可视化、以及根据你的体重给出的建议。当然,如果你真的对减肥有强烈的需求,那么找一个合适的教练,由教练来指导你的减肥流程才合适,而互联网体重计只是教练手中的一个 工具 而已。
服务跟软件相比,有几个大的不同点:
-
首先是 自由演化 ——对象存储的客户可以只关心SLA,并不关心你实现SLA的手段,所以演化更自由;
-
其次是使用服务完全不用关心 运维问题 ——运维问题完全交给服务提供商来解决;
-
最后是采用服务形态后,业务的 架构方式 更灵活——比如控制面和数据面分离更轻松等。
作为一个部署在云端的服务,它的接口和实现是分离的,也就是说我可以在保持接口不变的情况下持续演化实现。我们可以想象一下第一次在 AWS S3 上传的数据还有一些直到今天也没有删除,但这些数据可能已经经历了很多代的硬盘(毕竟硬盘的寿命一般也就3-5年),以及很多代的存储引擎了。 这也是与传统存储软件不同的地方,传统存储软件如果大幅度更改了架构,那么通常是以一个新的存储软件的形式来出现。
背后的原因至少有两点:
-
不同存储引擎之间的平滑过渡和数据迁移难度很高,耗时很长,风险也很大,对于软件的使用者来讲根本不愿承受这些风险;
-
每个存储引擎都有自己的优缺点,如果是服务的提供方,还能接受新引擎的缺点,也能通过硬件或者使用其他方式来弥补,但作为软件来使用的话,部分喜欢老版本优点的用户会长期停留在老版本,这经常会导致社区的分裂。
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
推荐阅读
*点击“ 阅读原文 ”免费领取京东云 10GB对象存储额度
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 畅谈云原生(上)
- 畅谈云原生(下):云原生的飞轮理论
- 卡巴斯基、启明星辰、上海控安专家畅谈工控安全
- 2019全球智博会高峰论坛圆满召开,18位学界、业界大牛畅谈AI应用与落地
- 公有链MagnaChain喜提CJ 舞台C位,CTO肉松畅谈链游技术及生态布局
- 聚人才畅谈小游戏发展机遇,2018白鹭HTML5开发者沙龙武汉站干货再升级
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Ruby元编程(第2版)
[意] Paolo Perrotta / 廖志刚 / 华中科技大学出版社 / 2015-8-1 / 68.80
《Ruby元编程(第2版)》在大量剖析实例代码的基础上循序渐进地介绍Ruby特有的实用编程技巧。通过分析案例、讲解例题、回顾Ruby类库的实现细节,作者不仅向读者展示了元编程的优势及其解决问题的方式,更详细列出33种发挥其优势的编程技巧。本书堪称动态语言设计模式。Ruby之父松本行弘作序推荐。一起来看看 《Ruby元编程(第2版)》 这本书的介绍吧!