网易云对象存储方案和应用场景介绍

问题导读：
1、对象存储应用场景有哪些？
2、网易对象存储核心是什么？
3、DFS分布式文件系统哪些特性？
4、网易NOS系统架构提供哪些服务？



大家好，我是来自网易蜂巢的汪滔。今天借此分享的机会，和大家交流一下网易的对象存储方案和应用场景，希望能够对大家有所启发。

一、对象存储应用场景

IT时代产生的大部分数据都是没有固定大小限制、没有固定格式的非结构化数据（图片、视频、 文件、归档备份数据）等，面对如此庞大的数据量，时常需要专业的云存储平台帮助解决一站式全方位的需求。

针对存储系统在扩展性、 可用性、可靠性上的担忧，我们通过开发的全方位的SDK，快速提供了一种理想中的非结构化数据一站式解决方案。以下为几种典型的引用场景：

1、资源分发下载

可以使用NOS并结合网易CDN服务实现一站式的数据上传、存储、下载分发服务，其对象包括：

    网站、APP需要存储、上传和分发视频(视频网站、朋友圈)；
    存储、上传和分发图片（电商网站）；
    发布APP安装包等。



2、UGC业务场景

网易对象存储提供边缘节点上传加速功能，其优势为：

•     在不暴露NOS A/S KEY的情况下，让移动端直接将数据上传到NOS
•     利用分布全国的边缘加速节点，更快的将数据上传到NOS中，提高终端用户上传体验
  

3、企业网盘

4、云端数据处理

上传文件到NOS后，可以很轻松地进行图片处理服务和视频处理服务。


5、网站/应用动静分离

简单管理网站上的图片，脚本，视频等静态资源，通过BGP网络或者CDN加速的方式，提供用户就近访问，有效降低WEB服务器负载，提升用户体验。

二、网易对象存储核心竞争力

1、DDB分布式数据库系统

分布式数据库系统（Distributed DataBase，简称DDB）是网易杭研后台技术中心研发的分布式关系数据库平台。

在NOS中用于元数据存储，主要用于解决如下问题：
1）海量结构化数据存储
2）高并发高吞读数据访问

均衡字段：用于计算哈希值的字段

两级映射：结合哈希的高效性和路由表的可管理性

2、DFS分布式文件系统

与之对应的，分布式文件系统（Ditributed FileSystem，简称DFB）是杭研后台技术中心研发的分布式非结构化数据存储平台。

主要用于解决如下问题：
1）海量非结构化数据存储
2）高并发吞吐数据访问



3、富媒体服务

（1）概述

当前NOS承载着几乎所有网易互联网产品blob数据的存储，图片、视频、附件等是最常见的应用场景，而其中很大一部分数据为图片数据，比如网易lofter、网易云音乐、网易考拉海淘、易信朋友圈都有非常多的图片应用场景。几乎所有的这些产品都会大量得使用到NOS提供的图片处理服务。

NOS图片处理服务从2013年上线到现在已经上线差不多快3年半的时间，图片处理服务器从几台扩容到几十台；系统负载tps从几百tps上升到现在的2w＋tps，近上百倍负载增长。功能从简单的裁剪缩略到提供丰富的图文水印、链式处理等功能，已能满足专业的lofter图片处理的需求。

架构不断演变以适应更多的功能、性能、扩容性等各方面的需求。

以下为NOS图片系统发展的timeline。

接下来我会从几个方面介绍NOS图片处理解决方案：

•     图片核心处理单元
•     数据的获取nosfs
•     系统过载控制
•     图片处理架构
  

（2）图片核心处理单元Tobie


分治永远是解决所有复杂问题的解决方案,在计算机科学中体现的尤为明显。如上为一个基本的图片核心处理单元。主要分为以下几个层次接口层、并发层、处理层、数据层。

    接口网络层

