靠谱 的软件外包伙伴

您的位置:首页 > 新闻动态 > LinkedIn软件开发架构升级之路

LinkedIn软件开发架构升级之路

2016-02-01 11:37:56

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服务。

 

关于:中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务,十年研发经验,上百成功案例,中科院软件外包合作企业。通过IT技术实现创造客户和社会的价值,致力于为用户提供最佳的软件解决方案。联系电话400-0316-532,邮箱sales@zhongkerd.com,网址www.zhongkerd.com


  上一篇   [返回首页] [打印] [返回上页]   下一篇