1、集团使用阿里云对象存储 OSS 概述
双十一在逛淘宝、天猫时最关注的通常是价格，比如这件衣服打几折，那里可以领到红包或优惠券，另外的关注点就是商品。商品图片是给消费者最直观的印象，直接影响店铺商品的销量。那这些海量的图片到底是存储在哪里呢？答案就是阿里云对象存储 OSS。
OSS 是阿里集团非结构化数据的统一存储系统，为天猫、淘宝、聚划算、飞猪、饿了么、UC、优酷、小微金服、钉钉、菜鸟、AliExpress、Lazada 等提供服务，存储了超万亿商品详情、主图、视频、音频、文档等各种类型文件，总数据量达数 EB 级别。其中，淘宝、天猫商品图片是支撑双十一的核心服务，通过图片空间业务支撑双十一的顺利开展。
2、图片空间业务的存储技术演进
淘宝、天猫电商网站的图片随着用户的增长、商户的入住而增多，其后端的图片存储技术也伴随着图片数量的几何级增长而演进。其技术也是逐步从 TFS 演进到 OSS，回顾技术发展过程，可以更好的掌握中间的决策原因。
2.1 （2007年前）基于NAS的图片存储
图片空间采用分层架构，上图是 2010 年“Taobao 海量图片存储与 CDN 系统”的内容。通过 CDN 提供 L1/L2 Cache，后端应用连接存储提供图片服务。在 TFS 之前，图片存储最早采用 NetApp 提供的 NAS 存储设备，但是在 2006～2007 年期间，随着淘宝的影响越来越大，数据的安全也更加重要，数据存储量以每年二倍的速度增长，弹性扩展的需求非常明显，采用 NAS 存储设备存在诸多痛点：
对小文件的存储、访问无法优化。
文件数量大，网络存储设备无法支撑。
连接的服务器越来越多，网络连接数已经到达网络存储设备的极限。
扩容成本高，10TB 的存储容量需要极其高昂的费用。
容灾和安全性无法得到很好的保证。
因此，通过升级设备来支撑已经变得非常昂贵，且得不偿失。必须要通过新技术来解决这些问题，特别是小文件存储的扩展性问题。
2.2 （2007-2015年）基于TFS的图片存储
为解决 NAS 的扩展性问题，淘宝研发上线了 TFS，它是淘宝针对海量非结构化数据存储自主设计和研发的分布式文件系统，构筑在普通的 Linux 机器集群上，对外提供高可用、高性能、高可扩展性的存储访问。针对淘宝图片单个文件尺寸较小（通常不大于 1MB），但数量巨大的特点而设计。
2007年6月，淘宝自主开发的分布式的文件系统 TFS 1.0 上线运行，分布式存储集群规模为200台 PC Server，支持文件数量为亿级，系统部署存储容量为 140 TB，业务实际使用存储容量为 50 TB，单台 Server 支持随机IOPS 200+、流量3 MB/s。TFS 1.0 架构如下图所示，集群由两台 Name Server 和多台 Data Server 构成。每台 Data Server 运行实体是普通的 Linux 主机，它以 block 文件的形式存放数据文件（通常每个 block 大小为 64MB）。为保证数据安全 block 会存多份，而 block 文件则存储在 ext3 文件系统上。为了保证 ext3的数据冗余，底层采用基于磁盘 raid5 的技术。Name Server 的文件名内置元数据信息，用户自己保存 TFS 文件名与实际 block 文件的对照关系，从而使得元数据量特别小。
2009年6月TFS 1.3上线运行。分布式存储集群规模为470台 PC Server，支持文件数量为百亿级，系统部署存储容量为 1800 TB，业务实际使用存储容量为 995 TB，单台 Server 支持随机IOPS 900+、流量15+ MB/s，TFS 1.3提供加强扩展性相关功能特性。
所有元数据全部内存化。
实现清理磁盘空洞能力。
容量和负载的均衡策略。
平滑的扩容能力。
数据安全性的冗余保证。
秒级 Name Server故障自动切换。
容灾策略。
性能大幅提升。
TFS 1.3架构如下图所示，和 TFS 1.0 相比采用具有容错能力的 MySQL Dup Store，并且实现 Name Server 的故障切换架构，从而提高系统可用性。
经过几年双十一的考验和打磨，TFS 在性能和稳定性上都取得了长足的进步。但是随着淘宝业务的不断发展，TFS 的一些劣势逐渐凸显：
缺乏多租户隔离机制。TFS 是内部系统，并未提供多租户隔离的机制，导致随着业务方越来越多，各个业务方互相影响导致出问题的几率越来越大，某个业务的突发流量可能会打爆整个系统，最终导致所有业务都无法使用而出现大面积业务中断。
视频大文件性能不足。TFS 在小文件访问上做了大量优化，但是在视频类等大文件的访问上，性能并不突出。
产品化能力待提升。TFS 不支持用户自定义文件名、不支持计量计费和审计等功能，也影响着业务方的使用体验。
2.3 （2016年-至今）基于OSS的图片存储
阿里云对象存储服务 OSS（Object Storage Service）提供海量、安全、低成本、高可靠的云存储服务，其数据设计持久性不低于 99.9999999999%（12 个 9），可用性（或业务连续性）不低于 99.995%。
OSS 使用 RESTful API 可以在互联网任何位置存储和访问，容量和处理能力弹性扩展，多种存储类型供选择全面优化存储成本，用户按实际容量付费，只需真正专注于核心业务。OSS 适合存放任意类型的文件，不管是图片类的小文件，还是视频类的大文件，OSS 都能提供高性能、高稳定的存储和访问。
OSS 架构如下图所示，主要包括协议层、索引层、盘古存储层的三层架构，最上层是网络接入的负载均衡。
协议层，主要负责协议处理、权限验证、多租户隔离 QoS、安全防护、计量、审计等能力，相对于 TFS，OSS 提供更丰富的多用户接入能力，能够满足集团众多业务方的接入需求。
索引层，主要负责数据切片、分区、压力均衡，避免访问热点，同时提供数据的索引信息，在读取时降低访问延迟。不管是图片类小文件，还是视频类大文件，相对于 TFS，都能提供极高性能的读写能力。讨论 TFS 迁移到 OSS 时，图片业务也经过多轮的性能对比，OSS 在各种大小数据的场景表象上，都优于 TFS。
盘古存储持久层，主要实现数据持久化、多副本容灾的能力，多个副本分布在不同机器、机架上保障数据高可用和高可靠。
选择 OSS 作为图片空间的后端存储后，新数据写入 OSS非常简单易用。但是还需要解决 大规模的 TFS 存量数据迁移到 OSS，以及兼容原有 TFS 访问接口的问题。如下架构图，介绍在TFS基础上增加后端使用 OSS 机群实现数据平滑迁移的技术原理，整体流程的核心是 TFS2OSS Proxy 模块。
TFS2OSS Proxy 负责将接收到的 TFS 请求转换为对 OSS 后端存储集群的请求，并按照TFS 协议相兼容的格式返回结果，技术上等价于 OSS 协议层的扩展。在 OSS 中创建业务需要的桶（bucket），用于存放要迁移的数据，通过桶元数据标识的位置信息来决定当前的主写集群，从而基于本地配置信息来决定就近读取的后端集群。
3、基于 OSS 构建图片空间存储的技术亮点
淘宝、天猫图片空间在选择使用对象存储 OSS 作为后端图片存储平台后，也不断在稳定性、性能、成本方面提出新的需求，因此 OSS 也在不断创新技术来保证图片空间的竞争力。
3.1 基于 OSS “跨地域复制+回源”实现图片空间异地多活高可用
对于双十一业务的重要性增加，业务对稳定性要求也越来越高。如果由于机房断电或者光缆被挖断，导致淘宝商品图片无法访问，那么也将导致交易量的大幅下跌，这是不可容忍的重大故障。
为避免机房级别的故障给双十一图片访问带来的稳定性影响，确保双十一顺利进行。图片空间基于 OSS 的“跨地域复制+镜像回源”打造了异地多活的架构，如下图所示。
业务基于该架构采用一写多读模式，通过开通 OSS 主地域（Region）到两个备地域的跨地域复制功能实现。
写入时只写主地域，开发便捷。利用“OSS 跨地域复制能力”，将数据复制到备地域，从而备地域有全量的数据。
读取时可根据地域就近读取，降低延迟。由于写入时只写数据到主地域，数据是异步复制到备地域，所以用户读备地域数据时，可能数据还未复制完成，此时可通过“OSS 镜像回源功能“从主地域读取数据。
从而，可在不同的地域级故障场景时，实现快速切换，提供容灾秒级 RPO，保证业务应用连续性。
备地域不可用，上层业务快速切换到另外 2 个地域，并将流量均分，业务能立即恢复，切换也非常方便。
主地域不可用，则选择新的主地域(如选择地域2)，并开通地域2到地域3的跨域复制，从而业务可以将写请求切换到新的主地域，读请求也切换到剩下的地域；同时，基于OSS 的“版本控制”和业务“无更新写”，实现了主地域故障切换的数据一致性。
3.2 全面上 OSS 公共云，优化图片处理时延提高用户体验
业务采用异地多活架构提高系统可用性，经过 2016、2017 两年双十一的考验，集团业务完全扛住双十一的峰值访问压力，性能表现优异。除了提供高可靠、高可用、高 QPS 的访问外，在多租户隔离 QoS、安全防护、计量、审计等功能方面，也能完全满足集团各种业务的使用需求。在满足业务的同时，也带来新的问题。
弹性扩展，解决资源固化的浪费。尽管从 TFS 切换到 OSS，但图片空间业务在支持双十一时仍然保留原有的资源固定申请模式。在每年双十一前，都需要对集群的机器和网络资源进行专门扩容；在双十一后，业务洪峰过后扩容的集群资源无法内部消化掉，从而导致浪费。
图片处理瓶颈。随着双十一峰值压力逐年增加，图片处理量也越来越大，依赖 CPU 来处理图片性能较低，还需要消耗大量 CPU 算力，从而导致图片处理逐渐成为双十一访问的瓶颈。
3.2.1 百分百上 OSS 公共云
为了解决上述问题， 2018 年启动图片空间全面上云。通过如下的评估，可以发现通过将“资源固定申请”转换为公共云弹性扩展可以大幅优化资源使用，并且 OSS 的公共云规模完全可以扛住图片空间的容量和性能需求。
资源优化分析。通常双十一峰值访问量可达到日常访问量的 5 倍左右，双十一峰值的资源在使用过后会限制数月，其他业务也服务有效使用。将图片空间切换到 OSS 公共云后，将直接使用公共云资源池，按需使用资源，按实际使用量付费，从而带来资源的数倍优化。
OSS 公有云的规模化能够支撑图片空间上云。随着阿里云业务的不断发展，业务量已经占据了国内公共云市场的半壁江山，形成巨大的规模化效应。图片空间的用量需求，相较于业界而言非常大，但也仅是公共云规模的 N 分之一，完全可以用 OSS 公共云资源池来满足。
因此，业务方和 OSS 技术方决策利用公共云强大的资源池能力，将淘宝图片业务迁移到公共云。在双十一高峰期，OSS 可以做到基本不用做特别的机器和网络扩容，就能利用公共云资源完全抗住业务洪峰，从而充分的利用资源，这也是公共云规模化效应给集团业务带来的巨大好处。
3.2.2 图片处理通过硬件卸载降低时延，提升用户商品购买体验
对于双十一而言，在峰值时刻用户流量商品图片带来的访问量，带宽达到 Tbps 级别。提高图片的压缩比，能够给用户淘宝客户端和服务端节省巨大的流量。某种意义上来说，图片的编码技术直接影响着双十一的成本。
自 1990 年初到现在的近 30 年期间，图片编码技术经历飞速发展，从最初的 JPEG 格式，到谷歌主导的 WebP 格式，及 MPEG 标准组织制定 HEIF 格式，压缩率有着极大的提高。但与此同时，编码计算复杂度也明显上升。从而图片处理极大的增加CPU 负载，根据实际测试，WebP/HEIF 格式的编码 CPU 消耗是同等大小 JPEG 的 10 倍以上，如果还使用 CPU 处理，将不可避免地扩容大量计算机器。
随着近年 FPGA 异构计算在人工智能领域的大热，FPGA 开始进入硬件卸载的视野。相比 CPU 而言，FPGA 具有数百万的 LUT（查找表，可以实现逻辑运算）、上万个存储单元、数千个 DSP 运算单元，可实现数千并发，非常适合于做图片处理，且在此场景下成本具有优势。 因此 OSS 基于 FPGA 打造的图片处理硬件卸载功能，在单机性能上达到了数十倍的提升，而单位成本降低到以前的十分之一，从带宽和机器数目上，大大降低双十一图片处理的成本，其架构如上图所示。
3.3 基于 OSS “生命周期管理”实现图片空间成本优化
到 2019 年，图片空间存储的图片文件数已超万亿级。OSS 作为海量存储资源池，保存的数据随着日积月累其访问性能要求也逐渐下降，由热数据逐步改变为冷数据；随之而来的则是冷数据希望成本越来越低，从而可以长期将数据保存下来。
为了解决该问题，OSS 提供了4种存储类型：标准型、低频型、归档型、冷归档，依次性能降低并且成本也降低，同时为了方便客户使用，通过生命周期管理特性基于策略自动完成数据的分级分级存储，从而保证整体性价比的最优。
该特性始终保持将不同类型数据存储在相同桶的同一名字空间，其核心点就是“生命周期按策略的分级数据存储”，通过此方法将保存海量的对象结合清单（Inventory）功能有效的管理数据资产，从而实现海量存储的极致成本优化。
4、迁移 TFS 到 OSS 的最佳实践推广
基于 OSS 成功实现阿里集团 TFS 全面迁移上云，在此过程中也积累大量的经验。2010 年 TFS 选择社区开源，该技术方案被许多互联网客户所采用，他们也规模化、多租户、可靠性、性能、成本上都遇到了挑战，因此也选择迁移到 OSS 的技术方案。
某音频客户在选型对比后，决策从自建 TFS 迁移上云，由于历史原因，没有现成 TFS 文件清单等信息。因此 OSS 团队结合集团上云的实战积累，决定帮助客户解决大规模存量自建 TFS 数据上云难题，形成如下最佳实践。
4.1 客户 TFS 现状分析
客户采用开源的 TFS 1.3 构建机群，对应的数据访问流程如下。
在TFS中以block 方式组织文件的存储，大量的用户文件（长度较小）合并成为一个大文件，大文件称为块（block）。
每个block 在整个集群内拥有唯一编号，该编号由 Name Server 分配，而 Data Server上实际存储该 block。
在 Name Server 节点中存储所有 block 的信息，每个 block 会存储到多个 Data Server 中，以保证数据的冗余。
对于数据读写，均先由Name Server 选择合适的 Data Server 节点返回给客户端，再去对应的 Data Server 节点上进行数据访问。Name Server 需要维护 block 信息列表，以及 block 与 Data Server 间的映射关系。
TFS 的文件名由块号和文件号通过某种对应关系组成，最大长度为 18 字节。文件名固定以T 开始，第二字节为该集群的编号(可以在配置项中指定，取值范围 1~9)。余下的字节由 block ID 和 File ID 通过一定的编码得到。
4.2 技术难点
数据迁移前
由于历史原因，客户没有 TFS 文件清单，且无方案获得该清单，导致无法直接通过文件清单迁移数据。
文件存储在 TFS 存储中并且无后缀，无法分辨文件类型。
数据迁移中
部分 block 文件为空，需要在导出文件列表过程进行判定筛选。
数据迁移机器使用资源池，需要弹性的迁移工具支持横向扩容，保证高效使用。
数据迁移后
由于 TFS 文件一致性记录的为 CRC32，迁移后的校验需要 OSS 也提供 CRC32 的校验值，从而保证与源数据比对一致。
4.3 解决方案
在数据迁移前，首先分析客户 TFS 中的命名特征，找出用户可见的文件名，如上图所示。
获取TFS文件清单，通过工具扫描到工作目录的所有索引文件路径，利用 TFS自带read_index_tool工具来解析每个索引文件内容，得到blockId、FileId（File SequenceId + Hash Suffix），然后使用 TFS自带convert_name工具拼接blockId、FileId，得到block文件名。
精确获取文件类型，通过工具解析block文件名。得到Hash Suffix（文件扩展名的hash值），采用“彩虹表”方式基于Hash Suffix反推文件的扩展名（因为客户的扩展名是一个优先集），最终得到TFS原始文件名（含扩展名）。
获取到文件名列表，就可以执行迁移动作，需要关注如下技术难点。
1）解决部分 block 文件为空问题。根据 TFS 内部技术原理，会预留部分空 block 作为缓冲，以应对突发的写请求，因此在数据导出后，需要比对副本内的文件列表，若不一致则取三者并集。
2）解决数据迁移机器的弹性扩展问题。在配合客户实现数据迁移过程中，需要根据需要实现迁移服务的弹性扩容、缩容，通过改造迁移工具实现动态增、减机器，并且均衡任务到新机器。
数据迁移完成后，还需要完成 CRC32 比对。考虑到 TFS只存储文件的 CRC32 信息，且客户 TFS 已经在生产服务建设很长周期，性能较差。因此，不推荐做全量比对，而是做抽样的比对。迁移工具从文件列表中随机抽取文件，然后比对 TFS 原文件和 OSS 新文件。若一致，则说明数据正确，然后将 OSS 上的文件名、crc64、size 输出到结果文件中，以备客户进行三方对比；若不一致，则记录并上报，待后续修正。
4.4 客户价值
通过将自建 TFS 迁移到 OSS 云服务，提高系统的稳定性和性能，同时降低客户自己运维机群的复杂度，通过 OSS 按需付费、生命周期降低了整体成本。
同时，在客户上云过程中，解决了无现有 TFS 文件列表迁移难题，实现数据顺利迁移上云，成功的将 OSS 在阿里集团上云的经验应用到了更多的互联网客户场景。
5、总结
双十一图片存储技术演进，就是在数据存储道路上，追求更高性能、更低成本、更丰富更强大功能的历史。从最初的 TFS 满足小文件存储和访问功能，到图片存储基于 OSS 构建多租户、全面上云、异地多活、图片处理硬件卸载等核心技术，都见证了阿里云存储技术的发展。
