写点什么

云存储服务的可用性——从又拍网看云存储服务

2012 年 2 月 14 日

“云”这个概念在今年非常的火热,2 年前国内的云存储服务还只有又拍云存储一家,如今国内已不下十家,面对如此多的云服务商,选择云服务的标准成了大家比较关注的问题。我们很荣幸在 InfoQ 与大家交流一些心得。

我们在六年的云服务经验基础上沉淀了三个词:安全稳定、快速、易用。

一、安全稳定

云服务的安全隐患大致会出现在两个方面:第一是服务的持续可用;第二是数据的丢失和泄漏。

今年很多云服务平台屡屡爆出服务宕机或丢失数据的问题,这让大家对国内云服务更加的不放心, 其实云计算并不应该存在这类严重问题,云计算的主要使命之一恰恰是解决稳定和安全隐患问题。如 SAE 类 PaaS 云计算平台是保障我们网站应用的正常服务,高度容错且可扩展,而又拍云存储则属 IaaS 类云计算平台,存储数据的稳定和安全保障是云存储最主要的工作。

先说持续可用性的保证问题。无单点是一个云服务的基础,而目前很多云服务是单点的,所以致使故障频发。一个真正的云计算平台至少应该保证有两个互相热备的数据中心,三分以上分布不同机柜和机房的数据,在机房引入的线路上也应该保证至少电信、联通有两根以上的线路。只有这样才能保证不论是机房断电、硬盘故障、还是断线,都能保持持续的访问。另外就是对于服务器集群的部署上要实现负载的均衡,可采用服务器 HA 互备,lvs 进行 4 层负载,7 层 nginx 进行一致性 hash 及冷热文件调度,一旦有服务器出现硬件故障,前端调度会自动识别并剥离出集群,确保不影响用户每一次的实际访问。

为充分发挥 Nginx 的 7 层代理的优势,我们在此基础上加入了较多的业务模块,如:一致性HASH模块,根据业务需求通过请求信息进行计算,把请求统一分发到后端缓存服务器,避免使用普通负载均衡方式而导致缓存命中率降低,可大大提高缓存集群的业务处理能力 ;缓存调度模块,基于 LRU 和 MRU 算法对全局的所有访问 URL 进行热度分类,从客户端发起的请求到达 Nginx 就能快速确定该请求是否属于热门缓存,而直接到 SSD 磁盘获取资源 ;统计模块,在 Nginx 内部对所有访问 URL 进行统计并汇总,定期向后端业务系统发送统计报告,使得我们可以对客户提供实时的流量统计查询服务,这也是服务计费的标准 ;

再说数据的安全和泄漏问题。安全性的解决主要是通过多样的备份机制,像云存储主要依托在不同服务器上实现动态的实时三备份,也就是说会自动搜寻用户的数据是否存在 3 份,如没有自动选取服务器生成,这种机制可以完全的保证数据的安全。数据泄漏是使用第三方云计算的最大忧虑,因为云计算的 API 开放性,决定了云计算服务在安全性上的隐患更加大。目前通用的解决办法是采用 128 位 AES 加密码保护,以及权限控制,但是其实目前还没有绝对的办法可以杜绝数据部署在云上的泄漏问题。云存储目前主要是托管用户的公开数据,及网站上本身提供给用户访问的数据。

二、快速

快速是互联网平台发展的基石,优秀的速度才能创造有利于增长的用户体验。但是传统的 IDC 部署方式下,受限于硬件规模和存储架构的影响,通常速度很难发挥。这时候云存储就能发挥作用了,其集群服务器部署的方式,能最大的发挥数据运算的效率。开发者在评估云存储服务的速度时,应该看看他们有没有全国分布的 CDN 加速网络,如果没有通常速度都无法保证,严格来说,云服务是需要具备 CDN 节点的。

再就是看这个云服务的 CDN 部署架构是否优良,这个对速度的影响非常大。云存储 CDN 架构采用各地方缓存节点、核心缓存层、中心数据机房,3 层结构部署,前端智能 DNS 调度用户到该用户访问最快的节点,地方缓存节点会保持连接 2 个核心缓存机房做负载均衡及相互备用,避免单路网络问题。核心缓存机房通过多条线路互备到数据机房读取文件。