接口层向上层调用者提供HTTP RestFul Service，如下为对存储在nos的一张图片资源 Koala.jpg 执行简单的缩略操作。
http://nos.netease.com/doc/Koala.jpg?imageView&thumbnail;=100x0
接口层为基于Libevent实现的 C++ http服务。Master负责网络层的处理，包括接收来自客户端的请求，进行合理解析分发到任务队列，以及接收来自worker的处理结果并返回给客户端。Master基于libevent实现Non-Blocking的网络IO处理，所以基本单线程能够hold住整个图片处理单元的网络负载。

    并发处理层

并发层worker从任务队列中获取请求并进行实际的图片处理工作，并发层Processor为通用的数据处理单元，当前已经整合Grapbic Magic 图片处理单元以及ffmpeg视频处理单元，后续如果有新的处理服务也可以非常方便的整合实现其它的处理功能。同时Processor也实现了Lua 扩张功能，可以非常方便的进行外部命令调用，从而非常快速的整合新的处理功能。

    数据接口层

数据层实现了内存的数据接口以及本地文件系统的POSIX访问接口。数据资源可以是本地资源，也可以是来自网络资源。本地资源提供内存和File接口是非常直接的，网络上的资源是(对于我们来说主要也是通过网络方式来获取NOS上的资源)通过基于nosfs模块实现将NOS HTTP Rest API接口到Posix接口的转换。

（3）nosfs


NOS提供的是标准的HTTP Restful API，而某些图片或者视频处理库的只提供了基于本地文件的处理接口；所以面对这样的场景我们基于fuse（用户态文件系统开发框架）实现了nosfs，将NOS上的资源以文件系统中文件的方式暴露给上层用户。

NOFS的基本框架如上图所示。APP（Tobie） 使用 open、read、write等文件系统POSIX API接口读取文件内容，陷入内核后，Fuse 内核模块会将用户的调用请求转发给上层我们基于libfuse实现的NOSFS模块，NOSFS 将文件系统形式Read、Write 调用转化为NOS HTTP PUT GET 请求实现协议的转换和数据的读取和写入。

（4）处理单元的过载控制

a）过载与排队

    过载问题与解决方案

对于时延敏感的服务（同步调用），当外部请求超过系统处理能力，如果系统没有做相应保护，可能导致历史累计的超时请求达到一定规模，像雪球一样形成恶性循环。由于系统处理的每个请求都因为超时而无效，系统对外呈现的服务能力为0，且这种情况下不能自动恢复。

对于图片处理系统来说，是典型的CPU消耗性业务，往往32核机器对外只能提供几百的TPS的服务能力。如果系统在高负载情况下CPU成为瓶颈而请求还是在不断累积，那么很容易造成恶性循环。

NOS图片服务刚上线的时候就因为此类问题吃过不少亏，下图简要说明了图片服务刚上线之前的构架。逻辑层(tomcat)是统一的，不仅承担了用户数据的读写，还要转发处理图片服务请求。某次系统发生局部故障，Tobie处理集群中的某台机器处理能力降低不能快速进行图片处理，但是tobie的IO线程并没有block，还可以正常得进行请求得接收，从而导致请求积压，这不仅仅导致我们Tobie做了很多无用功（处理队列中已经超时的请求），更重要的是导致上层调用方(诸业务服务器)等待在这个故障图片处理节点上等待图片处理结果，而不能处理其它包括文件读写等核心业务。



所以事后，我们做的第一件事情是核心服务的拆分，将上传下载、图片处理业务逻辑隔离开来。并且后续又针对图片处理核心模块系统层次的做了深层次的梳理，包括操作系统层次，保留libevent网络库层次，应用层次等。


如上图所示，从服务端收到客户端发送的Sync信号连接，连接进入Sync-Received队列，到三次握手完成进入Establish队列之后；再到上传网络库libevent通过epoll多路服用方式将底层的连接Accept放入event队列；直到连接上接收到一个完整的HTTP请求之后，IO线程回调上层应用的回调函数将HTTP请求插入请求队列，最后worker从请求获取请求进行处理。

