图片服务整体架构

Thu, 09 Jun 2022 15:09:21 +0800

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) 扩容问题：这个也不算特别问题，是项目一般都会遇到