三、易用

云服务因为其弹性扩容的特点,大幅度降低了互联网平台的运维规划压力。但同时他也有可能需要做一些额外的对接开发,因此易用就非常重要。好的云服务会开放高度可用的 API,让用户系统极容易与云平台对接。如果云平台的 API 不够优秀,会让开发者的对接成本以及后续维护成本都非常的高。最好的云服务,应该有一些基于云的处理功能,去帮助用户节省一些工作时间和成本。比如又拍云存储,我们做了 10 种缩略图自定义、文件防盗链、以及与各种第三方平台系统的对接插件,以使得用户易用性更高。

最后给大家一个建议,如何去选择云服务。我们知道亚马逊的云服务划分为 EC2 和 S3 两块,EC2 专用于网站的计算,而 S3 专用于静态文件的存储。在国内目前还没有公司具备亚马逊这样的云服务能力,因此建议大家可以考虑把网站托管到云主机,而静态文件托管到云存储。而对于数据库这类有高要求的数据应用,还是建议大家使用托管的物理服务器,毕竟目前云主机的性能和稳定性方面仍有待观察。


感谢金明对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ )或者腾讯微博( @InfoQ )关注我们,并与我们的编辑和其他读者朋友交流。

2012 年 2 月 14 日 00:006979

评论

发布
暂无评论
发现更多内容

Week_04作业+总结

golangboy

极客大学架构师训练营

桂林漫游流水记

穿过生命散发芬芳

美食 旅行

算法判断循环链表、数据工程师练级攻略、python从入门到精通、UML精粹读后感、John 易筋 ARTS 打卡 Week 22

John(易筋)

ARTS 打卡计划 UML精粹 数据工程师必备技能 python从入门到精通 循环链表

从理论到工具:带你全面了解自动化测试框架

陈琦

开源 DevOps 工具 自动化测试

week-4-part2 学习总结

陈龙

架构师训练营第4周:系统架构

子青

灯下黑中的自己

非著名程序员

个人成长 管理 管理者

几行代码轻松实现跨系统传递 traceId,再也不用担心对不上日志了!

程序员小航

Java 日志 链路追踪 工作笔记 traceId

第四周 系统架构 作业一

应鹏

极客大学架构师训练营 课程作业

天下武功何其多,到底该用哪一拨 - Week 4 - 学习总结

小粽

第四周 总结

mm马

极客大学架构师训练营

第4周

paul

第四周学习心得

熊桂平

极客大学架构师训练营

java安全编码指南之:Thread API调用规则

程序那些事

Java并发 多线程 java安全编码 java安全编码指南 java编码规范

Linux下diff的操作详解

良知犹存

Linux

mongodb内核源码实现、性能调优、最佳运维实践系列-百万级高并发mongodb集群性能数十倍提升优化实践(上篇)

杨亚洲(专注mongodb及高性能中间件)

MySQL 数据库 nosql mongodb 分布式数据库mongodb

第四周 系统架构 学习总结

应鹏

学习 极客大学架构师训练营

系统架构

Zzzz

极客大学架构师训练营

jvm笔记

pCat

Java JVM

架构师训练营第四周总结

Erwa

成为 Apache 贡献者,So easy!

海豚调度

Apache 贡献

Go发起HTTP2.0请求流程分析(中篇)——数据帧&流控制

新世界杂货铺

golang 后端 HTTP2.0

LeetCode题解:98. 验证二叉搜索树,递归,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

架构师 01 期,第四周课后作业

子文

第四周作业

熊桂平

极客大学架构师训练营

【架构师训练营 1 期】第四周作业及学习总结

诺乐

架构师训练营第 1 期 - 第 4 周 - 作业

wgl

week-4-part1 大型互联网应用系统使用的技术

陈龙

系统架构

wing

架构师一期

第四周 作业1

mm马

极客大学架构师训练营

ARTS打卡 第20周

引花眠

微服务 ARTS 打卡计划 springboot

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

云存储服务的可用性——从又拍网看云存储服务-InfoQ