Flickr存储150亿张图片架构系统之Tripod揭秘

Flickr是著名的在线图片和短视频分享的社交网站，于2005年3月被Yahoo! 以3500万美金收购。
Flickr的图片和视频存储系统被称为『Tripod』，对这些多媒体数据进行处理，存储，管理及提供查询检索。Yahoo的技术团队在传统网站架构上做了延伸，目前已采用微服务这一流行架构理念，敬请浏览。

最初的LAMP架构

 
Flickr最开始的架构为经典的LAMP平台。
 
它是从一台服务器起步的，即Apache/PHP和MySQL是运行在同一台服务器上。很快MySQL服务器就独立出来，成了双服务器架构。
 
随着用户和访问量的快速增长，MySQL数据库开始承受越来越大的压力，成为应用瓶颈，导致网站应用响应速度变慢。

 
Flickr的逻辑架构
 
一般来说，数据库的扩展无外是两条路，Scale-Up和Scale-Out。Scale-Up，简单的说就是在同一台机器内增加CPU、内存等硬件来增加数据库系统的处理能力，一般不需要修改应用程序；Scale-Out,就是我们通常所说的数据库集群方式，即通过增加运行数据库服务器的数量来提高系统整体的能力，而应用程序则一般需要进行相应的修改。分别使用了：
 
PHP
Flickr运行在Redhat Linux上，Web服务器使用Apache，Flickr网站大约有6万行PHP代码；它没有使用Session, 应用是无状态stateless,便于扩展，避免PHP故障所带来的Session失效。
每个P访问。
 
MySQL集群
MySQL使用了master-slave结构，各位都知道存在”single point of failure”(单点故障问题)，且只对读操作有好处。master轮询，保证同时只有一个master负责写，从页解决了单点故障的问题。
 
Shards
使用Memcached 作为中间缓存层；
使用Squid 作反向代理服务器(反向代理HTML和图片)。
 
Smarty 模板
PHP的一种半编译模板语言，相当于PHP静态页面化。
 
Perl
用Perl做系统管理，比如日志分析等。
 
PEAR
PHP外部优质库，做XML和Email解析。
 
ImageMagick
图像处理，后来转移到Graphics Magick，处理速度提升了15%。
 
Java 作为节点服务
Apache SystemImager 作为服务器部署 
Ganglia 布式系统监控
Subcon 用SVN维护服务器配置文件并且可以部署不同的配置文件到服务器集群中去。
Cvsup 用做文件分发、更新。
Wackamole前端负载均衡。
Pair of ServerIron’s 做负载均衡方案 。
 

 
Flickr物理架构
 
双主数据库集群（Dual Tree Central Database）
－ MySQL 数据库，存放用户表，记录的信息是用户主键以及此用户对以的数据库Shard区，从中心用户表中查出用户数据所在位置，然后直接从目标Shard中取出数据。
－ “Dual Tree”架构是”Master－Master”和“Master-Slave”的有效结合，双Master 避免了“单点故障”，Master－Slave又提高了读取速度，因为用户表的操作90％以上是读。
 
双主集群（Master-master shards）
－ MySQL 数据库，存储实际的用户数据和照片的元数据（Meta Data)，每个Shard 大约40万个用户，120GB 数据。每个用户的所有数据存放在同一个shard中。
－ Shard中的每一个server的负载只是其可最大负载的50％，这样在需要的时候可以Online停掉一半的server进行升级或维护而不影响系统性能。
－ 为了避免跨Shard查询所带来的性能影响，一些数据有在不同的Shard有两份拷贝，比如用户对照片的评论，通过事务来保证其同步。
 
Memcached集群
用来做中间层缓存服务器，主要是缓存数据库的SQL查询等。
 
大数据搜索引擎
– 复制部分Shard数据（Owner’s single tag）到Search Engine Farm以响应实时的全文检索。
– 其他全文检索请求使用了Yahoo的搜索引擎处理。
 
存储管理
运行在私有的，适用于海量文件存储的Flickr 文件。
用了Net App公司的文件NAS存储设备，用于存储图片。其服务器的硬件配置如下：
– Intel或AMD 64位CPU，16GB 内存
– 6-硬盘 15K RPM RAID-10.
– 2U 服务器.
 
服务器总体数量和角色如下：
166台 数据库服务器,244台 Web 服务器（未包括 Squid）, 14台 Memcached 服务器。
 
使用System Imager/System Configurator 自动化安装、软件分发使用Subcon作为配置管理工具提高部署效率。
 
使用Ganglia 来进行容量数据的展现。Ganglia主要的优点是管理方便，是Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比 Cacti + Collectd 需要进行很多手工配置，更加方便。
 
Flickr技术团队很强调可测量(measurement)的重要性，对benchmark不甚关心。
 
无论是对开源软件比如Cassandra的benchmark，或是自己开发的进程的性能测试，都与上线后运营的负载差异太大，以致对容量规划几乎没帮助。基本上需要在灰度发布后根据实际应用负载才能做靠谱的规划。
 
随着网站的快速发展技术团队并没有增加大量人手，个人生产力的产出是相当的高。如何做到的呢，有如下四个非常有趣的原则：

[]机器自动构建 (Teach machines to buildthemselves)[/][]机器自监控(Teach machines to watch themselves)[/][]机器自修复(Teach machines to fix themselves)[/][]流程减少 MTTR (Reduce MTTR by streamlining)[/]

 
在自动构建上，Flickr 还使用了OpsCode 、Puppet 以及 System Imager/Configurator 等工具。
 

 
Flickr第一代网站架构全图
 
可以说，这个网站架构时至今日仍值得我们关注和学习。

