1. 如果用户检测一个尚未被收录的样本文件(pc文件，安卓apk软件包等)，那么用户会将样本上传至样本存储系统， 然后检测大流程会使用多类的扫描器，对样本文件进行查杀，返回查杀结果，并记录

2. 如果用户检测一个已经收录的样本文件，那么直接从云查杀中返回这个样本文件的黑白情况。

以上流程大致可以表示为下图：

在这里，我们以安卓手机软件(.apk)为例。新收集的apk软件 会直接落地在存储系统中。存储系统主要为了满足3个使用需求：

1. APK样本实时上传收集

2. 对APK样本实时检测服务提供样本文件下载服务

3. 一旦样本检测的扫描器/模型/规则发生变化， 则对已收集的样本进行回溯扫描

基于这样的功能性需求，我们设计并开发了样本存储系统Xstore。

在设计具体的系统架构之前，我们有必要对这个样本文件存储系统所要存储的目标对象做一个特征的分析，以便更好地设计出贴合实际需求的架构。

依旧以占比较大、较典型的apk样本作为例子。我们待存储的apk样本有如下特征：

• 大小：单个文件平均大小50M，波动在10k至3G之间，总容量为10-100PB这个量级

• 数量：总量在10-100亿级别，每日增量为百万级别

• 以写入和读取为主，几乎不更新，无物理删除

• 读取方式为随机+顺序读取

• 高价值，要求提供容灾和备份方法

在考虑了存储目标的特性和功能需求之后，我们得出了这个系统所需要满足的非功能性需求。

• 实时存取：需要提供易用性高的实时性存取接口

• Hadoop友好：为了方便使用MR/YARN/SPARK进行批量扫描，系统需要Hadoop易用

• 可水平扩展的存储空间和计算资源

• 强备份需求、容灾需求

• 优秀的顺序读取性能，以满足频繁的批量扫描需求

• 高安全性

基于以上提到的功能性和非功能性需求，我们就可以开始设计一个满足这些需求的存储系统架构了。

于是我们考虑使用HDFS+HBase的方式，来存储底层的数据。使用HDFS存储样本文件本身。使用HBase来存储样本文件的元信息。

在HDFS中，由于受文件数的限制，我们将样本进行了合并，暨在一个大文件中，存储若干个小文件。这些小文件的偏移量由HBase记录。整体的存储内容结构看起来如下图：

我们在一个大小约为2G（可配置）的.mrg文件中，存储了若干个样本块。每个样本块包含样本头文件信息，和样本文件本身的二进制内容。每个样本块如同乐高积木一样叠拼成一个整体。

在长度为256字节的头文件中，记录了样本文件的实际偏移量、文件实际长度、校验位、文件名等信息。这使得我们可以通过样本的头文件直接进行样本文件的遍历。

在HBase中

记录文件长度、文件偏移量等头文件中拥有的信息用于随机读取。同时也记录了诸如上传状态、合并状态等标记位信息，方便业务上进行状态判断或者业务扩展。

在这里，引入一个抽象的例子方便理解这样设计的目的和初衷。

咱们抛开之前所有的技术话题不谈，想一个抽象的例子来方便更好地理解这个架构形式：

假设我们需要设计一个住宿小区，小区有两个主要的需求，一个是挨家挨户收取物业费，另一个是对顽固不交的业主，按照其业主姓名，上门收取物业费。

显而易见，为了容纳更多的人，同时占地面积足够小，小区内肯定不能是平房。而是采用楼房的形式，将一户一户人家叠在一起。但是楼房有个问题是，没有办法精准的定位一户人家。所以如常识所见，我们给每个在楼房里的住户，都标记了门牌号，诸如3单元904等。

与此同时，为了方便管理每个户主和其门牌号的对应关系，我们用一张表格进行记录。Key为户主姓名，value为对应的门牌号（哪个楼几单元几零几）。

在收取相应的物业费时，我们既可以直接挨家挨户的按着门牌号逐户收取，也可以通过查询户主信息表，对某个户主专门收取。

这个抽象例子其实跟我们Xstore的组件组织方式，是如出一辙的。

Xstore存储系统架构图

根据以上的技术栈使用方法以及对应的业务需求，我们最终的得出了如下的Xstore存储系统架构图。下面我们自底向上的进行每层系统的解释。