当然系统层次或者libevent层次我们能够控制的余地较小，在底层做控制也不是非常优雅和通用，所以我们通过在应用层对请求队列做了一些控制，比如限制队列的长度，超过队列长度的时候直接拒绝请求；又比如每个请求插入队列的时候打上时间戳，worker取请求的时候发现已经等待很长时间了直接丢弃请求返回错误等等。另外我们结合nginx的健康检查机制，在服务已经过载情况下自动将请求调度到其它节点。

总结来说，以下几点为我们实践过程中总结出来的构架设计的关键点：

•     分布式系统中一个节点过载可能导致整个服务不可用，（tomcat类同步调用框架尤为容易受影响）
•     核心服务的隔离，拆分
•     前端不能信任后端, 所以第其他模块调用必须设置合理超时、一定的保护后端的责任
•     后端应该尽力而为，服务不了果断拒绝，SLA
  

b）图片处理架构


如上为NOS图片处理的整体框架，Nginx将图片请求转发到NosMeida，NosMedia层次的功能主要为图片协议正确性检查，调用NosAuth对用户的请求进行认证。ATS(apache traffic server)缓存集群用户缓存图片处理结果(当前NOS使用的是代理缓存的模式)，tobie处理集群氛围大集群以及小集群，小集群用户处理较小的图片资源的处理，大集群用户处理超大图片、以及针对视频的操作。

（5）NCAN上传加速


    1.客户端到基站的丢包率非常高

    2.基站到数据中心的RTT也比较高

导致客户端到数据中心的网速较低，上传文件失败率较高。


将上传文件分为过程一分为二：

    1.客户端到基站的带宽低，但是rtt较低
    2.Rtt较高，但是带宽较高

我们将边缘节点部署到离用户最佳的地方。

针对两个阶段分别进行优化，加速上传优化。



NOS在全球各地部署了上传加速节点，帮助用户以最快的速度上传数据。上传加速节点数量和线路在持续增加和优化。


关键技术点：

a）上传协议

传统标准OSS上传协议：

•     分块上传、最小分块5M
•     为服务端设计
  

NOS直传协议：

•     支持任意大小分片
•     分片append协议
  

自定义的上传协议，提高文件上传的成功率。

b）移动端上传优化


在一个TCP链接上并发发送数据，充分利用广域网带宽，提高上传速率，Pipeline测试结果如下：



Pipeline能够大幅度提高上传速率。

c）广域网TCP、HTTP优化




边缘节点及时提供响应，在上传完成之后，边缘节点和中心机房进行一次同步即可，有效率用客户端到边缘节点&边缘节点到中心机房两段带宽。



对边缘节点到中心阶段之间网络进行优化（客户端到边缘节点的网络不在可控范围之内），主要是TCP send buffer的调优，使buffer不成为上传速度的瓶颈，在不使用专线的情况下达到最优效果。




最下面一条线是杭州中心机房的base数据，我们对蓝线代表的边缘节点进行了优化，并对未进行优化的边缘节点进行了对比测试，相应时间差距可达到70ms以上。

Q&A：

Q1：Lua 的作用是什么？
A1：Lua的作用是用来做图片处理在数学上的一些换算工作，在测试等阶段可以做到不用重新编译可以对一些裁剪缩略的规则进行直接的调整。

Q2：golang 是用来做哪一层的？
A2：golang 其实在我们系统里面很多地方用到，比如替换tomcat 这样的thread base web server的，实现更高的并发性，比如上面提的图片处理进来之后的接口层次的服务处理都是用golang 做的。

Q3：视频处理方面的，有没有检测视频质量或者被人为修改的检测算法？
A3：没有，整合视频服务这块，当前PPT里提到的，我们的功能比较简单，主要是一些视频云信息的获取一集截图之后结合图片处理的一整个流程的传来服务，比如打水印的，缩略啊，转格式啊等等，你说的检测视频质量这没有做。其他比如分布式转码等功能，不在今天的分享范围内，后续可以再约。

Q4：存储用ceph？
A4：存储是自行开发的分布式文件系统，对小文件存储做了大量的优化。

来源：DBAplus社群
作者：汪滔

真是是很不错 ，学习了

学习一下，很好的分享