七牛数据处理架构变迁

据统计，互联网数据量正以每三年翻一番的速度膨胀，其中，95%以上都是非结构化数据，且这个比例仍在不断提升。如今，互联网已全面覆盖大家生 活的方方面面，每个人的消费行为、娱乐行为和社交行为都将产生海量的图片、音视频、网络日志等非结构化数据。非结构化数据的持续在线及数据种类的多样对数 据的处理提出了很高的要求。作为国内最专业的数据管理平台，七牛已覆盖国内50%以上的互联网用户。那么，七牛数据处理架构都经过了哪些演变呢？小编带你 一探究竟。

七牛云存储的数据处理主要分为实时处理和异步处理，对于较小的文件（如图片），一般推荐使用实时处理的方式。

对于实时处理，用户可简单通过URL对已有的文件进行实时处理。当用户将文件上传到七牛KODO对象存储平台，会得到相应的key，可通过URL访问。例如 http://xxx.com/key ，当需要对该文件进行实时处理时，可以通过 http://xxx.com/key?<fop>/<param1_value>/<param2_name>/<param2_value>/…. 进行处理。具体操作参数可以参考七牛官方文档。参数过多过长时可以设置样式，若涉及操作复杂多变可以采用管道技术。

异步请求可以通过Portal、命令行工具、SDK发起请求。一般适合处理较大文件，比如较大的音视频，这种情况下实时响应的效果并不理想，则 可以采用异步持久化处理方式，返回的结果是处理后的文件在七牛云存储中的相关元信息（bucket、key等），用户可以通过设置回调服务器地址，将结果 POST到自己的接收服务器，也可以主动查询数据处理状态和结果信息。

上图描述了简单的实时处理的基本架构，用户可以通过七牛云存储的I/O入口发起请求，判断出是合法的数据处理请求后，就会将其传给数据处理调度 服务，通过调度分发给计算处理集群。每个worker处理的流程为参数检查->下载数据->结合原数据信息对参数进行检查（若数据的相关信息 不需要download下来就可以获取，那么可以和前面的步骤对调）->自己编写算法实现或者调用工具对数据进行处理，比如转码、图像缩略等操作 ->结果返回（异步请求一般会持久化保存，通过对象存储服务，将结果上传，得到文件上传后的相关信息，例如bucket、key等，返回的是文件的 相关信息）。这里可以简单的把数据处理调度看做负载均衡器，请求根据接口判断，通过调度指向对应服务，然后将结果原路返回给用户。

上面的结构简单清晰，但同时面临几个问题：

• 数据处理调度这个服务相对比较重，它不仅仅需要实现负载均衡，还需要对所有处理终端服务进行管理，单台计算型服务器上可能有多个服务worker（多个图片处理、音视频处理服务worker），随着业务发展，管理的worker数量是非常多的。
• 内部实现缓存机制，使得读写缓存的流量全部集中在数据处理调度这个服务。
• 数据的处理离不开原数据，一般我们可以在worker中待前面的步骤顺利通过后，调用七牛的对象存储服务开始下载，那么每个 worker都必须配置对象存储服务的地址信息，然后才能download原数据，这套地址信息对所有worker都是共用的。前面提到1台物理机器上可 能有多个服务worker，每个worker自身有不同的属性参数（最起码端口号不同），而且可能机器上的服务worker有Image Worker也有Video Worker，共用一套配置显然不能满足，若每个worker都将这些普遍共用的信息写入配置，那么维护起来非常不方便。因此，七牛的数据处理架构有了一 些演变，就有了如下的架构。

首先，将Data Cache独立出来，理由非常简单，在很多环节都需要缓存服务，并且根据缓存数据大小、热度选择是SSD或者HDD进行缓存，小文件且热度高适合SSD，大文件且热度较低适合HDD。

其次，为每台服务器添加了agent服务。一台服务器可能有多个worker且可能是不同种的worker，数据处理调度服务只需要知道该请求 的对应worker存在于哪些机器即可，剩下的判断则交由agent处理。因为整个计算集群的服务器存在性能差异，采用权重轮询调度，这时某个 worker对应所在的机器一目了然，也不需要对worker整体标记序号，只需要知道某台服务器有哪些worker。agent可以承担 download原数据的责任，相当于提取各个worker的一些公共操作都可以都交给Agent，同时，agent分担了向Data Cache写入数据的任务。

值得一提的是，对于返回失败的数据也可以缓存。假如请求量巨大，每天100亿条请求，确认是客户端请求信息不当的错误约占5%，那么就有5亿错 误请求，即使服务迭代升级，也会保持原有接口功能不变。那么，若是同一个文件的同一个错误请求，基本上必然重现，这样的请求实际上就可以被缓存，一来用户 那边获得快速响应，二来减少计算压力而且减少拖取数据的流量。后来发现这个方案存在一个瑕疵，就是给Data Cache造成的压力略微变大，且有部分错误请求响应并没有加快，至少为了获得缓存数据而读盘会有时间消耗。先前worker的设计是检查参数是否合法 ->download数据->结合原数据信息检查参数是否合法。这里我们对错误请求做了细化，单独屏蔽了download数据之前所产生的错 误请求，因为这部分响应非常快，本身也没有多少计算，无需写入缓存。

最后，通过Discover服务来监控服务情况的变化，所有的agent和worker都需要向Discover上报心跳状态，Load Balancer会从Discover读取各个服务状态、服务相关信息（地址、权重等），同时允许人工通过Discover修改各个服务的状态。

异步请求的架构，则是在整个实时处理架构前面加上异步队列服务、异步请求状态服务等，每个worker的处理结果需要持久化，返回的是结果文件持久化保存后的相关信息。

现在的整个数据处理架构，看上去中规中矩，同时也存在一些弊端，即使做到了可以对单条请求大致消耗资源的预估，经过多次数据回滚压力测试以及峰 值比对确定一台服务器应该部署多少个worker，实现较为合理的调度，但机器上的worker数量基本上是固定的，无法跨机器实现弹性的实时调度，服务 器的资源仍然不能充分利用。例如，当实时处理服务的机器在非峰值阶段，可以将异步请求的服务worker迁移到该机器上，分担一部分任务，使得每台机器的 负载较为均衡；当实时请求到达峰值的时候，可以迁移部分worker到处理公有队列异步请求的机器（付费的私有队列用户不受影响），分担部分压力。

因此，七牛后续将会对整个数据处理的架构做一些关于Container的尝试，希望打破原有的一些束缚，带来比较好的效果，可以把agent和 worker放在一个Container内部，成为1:1的关系。Container自身具有隔离性，可以依据系统的资源情况选择这台机器有多少 Container运行。当某一台服务器资源已经接近饱和时，就会在下一台服务器上启动一个新的Container继续接收请求。一旦某台服务器空闲下 来，那么这台服务器就属于Container待运行的机器，整个计算服务器集群就是个资源池，worker无需被机器束缚，哪里空闲就启动在哪里，再也不 用担心机器资源浪费了。