Tripot新架构 

 
Tripot 近日在雅虎邮箱引入了一个功能，允许自动同步手机照片到雅虎邮件，以便用户在写电子邮件的时候可以随时引用照片。也提供了一个很好的机会，把 Flickr 功能带到Yahoo其它的网站产品。
 
Tripod 三大服务包括：
 

[]存储及转码服务（Pixel Service）：用于上传，存储，调整大小，修改照片和视频。[/][]增强服务（Enrichment Service）：用于图像识别算法完善媒体元数据。例如，算法可以识别和标记场景，动作和对象。[/][]聚合服务（Aggregation Service）：用于应用程序和跨应用程序元数据聚合，过滤和搜索。[/]

 
这三种服务的组合使得 Tripod 成为新一代图片服务平台。还有一个管理控制台，用于配置应用程序与Tripod的集成，以及身份服务，用于身份验证和授权。
 
 

 
 Tripod新架构图
Pixel服务
 
Flickr 具有高可扩展性的图片上传和转码等流水线。
 
在大规模处理海量照片和视频的情况下，Flickr 的移动和API团队对技术进行了大量调优，比如断点上传和防重机制，以便创建高品质的照片上传体验。解决了优化存储而不影响照片质量的挑战，并添加了动态调整大小，以支持不同的客户端图片布局功能。

目前，Flickr 可以支持每秒上传超过 500 张+图片，这一系列流水线包括了 PHP 上传接口，后端 Java 服务（图片监控，主存储），美国西部和东部海岸的上传热点，以及五个全球图片缓存节点以及大量的 CDN 。

在 Tripod 的 Pixel 服务中，Flickr利用所有这些核心技术基础设施，除了新的 Java API，还实现了一个新的基于桶的数据模型。
 Enrichment Service
 
2013 年，Flickr 开始了开始了更令人兴奋的前进，Yahoo!收购了计算机视觉技术公司 IQ Engines 和 LookFlow，并将这些团队转到 Flickr。使用这些图像识别算法，增强了 Flickr 搜索和 Flickr Magic View。

在 Tripod 中，Enrichment 服务提供应用图像识别技术，产生丰富的元数据，可用于增强过滤，索引和搜索。Enrichment 服务可以识别地点，主题，地标，对象，颜色，文本，不适合公开浏览内容（NSFW）和缩略图。它还可以进行 OCR 文本识别，生成美学指数来计算照片的整体质量。
 
 The Aggregation Service
 
Aggregation 服务允许应用程序（如Yahoo Mail）根据任何条件查找媒体。例如，它可以返回属于特定地址中的特定人的所有照片（例如，2015年3月1日之前的旧金山）

Vespa 是 Yahoo 的内部搜索引擎，索引了每个多媒体的元数据。如果已运行 Enrichment Service 过，则元数据被 Vespa 索引，并且可用于 Aggregation API。 调用 Aggregation 服务的结果集取决于读取权限。
 
API和 SDK
 
每类服务合并为一组 API。Flicker升级了 API 技术栈，从 PHP 切换到 Spring MVC，并利用最新 Spring 特性，例如 Spring Data，Spring Boot 和 Spring Security 以及 OAuth 2.0。使用 Swagger (http://swagger.io/) 定义和记录 Tripod 的 API。每个服务都是从独立的 Git 存储库独立地开发和部署的，具有独立的构建生命周期和微服务容器。
 

 
Tripod API
 
Swagger 编辑器可以根据 Yahoo 开发人员的需要，轻松自动生成各种语言的 SDK。iOS 和 Android SDK 是移动开发最常用的，JS SDK 是 Web 常用的,通过 SDK 可以实现移动及 Web 端轻松与 Tripod 集成。 
 
Buckets 与 API Key
 
Tripod 数据模型与 Flickr 数据模型不尽相同。
 
Tripod 应用程序，存储桶和 API  加入了多租户的概念，具有强大的访问控制能力。应用程序是 Tripod 服务的使用方，如 Yahoo Mail；存储桶是应用程序存储的逻辑容器，应用程序中的媒体(media)受到存储桶设置（例如压缩率，容量，TTL 生存时间以及其他选项）的影响。
 

 
 
除了 Tripod 的通用属性，存储桶还可以由应用开发人员自定义组织属性。由 API key 控制对存储桶的读取/写入权限，生成的 OAuth 令牌对存储桶进行认证访问。
 

 
 
开发人员使用 Tripod 控制台，可以：

[]创建存储桶和 API key[/]

[]定义每个 API key 的存储桶设置和访问控制规则[/]

 
与 Flickr API 的另一个不同的是 Tripod 可以处理非用户生成的内容（UGC）的媒体——这是许多 Yahoo 应用所要求的。
 
架构和实现
 
从单一架构到微服务架构面临很大挑战。特别是需要在服务之间找到合适的通信方式，其核心是我们的 Pulsar 事件总线，通过总线发送 Avro 消息。这让每个 Tripod 团队迅速开发，而不会引发不兼容的修改。

对于数据持久化，Flickr将大部分数据移动到Yahoo!分布式 NoSQL 数据库 ，试验使用 Redis Cluster 作为缓存层，并使用 Vespa 来驱动聚合服务。
 
对于 Enrichment 服务，Flickr广泛使用了 Storm 和 HBase 进行实时处理 Tripod 视觉算法。最后还使用了 PIG，Oozie 和 Hive 在Yahoo!基础大数据平台上运行大量的计算任务。

在2017 年，Tripod 新架构将布署在 Flickr 系统 50％以上，Tripod 将支撑更多Yahoo应用的多媒体内容引用，为移动和PC版10亿以上用户提供坚实服务。
 

编译：21CTO社区
原文：https://yahooeng.tumblr.com/po … tored