这一层主要负责原始组件的接入。我们主要使用的组件包括之前提到的HBase和HDFS，以及尚未提到的用于提供分布式文件锁功能的ZooKeeper。数据层负责将原始的组件进行简单的封装，并向上层暴露组件自己本身的接口，诸如文件的get/put ，hbase key的get等。

对于底层暴露原始接口的数据层，存储逻辑层主要负责对其原始接口进行二次封装，以便进行业务上的整合。这里主要提供了以下三个接口服务：

1. 文件头协议：设计实现了文件头，存储文件相关信息。

2. 文件合并：将文件头+文件内容作为一个块，合并到固定文件中

3. 文件索引服：根据文件key等信息，从HBase中查询相关信息。

在逻辑层之上，是数据访问层。这一层负责实际对数据的访问。对外暴露可以作为单独服务进行的接口。接口实际操作底层数据层的数据，以数据逻辑层作为媒介。主要提供的数据访问接口有：

1. 文件寻址服务：通过文件的key和逻辑层的索引服务，对外提供文件key到HDFS实际路径的映射关系查询

2. 冗余备份处理：使用基于HDFS的冗余备份，实现存储文件的备份处理

3. 分布式文件锁：使用ZooKeeper，提供HDFS文件操作时候的分布式文件锁

4. 文件的增删改查处理

在对外提供服务时，我们引入了文件分片传输，以方便网络IO的均衡，也减小了传输包的差异性。同时使用RPC对外提供类似的文件服务以补充HTTP协议的不足。负载均衡搭建在下载前端机之上，保证整个服务的稳定性

在线部分我们提供了http/rpc相关的接口，以及PHP和Python的sdk支持。而离线部分，我们基于Hadoop，提供了回扫管理器、调度器等子系统。

Xstore上线一年以来，存储了约10亿个、21PB的样本文件。每日增量约140万个、30TB的样本文件。类型包括apk、elf、qex、沙箱产出、pc训练样本等等，服务项目约20余个。

• 在线业务部分，日均吞吐约20TB， QPS 2-3k，每日约两千万次文件请求。

• 离线业务部分，Xstore回扫服务了17个组内组外业务，响应扫描器迭代，为扫描器产出保驾护航。全量apk样本回扫可在5小时内完成。

已有的架构能够满足基本的功能需求，但是经常会因为底层存储组件HBase或者HDFS的故障(诸如访问缓慢，resionserver切换需要时间等)，从而引起业务方在上传样本时候出现卡顿或者服务停滞。为了解决这个问题，我们着手进行了Web服务架构上的改进。

先来看一下现有的Web在线服务架构图：

当用户上传样本文件时，首先通过域名解析和负载均衡将具体请求转发到某一前端机上。然后在前端机上，我们部署了Xstore的文件存储服务，将通过HTTP等协议收到的文件包，流式的直接写入HDFS，并操作更改HBase。这样的好处是显而易见的，文件不落盘，不会对本地磁盘IO造成过多的负担。与此同时由于不过多更改用户上传的包，所以文件的一致性得到了保证。

但是这样架构的缺点也是明显的。首先，过长的数据链条使得整个业务流程变得易碎。样本包文件要经过负载均衡 ，前端Web机，HDFS等诸多组件。其中单个组件的故障会直接影响到这个包的落地。于此同时，这个架构方式将原本服务于离线的HDFS和HBase变得在线化了，这对组件实时性要求变高的同时，也违背了我们的设计初衷。

于是我们重新组织了在线部分的系统架构，得到了如下的架构图：

我们可以看到，在文件存储服务和前端机之间，我们搭建了一套文件缓存服务。这个文件缓存服务的用途主要是：

1. 接受Web前端机收到的文件，并且形成文件队列，异步的写入Xstore底层存储

2. 除了支持上传文件的接受以外，也同时提供HTTP的文件下载服务。根据文件的key，查询其实际的存储机器/路径/地址，并提供这个文件的下载url。

在这次tradeoff中，我们牺牲了磁盘存储空间和Xstore归档的实时性，换来的是对底层存储组件的低依赖和访问速度的保证。

优化之后的用户时序图如下：

其他业务相关的优化策略，就不在本文的讨论范围之内了。

以上就是本次分享的内容~

如有问题，欢迎公众号后台留言鸭！