重IO类型应用的最佳实践

本文要解决的主要问题是,如何针对重IO类型的应用,通过组合使用云产品,设计灵活的应用架构,使应用能够顺畅地运行在云端。下面将以一个视频分享应用的架构为例来说详细阐述。

1. 最佳实践
1)  将IO压力分摊到适合的云产品上
下表是对阿里云具备存储能力的产品适用和不适用场景的建议。

产品 建议的数据存储场景 不建议的数据存储场景
云服务器 1.      应用代码,应用日志
2.      临时文件存储,缓存数据
3.      搭建mysql/sqlserver等数据库(可使用RDS来替代)
4.      MongoDBnosql的数据库(可使用OTS来替代)
5.      文件存储,如图片、视频、附件
OSS 1.      各种大小的文件(不需要局部修改的文件),如图片、视频、各种附件 1.      需要局部修改的文件,更新一个文件的片段,如搜索引擎的索引
RDS 1.      结构化的数据,需要支持SQL关系操作(如需要较复杂的索引和Join操作) 1.      非结构化数据,如图片、二进制文件
2.      海量结构化数据,但不需要SQL支持,查询模式简单,没有join操作
OTS 1.      海量结构化数据的存储,无需Join、复杂SQL操作,特别适合宽表(稀疏表)类的应用 1.      需要复杂SQL操作支持、需要支持Join查询
2.      图片、视频等二进制文件

 

对于重IO类的应用来说,建议:
a) 不要在云服务器上部署数据库(以避免单点故障和IO爆发的情况),而使用RDS来替代;
b) 不要将需要持久化的文件存放在云服务器上(为应对容量限制、带宽限制、IO压力等),而是将数据存放到开放存储服务OSS上;
c) 尽量使用OTS来替代自己搭建mongodb。

2) 分层构建可扩展应用,同时降低不同应用对IO的争抢
将Web层、应用层、缓存层分开部署,保持每层无状态,当业务压力激增时,只需要通过扩容机器就能应对。

2. 最佳实践案例与解析
下图是一个视频分享应用的技术架构。用户可使用该应用在手机上拍摄视频并分享给自己的朋友圈。在系统架构上,主要分为三个部分:
1) 用户维护自己好友关系、管理自己已经上传视频的Web服务;
2) 视频的上传入口和编码(适配不同的网速和手机播放能力);
3) 视频的播放出口。

对与IO有关的各模块分析

对与IO有关的各模块分析如下:
1)标记红色1的模块:将Web服务、上传服务、视频编码服务、缓存和消息队列分为了4个角色,分开部署。
a)Web服务:本身只部署代码,同时存放应用程序的日志输出;
b)上传服务:上传服务建议不要将接受到的文件放到本地临时目录,而是由nginx/apache等http服务在内存中开设一个缓冲池接收用户上传的视频,当缓冲池满后,再直接写入到OSS,即流式写入数据到OSS。如果无法使用内存缓冲池接收用户数据,建议将nginx/apache接收上传文件的临时文件存储地址放到/dev/shm中(风险是当机器异常宕机后,还未持久化到OSS的文件将丢失)
c)ECS Redis扮演了数据库(RDS)缓存和消息队列的作用,这层可以选择其他的开源的软件来搭建
d)ECS编码服务集群,这组服务器主要是将用户上传的原始视频编码为不同的码流以适应不同的用户网速和手机播放能力。编码服务器订阅Redis中的新上传文件的信息,当有新文件上传后,从OSS中取出原始文件的数据到ECS的内存或Ramdisk中,进行编码,完成后写回到OSS。
这4层都应当做到支持水平扩展,对ECS Redis做水平扩展较为困难。

2)标记红色2的部分:将视频文件的存储放到OSS,将关系型数据存储到RDS。OSS提供了一个大小无限制的文件存储空间,并且对外的带宽远比单台云服务器的带宽高,特别适合存储图片、视频、附件等在线文件,每一个存入的文件都有一个独立的URL,可以设置容许外部用户直接访问。RDS提供的关系型数据库服务,本身已经是主从互备机制,遇到单点故障会自动在30秒内完成切换,且可以根据用户指定的策略将数据库备份到OSS,除了服务高可用、数据高可靠的特点外,比自己在云服务器上搭建数据库具备更好的性能。

重IO类型应用的最佳实践:等您发表观点呢!

发表评论


快捷键:Ctrl+Enter