LinkedIn架构这十年

LinkedIn 架构 Rest.li Kafka

摘要

自2013年创立至今，LinkedIn全球用户数已经从第一周的2700增长到了现在的3个多亿。它每天每秒都要提供成千上万的网页请求，而且移动账户已经占据了全球50%的流量。所有这些请求都是从他们的后台系统获取数据，而这个后台系统每秒需要处理数以百万计的查询。近日，LinkedIn高级工程经理Josh Clemm撰文介绍了LinkedIn架构10多年来的演进。

正文

自2013年创立至今，LinkedIn全球用户数已经从第一周的2700增长到了现在的3个多亿。它每天每秒都要提供成千上万的网页请求，而且移动账户已经占据了全球50%的流量。所有这些请求都是从他们的后台系统获取数据，而这个后台系统每秒需要处理数以百万计的查询。近日，LinkedIn高级工程经理Josh Clemm撰文介绍了LinkedIn架构10多年来的演进。

Leo

最开始的时候，LinkedIn是一个他们称之为“Leo”的单体应用。该应用托管着所有各种页面的Web Servlet，处理业务逻辑，并连接到少量的LinkedIn数据库。

“会员图（Member Graph）”

作为一个社交网络，他们做的第一件事是管理会员之间的连接关系。他们需要一个系统，使用图遍历的方式查询连接数据，并且要常驻内存，以保证效率和性能。同时，它还需要能够独立于Leo进行扩展。因此，他们为实现会员图创建了一个单独的系统Cloud。LinkedIn的第一个服务就此诞生。为了实现图服务与Leo的分离，他们使用了Java RPC通信。大约正是这个时候，他们产生了搜索功能需求。他们的会员图服务开始向一个新的运行Lucene的搜索服务提供数据。

只读副本数据库

随着网站的发展，Leo的功能越来越多，复杂性也越来越高。负载均衡可以帮助启动多个Leo实例。但新增的负载使LinkedIn最关键的系统不堪负重——会员资料数据库。

这个问题可以通过简单地增加CPU和内存来解决。他们这么做了，但还是不够。资料数据库需要同时处理读写流量，所以为了扩展，他们引入了从属副本数据库。该库是会员数据库的一个副本，二者之间使用databus（现已开源）的早期版本保持同步。副本数据库负责处理所有的读流量，而且他们构建了一个逻辑，用于确定什么时候从副本读取是安全的。

但随着流量越来越大，作为单体应用的Leo经常宕掉，而且很难诊断和恢复，新代码也不容易发布。对LinkedIn而言，高可用性非常关键。显然，他们需要需要将Leo分解成许多小功能和无状态服务。

面向服务的架构

他们抽取微服务和业务逻辑，然后按领域抽取展示层。对于新产品，他们会在Leo之外创建全新的服务。他们构建了前端服务器，用于从不同的域中获取数据、处理展示逻辑以及通过JSP构建HTML。他们构建了中间层服务，提供访问数据模型和后端数据服务的API，实现对数据库的一致性访问。到2010年，他们已经有超过150个单独的服务。现在，他们有超过750个服务。

至此，他们已可以针对单个服务进行扩展。期间，他们还构建了早期的配置和性能监控功能。

缓存

由于发展迅猛，LinkedIn需要进一步扩展。他们通过增加更多的缓存层来减少整体负载。比如，引入类似memcache或couchbase的中间层缓存，向数据层添加缓存，并在必要的时候使用Voldemort进行预计算。但实际上，随着时间推移，考虑到缓存失效增加了系统复杂性，而“调用图（call graph）”难以管理，他们又去掉了许多中间层缓存，而只保留了离数据存储最近的缓存，在保证低延迟和横向扩展能力的同时，降低了认知负荷。

Kafka

为了收集日益增长的数据量，LinkedIn开发了许多自定义的数据管道，用于对数据进行流式处理。例如，他们需要让数据流入数据仓库，需要将数据批量发送给Hadoop工作流用于分析，需要收集和汇总每个服务的日志信息，等等。随着网站的发展，这样的自定义管道越来越多。如果网站需要扩展，每个管道都需要扩展。因此，他们基于提交日志的概念开发了一个分布式的发布订阅消息平台Kafka，作为通用的数据管道。该平台支持对任何数据源的准实时访问，有效地支撑了Hadoop作业和实时分析，极大了提升了站点监控和预警功能，使他们可以可视化和跟踪调用图。现在，Kafka每天处理超过5000亿事件。

Inversion

2011年底，LinkedIn启动一个名为Inversion的内部项目，暂停了所有的功能开发，整个工程组织全部致力于改进工具、部署基础设施和开发效率。

Rest.li

在从Leo转换到面向服务的架构的过程中，抽取出来的API采用了基于Java的RPC技术，不仅各团队不一致，而且与展示层紧耦合。为了解决这个问题，他们构建了一个新的API模型Rest.li。这是一种以数据模型为中心的架构，可以确保整个公司使用同一个无状态的Restful API模型，而且非Java客户端也可以轻松地使用。这一措施不仅实现了API与展示层的解耦，而且解决了许多向后兼容的问题。此外，借助动态发现（D2），他们还针对每个服务API实现了基于客户端的负载均衡、服务发现和扩展。现在，LinkedIn有超过975个Rest.li资源和每天超过1000亿次的Rest.li调用。

“超块（Super Blocks）

面向服务的架构可以解耦域及实现服务的独立扩展，但它也有缺点。他们的许多应用程序都需要获取许多类型的不同数据，发起数以百计的调用。所有的调用就构成了上文提到的“调用图”。该调用图非常难以管理，而且管理难度越来越大。为此，他们引入了“超块”的概念，为一组后端服务提供一个可以独立访问的API。这样，他们就可以有一个专门的团队对块进行优化，并控制每个客户端的调用图。

多数据中心

他们不仅要避免单个服务成为单点故障点，而且要避免整个站点成为单点故障点，因此多数据中心非常重要。现在LinkedIn主要通过三个数据中心提供服务，并在全球范围内提供PoPs服务。

正如Clemm所言，他们的故事远不止这么简单。许多关键系统的背后都有一段丰富的历史，比如，会员图服务、搜索、通信平台、客户端模板等，感兴趣的读者可以进一步阅读。

查看原文：A Brief History of Scaling LinkedIn