BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

LinkedIn架构这十年

| 作者 谢丽 关注 10 他的粉丝 发布于 2015年8月19日. 估计阅读时间: 7 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

2003年创立至今,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需要进一步扩展。他们通过增加更多的缓存层来减少整体负载。比如,引入类似memcachecouchbase的中间层缓存,向数据层添加缓存,并在必要的时候使用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


感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2013 or 2003 by 王 辉

开头年份就写错了,作者以及审校都没发现吗

Re: 2013 or 2003 by Guo Gary

不好意思,没发现,立即修正。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT