云栖社区2017在线技术峰会，阿里云对象存储服务技术专家杨铭来为大家揭秘存储技术实战优化红包体验。本文主要从红包场景中设计到的存储开始谈起，着重介绍阿里云对象存储OSS的技术架构，以及架构如何支撑红包活动的，最后从存储扩展看看OSS上的计算生态。
以下是精彩内容整理：
红包场景中的存储
2017年支付宝红包有两个有趣的玩法，AR实景红包和“扫一扫”扫福字。AR实景红包可以利用手机拍的照片，将红包藏在某个地点，将红包地点和线索图发给好友，好友可以根据线索图找红包；扫福字可以利用手机扫各种福字，集齐五福，下面我们就来看一看整个活动背后蕴含的技术是怎样的。
藏红包就是用手机拍照片，拍好照片将照片上传到服务器，服务器要将红包图片特征值提取出来，同时要将图片制成线索图，将两个图片存储到OSS上，当好友来找红包时候，他会从OSS上将线索图下载下来，自己拍张图片作为比对图，比对图会先在客户端做比对，客户端比对通过后会服务端作比对，服务端比对过程就是要把比对图上传到OSS，由服务端程序进行严格的匹配，只有匹配到了才能找到红包。”扫一扫”扫福字更倾向于在客户端将事情做完，用户通过扫一扫拍照，客户端识别福字，如果客户端识别不出来，那也会上传到OSS中，由更为强劲的算法进行严格的匹配。从这两个场景可以发现，在整个红包活动中，所有的用户所拍摄的图片都是上传到OSS的，此外，整个红包过程中所涉及到的宣传图片、宣传视频、拜年视频都是存储到OSS上的。
红包场景的核心业务指标是什么呢？
首先，除夕参与人数有2.2亿，大约七八个人就会有一个人在玩红包；红包主页面峰值达到了81w/s，上传峰值可以达到20w/s，这和一般产品都有点不一样，上传量特别大。
怎么选择合适的存储来满足业务需求呢？存储痛点主要有以下六个：
1.突发式访问，在整个活动中，过年前一周是没什么人玩的，除夕夜大家都疯狂扫福，大家经常会聚在一起玩AR实景红包，峰值是可以达到20w/s上传；
2.红包活动需要高可用性保障，如果因为某个设备的故障，就扫福扫不出来，或是AR实景红包就没有办法获得线索图，这样的用户体验是很差的；
3.低延迟保障，当把扫好的图片上传到服务器做比对时，期望的延时大概在1～2秒之间，最终留给OSS上传时间大概有50ms，如果你的平均延迟比较高或不稳定，用户体验就会变差。
4.可以存储海量文件数目；
5.对于活动页面、宣传视频，我们希望有一定的处理能力，比如说，图片的缩放、水印，视频的码率转换等；
6.对于业务来说，简化运维，以较低成本达到目标。
存储方案来说，一种方案我们会选择传统的NAS设备，NAS设备的横向扩展能力或是弱或是没有，需要买高规格机器，除了除夕夜几天外，平时用不到，造成资源的浪费；另外一种选择是很多创业公司会自建云存储，但并不是人人都是存储专家，运维方面会面临挑战；支付宝红包活动选择阿里云对象存储，对象存储解决了所有的痛点。
OSS技术架构
OSS有许多特性，首先OSS支持海量文件数目，用户可以放心存储很多文件，每个文件大小也不限制，最小文件可以是空的，最大可以达到48.8TB；OSS具备高可用性，不能因为某一部分故障导致服务不可用；OSS也具备高可靠性，数据存在OSS上面要保证长期不会丢失，在同一个AZ内将一份数据存成三个副本，同时OSS还提供跨区域复制功能，通过这个功能将一个城市的数据自动化备份或同步到另外一个城市，当某一个城市不幸发生灾难时，可以在另外城市找到数据；OSS还提供了很多公共服务，比如权限管理可以给你很多子账户，每一个子账户可以访问一部分资源，也可以将你的资源临时授权给某人看，同时也进行多租户隔离；除此之外，OSS还围绕着庞大而且完备的计算生态，可以对文件进行图片处理、视频转档和大数据分析等。
OSS存储技术架构主要分为三层。第一层为协议接入层，主要接入来自用户的HTTP或HTTPS请求，接着我们会做一些权限的验证等，然后将数据转发给分区层，分区层主要对数据进行分片，同时做进一步均衡，主要基于LSM Tree结构，KVMasters主要存储分片信息，每个分片隶属于某个KVserver，由它来进行分片上面的读写操作，最下面层是持久层，主要是将数据保存到物理磁盘上面，由分布式文件系统盘古实现，它是基于Paxos的多Master结构，用户数据存储在称为chunk server的数据节点上，每份数据都会存三个副本，三个副本会分布在不同磁盘、机器、机架以及网络设备上，主要用来保证高可靠性的。
我们通过写入请求的例子来具体理解技术架构是怎样的。首先，用户写入请求进来，进入阿里云机房，阿里云会有一系列安全产品，比如云盾、或其他产品对这个请求进行识别，确定它不是攻击流量才会放行，然后进入负载均衡，负载均衡会将请求按照一定的策略分配到某一个HTTPServer上，HTTPServer就会做大量工作，首先要对HTTP协议进行解析，接着对用户身份进行识别和权限识别，我们还会做其它识别比如是否超出使用额度，准备向分区层发送数据，发送数据前会向KVMaster询问数据由哪个KVServer服务，KVServer同时写三分redo log到chunk server中去，KVServer还要更新内存中的MemTable，更新完毕后可以回应HTTP Server，继而回应客户。
可以看出，整个架构实现了高可用，没有一个环节有单点故障发生，任何一台挂机都不会存在可用性上的损失，每一个机房以及物理上的保障，包括网络上的保障，每一个机房的电力包括接入光纤、空调各方面都是有冗余的，整个系统可以实现横向扩展。
支付宝红包活动由很多图片需要处理删除，比如将图片分享给家人、朋友，会根据手机尺寸、个人爱好等各方面进行一定的缩略，缩略都是在OSS端在线完成的。
我们通过请求的方式让大家了解OSS图片实时处理架构，用户在访问OSS时在图片后面加一些参数， 一般来说会通过电脑和手机先访问CDN，CDN发现缓存 miss以后，就会回源到OSS协议接入层，OSS会先去访问图片缓存，如果命中，就可以立即反馈给客户，如果不命中，就从对象存储引擎中将原图读上来，经过图片处理引擎优化处理完后，再返回给处理图片的缓存，最终反馈给客户。
为了解决红包活动中突发式访问问题，需要准备足够多的资源满足业务需求，而且不能让别人影响我，红包业务也不能影响其他业务。
多租户架构主要分成两部分，一是前端HTTP Server，属于协议接入层一部分，它会实时采集用户信息，一是Quota Server，Quota Server对信息进行汇总，HTTP Server会定时将它收集到的信息汇报给Quota Server，Quota Server会把流控的信息返回给HTTP Server，除此之外，我们还会对手机的信息进行实时计算，包括它的访问分布有多少400、403和200等，这些信息汇总后，我们还会将信息输入到运维大盘系统中去，该系统主要承载展现收集到数据，比如一个用户在一段时间内的访问状况，另外也可以设置阈值进行监控和报警，运维大盘对于保障支付宝红包这样的大型活动是十分重要的。
OSS的计算生态
OSS除了提供图片处理功能外，还提供了很多能力来帮助用户挖掘数据价值，包括音频视频转码，转码后还会放在OSS上，可以很方便的将转码后的东西分享给别人；除此之外还对图片视频鉴黄，保障业务健康发展；也可以对OSS上文档进行索引，并且进行搜索，可以作删除日志分析和抽取等。
用户自定义计算(UDF)
对于像支付宝等追求极致的应用，会有一些特殊的需求。比如需要对宠物进行裁剪，或者对数据进行定制化的压缩、加压，或者对数据进行打包，也有一些用户不满足阿里云的服务，想要接入第三方服务。
在这个过程中有两大痛点，一是数据和计算分离了，需要从OSS跑到自己机房或者跑到另外一个地方去，这是对带宽的浪费；一是延迟会比较大，需要额外的代理逻辑，运维成本很大。
为了解决这些痛点，更好的接入第三方服务，OSS推出了自定义计算的优势，用户可以将自己的应用程序托管给OSS，在用户请求数据的过程中，OSS就将数据处理好了，就会达到无缝的体验， 真正做到功能定制、数据就近处理、简化调用和无需运维。
UDF建立在飞天分布式系统中，主要由轻计算协议插槽、轻计算运行容器和轻计算控制系统组成，当收到用户请求时，我会识别发现需要自定义计算的，将请求转发给用户程序，程序运行在轻计算运行容器中，控制系统主要是用户用来运维程序。
首先用户需要定义一个名字，然后将程序打包好，上传到OSS，OSS会将你的程序在轻计算运行框架中运行，同OSS其它原生处理是一样的，将请求发送给OSS协议接入层，如果OSS发现需要自定义计算，就会将请求转给UDF调度管理，调度管理选择运行实例进行处理，然后返回给客户，也可发送异步消息给MNS。图中橘黄色部分是运维保障。用户不需要买自己的服务器，用户对运维也不需要那么麻烦，数据流动都是对OSS内部，URL和标准图片处理基本一致，编程方面不需要有额外的支出。
OSS计算生态如图，数据上传后，既可以用我们的已经有的阿里云的产品，也可以方便接入第三方服务，此外可以根据自己业务需求进行自定义处理，处理结果有一套同步或者异步通知方式及时告诉处理成功或失败。
总结
1. 红包场景的存储需求：海量文件数，高可用性，突发式访问，低延迟。
2. OSS分布式水平扩展的服务能力完美的支持了红包等业务场景。
3. OSS以完备的计算生态，一站式的满足了数据的存储和计算需求：
– 原生支持图片处理
– 作为多种阿里云计算服务的输入、输出介质
– 通过UDF，用户能够便利的加入定制化计算
