从“软件”到“cdn加速服务”【对象存储】的发

1.软件V.S服务
跟上一篇提到的各个软件相比，对象存储与之最大的区别不在于实现的机制，而在于形态从软件到服务的一个大飞跃。在这儿我想用一个可能不太恰当的比喻来说这事——传统的体重计。
不管是电子的还是机械的，他只是一个工具，我们评价的标准更多是价格、准确度、易用性、量程。而互联网的体重计，能帮你记录你的体重变化曲线，你关心的可能更多是数据联动、可视化、以及根据你的体重给出的建议。当然，如果你真的对减肥有强烈的需求，那么找一个合适的教练，由教练来指导你的减肥流程才合适，而互联网体重计只是教练手中的一个工具而已。推荐阅读：《如何防范国内CDN加速中小老鼠》
服务跟软件相比，有几个大的不同点：
首先是自由演化——对象存储的客户可以只关心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的支持。

 

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的支持。