图片服务整体架构
1.背景 面向海外用户设计图片类app的后端架构。 2. 目标 考虑跨地区访问图片列表。 图片容灾和备份服务。 用户访问突增的解决方案。 海外服务政策相关注意事项。 3. 方案(图片) ps:这里先统一考虑图片的设计过程,图片解决后,再考虑业务后台过程 3.1 自研 方案设计 分布式文件系统:采用开源系统进行搭建分布式文件系统 文件系统服务:可以新增图片时可以生成索引返回给业务,当业务只需要根据索引,就能查询到对应的文件内容 业务层:上传服务主要负责图片的上传、而列表服务则是需要根据请求,获取列表及数据 接入层:接收用户的请求,把请求代理到业务上 这么设计,可以实现一个图片类的应用。在实际中会有什么问题? 不同区域的用户,体验不一样,用户离部署的节点越近,用户体验更好 因为根据之前的经验,地域对于网络的延迟影响很大。大致从ping上就能体现 地区1 地区2 ping时间 上海 广州 30ms 上海 上海 10ms 上海 美国 100ms 从终端的成功率上看,由于网络上的丢包、延迟,成功率会低很多,特别是图片(目前图片1~3M都是比较正常的),这么大的图片,在过程中,发生丢包、延迟,失败率可想而知,会特别的高。 这种场景,我们可以考虑下,访问国外某些网站的时候,经常是失败,体验非常差 改进点 那么需要怎么改进呢? 比较容易想到的就是,既然是距离远,那么直接在对应的地方部署一个服务,不就行了么? 这样各地的用户,通过dns的调度,访问对应的接入层,接入层只访问当前区域的服务(同一个区域),这样就减少了网络上的问题。解决了用户体验。但是,好像跟需求不是太耦合。。。需求是跨区域访问。 那么要怎么样实现跨区域访问呢? 从图上可以看出来,如果底层数据实现了数据同步,那么是不是就可以了? 比如亚洲用户发布内容,那么我们把数据同步给其他集群,这样其他集群就可以访问到亚洲用户的信息了 要怎么实现同步呢?目前了解到**FastDFS**可以实现分布式任务系统的,他是采用binlog进行同步,在log中有个标志位用户记录该条记录是C: 增加 D: 删除 A: 添加 M: 修改 U: 更新整个文件 T: 截断文件 等,当亚洲区域进行添加时,会发送日志给美洲、欧洲,他们也会根据binlog的日志添加,这里需要注意:同步数据采用的标识与写入的是不一样的,采用小写,目的是为了区别是否需要同步给其他集群。 这里还没有对FastDFS跨区同步进行测试过,还不确定具体的延迟能够到达多少(有待验证)。 理论上,上面的方案是可以实现的,那么我们会有什么问题呢? 所有图片数据,都存在多份,每个数据都需要进行公网的同步。 文件传入与数据传输需要保证一致,不能有数据了,没有文件 那么我们有没有其他方案进行呢?下面我们来看下 对于图片,可以采用CDN加速。 对于API接口了解到市面上,有一种产品,叫做“全站加速”或者“动态加速”,也就是cdn不进行缓存,直接访问,这样的话,我们可以直接让用户访问,这样的话,所有数据都访问了中心区域的数据,通过“动态加速”把用户和源进行连接,核心是增加了数据传输的稳定性,降低失败率。 这种方式存在什么问题: 数据量问题: a) 扩容问题:这个也不算特别问题,是项目一般都会遇到 b) 冷热数据:如果统一的采用一套文件系统,那么会导致数据积累越来越多,文件系统会不停的扩大 当然还有其他的一些需要考虑的点,比如高请求量下“文件内容缓存”、容灾备份等还没有详细讲 3.2 外部功能 既然自研中,考虑了外部功能,那么市面上是否有外部的功能,可以实现全球图片访问问题呢?...