做互联网应用少不了图片的支撑,图片的上传,浏览速度很大程度上决定着用户的体验,甚至用户去留,就因为其重要,所以,在任何时候,图片的架构和优化都在进行,不敢丝毫放松。
在以后几个章节,会从后端图片存储,前端浏览,动态浏览这些方面和大家分享一下我们一路过来的经验。
经过数据的观察,应用,WAP的用户量基本与PC端持平甚至超越,因此,应移动端用户体验和访问速度都被运营方盯得紧紧。在2014年的时候已经看到这个趋势后,主动监测发现移动端的跨运营商访问速度和稳定性真不敢恭维。所以,在那个时候开始,我们已经在寻找中国移动的机房资源进行部署加速节点,为移动端用户进行加速,接着引入边界网关协议机房;至此,总算解决了很大程度上用户浏览图片速度的问题,但在用户图片上传方便还是在不停探索中,以下是一些走过的路子。
应用端代码对图片进行压缩,水印,裁剪,缩图。缺点:耗费用户CPU和流量。这个方法只是解燃眉之急。
应用端对超一定大小的图片进行压缩,然后直接上传,服务端接收完图片并做完转图操作后返回用户上传成功状态。这方法一直沿用至今。
不同的运营商用户上传图片到所属运营商网络节点,然后通过内部同步系统进行图片资源同步,从而达到各机房数据的一致性。基于多点上传会存在资源短暂不一致情况,(如:机房用户上传完并可以浏览的时候,资源还没同步到其它机房,那其他机房的用户就会存储404),我们引入查询系统。具体架构
1。上传:客户端调用上传接口进行图片上传。
2。写入:传一条记录到查询系统中,该信息会在各机房的查询系统共享,同步系统发现新文件后也会自动执行同步任务。
404:浏览用户通过浏览系统进行浏览图片,当发现本地图片404后,会拿查询系统信息,能得到对应信息则能正常返回用户图片。
随着图片和手机性能的提升,图片大小大幅提升,但手机网络的不稳定性还是很普遍的情况,针对这情况,在原有的基础上我们加入分片,把一张图片分成若干的小片,然后再上传,最后在服务端合并。
经过几轮的折腾,看数据情况可以。
我们想着能顶个一段时间,大概过了一年半,运营报障有网友反馈慢。
在应用中进行埋点收集用户数据,结合数据初步判断,发现主要两个问题:1。服务端转图慢,因为经过一定时间的业务发现,需要转的图片种类越来越多。2。移动网络地域之间,网友移动网络到我们移动网络机房之间都存在慢的情况(归纳到同运营商间的地域问题)。
解决问题一:实时转图系统的引入(后面介绍)。
解决问题二:1。自建,投入更多的资金建立上传边缘节点。2。利用现有的图片云服务,公有云能提供更多地区地就近接入,上传边缘节点。经过评估我们尝试走图片云服务。
测试对象:
七牛;2。阿里云;3。腾讯云(云对象存储服务)
<李>
调研后,其实三大厂家提供的api接口和功能组成差不多,今次选择主要是根据技术支持服务决定,选用七牛为主,阿里云为辅助(如果七牛整个挂了,上传服务自动转移阿里云)。
引入云图片服务后架构变为:
1。应用程序向“UPC云”(是我们内部的一个上传认证系统)申请上传的身份验证,带着身份信息向云端上传图片。
2。通知后端需要进行资源的同步和实时转图的格式。
3。向资源同步系统中传递信息导(异步)。
(因为我们有自己cdn,另外和cdn厂商合作非常顺利,从成本考虑,我们还是保留出图走自己的cdn或cdn厂商)
4。用户查询请求先到cdn。
5。cdn 404回源请求。
6。img前端(图片浏览服务)如果不存在该图片,则把请求派送到云资源同步系统中。
