信也科技图片存储高可用方案揭秘

原创信也科技布道师拍码场

作者 | Alfred Gao
编辑 | Ken Zheng

一、背景

信也科技经过12多年的发展，已积累1亿多的用户，每天都会产生百G级的用户图片资料。2019年之前由于业务的迅速发展，用户的图片资料为确保安全，采用加密、切片技术存储在多个公有云上。公有云的稳定性大部分时候都宣称能保证99.95%的服务可用性和99.9999999%的数据可靠性，直到某云服务商发生了“数据丢失事件”，才意识到数据的可靠性完全不能依赖公有云。同时，信也科技是一家科技金融公司，对用户图片资料的安全性有着金融级的要求，综合多方面因素，我们需要建立一套私有的对象存储了！

二、分布式文件存储选型

2.1 自研 or 开源

既然选择建立一套自有对象存储，就会面临着自研 or 开源的选择。如果自研一套分布式文件存储，我们需要相应的人才储备，至少需要存储架构师、存储产品经理、存储运维工程师、存储开发工程师。基于公司的现状，筹备这一套研发队伍，无论是资金成本还是时间成本都无法满足需求。鉴于此，只有选择开源产品一条路可以走。

2.2 图片资料使用场景

在对开源框架选型之前，需要先了解信也科技的用户图片资料在业务中的使用场景。信也科技的图片资料主要使用场景是对用户进行实名认证、OCR、人脸识别、活体检测等用途。在助贷业务中，也会将用户资料授权给机构进行二次认证，同时也会给内部运营、客服进行人工审核、信息确认等用途。

2.3 开源框架选型

确立了开源的路线之后，下面要做的就是对开源产品的选型。在社区搜索会发现，目前有五个主流分布式存储技术，分为Cehp、GFS、HFDS、Swift、Lustre，其中GFS/HDFS/Lustre属于文件存储，Swift属于对象存储，而Ceph可支持块存储、对象存储和文件存储。详细对比如下表：

分布式存储	Ceph	GFS	HDFS	Swift	Lustre
平台属性	开源	闭源	开源	开源	开源
系统架构	去中心化架构	中心化架构	中心化架构	去中心化架构	中心化架构
数据存储方式	块、文件、对象	文件	文件	对象	文件
元数据节点数量	多个	1个	1个（主备）	多个	1个
数据冗余	多副本/纠删码	多副本/纠删码	多副本/纠删码	多副本/纠删码	无
数据一致性	强一致性	最终一致性	过程一致性	最终一致性	无
分块大小	4MB	64MB	128MB	视对象大小	1MB
适用场景	频繁读写场景	大文件连续读写	大数据场景	云的对象存储	HPC超算

由于信也科技的业务场景大多数都是小图片的文件存储，可以将选择范围直接缩小至适合小对象存储的Ceph和Swift。另外，信也科技同时也是一家科技金融公司，对数据具有安全性、强一致性等需求，且对图片资料需要频繁读写的场景，最终确定选择了Ceph。

三、云存储上的图片处理解决方案

引入Ceph之后，将图片处理分为了对象流服务，资料服务、对象存储网关服务和离线图片处理服务。为了保证数据的稳定性和高可用性，将公有云与私有云融合做成双活机制，确保用户图片资料的信息安全，所有用户的图片经过RSA加密之后进行存储，然后将公钥下发到图片使用方进行解密。

对象流读取服务：传输对象流的服务，包括JPG、PNG、GIF、PDF、ZIP等格式，支持CDN缓存加速
对象流上传服务：上传图片、文件等对象文件，防止上传大对象，需要进行上行带宽隔离。
资料服务：资料服务主要维护用户图片资料的生命周期，包括存储、查询以及销毁。
对象存储网关服务：包括上传对象进行公有云与私有云的双备份存储，对象流读取的双活逻辑，以及整个对象的生命周期管理和内容审核
离线图片处理服务：处理图片格式的转换、明暗水印的处理、以及图片的离线裁剪与缩放等多媒体功能。

3.1 公有云与私有云的融合双活

由于在引入Ceph的过程中，考虑到整个技术团队对Ceph的掌握能力处于初级阶段，以及服务的整体稳定性，采用了公有云与私有云的双活模式，通过双写公有云与私有云，并将链接的hash映射存储至DB中，当公有云或私有云某一方出现故障的时候，能够自动进行切换。

3.2 图片加密处理

3.2.1 图片水印

为了保证用户图片资料的安全性，后台运营、客服人员查看图片时，给图片添加工号、登录用户名等明暗水印，防止运营、客服人员将图片外泄。

明水印

明水印是通过JDK自带的Graphics2D实现的，其原理就是将图片流转换成java.awt.Image对象，然后通过java.awt.Graphics#drawImage(java.awt.Image, int, int, int, int, java.awt.image.ImageObserver)方法添加水印。