linkedin架构演化历史解析

linkedin架构演化历史解析

ID:32658109

大小:192.94 KB

页数:6页

时间:2019-02-14

linkedin架构演化历史解析_第1页
linkedin架构演化历史解析_第2页
linkedin架构演化历史解析_第3页
linkedin架构演化历史解析_第4页
linkedin架构演化历史解析_第5页
资源描述:

《linkedin架构演化历史解析》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、Linkedln架构演化历史解析Linkedln创建于2003年,主要目标是连接你的个人人脉以得到更好的的工作机会。上线第一周只有2700个会员,Z后几年,Linkedln的产品、会员、服务器负载都增长非常快。今天,Linkedln全球用户己经超过3.5亿。我们每天每秒有上万个页面被访问,移动端流量己占到50%以上。所有这些接口请求都从后台获取,达到每秒上百万级。那么,我们是怎么做到的呢?早些年-LeoLinedin开始跟很多网站一样,只有一台应用服务做了全部工作。这个应用我们给它取名叫“Leo”o它包含了所有的网站页面(JAVAServlets

2、),还包含了业务逻辑,同时连接了一个轻量的Linkedln数据库。哈!早年网站的形态■简单实用会员图表第一件要做的是管理会员与会员间的社交网络。我们需要一个系统来图形化遍历用户之间连接的数据,同时又驻留内存以达到有效和高性能。从这个不同的需求来看,很明显我们需要可以独立可扩展的Leoo-个独立的会员图示化系统,叫“云”的服务诞生了-Linkedln的第一个服务。为了让图表服务独立于Leo,我们使用了JavaRPC用来通讯。也大概在这期间我们也有搜索服务的需求了,同时会员图表服务也在给搜索引擎-Lucene提供数据。复制只读数据库当站点继续增长,L

3、eo也在增长,增加了角色和职责,同时自然也增加了复杂度。负载均衡的多实例Leo运转起来了。但新增的负载也影响了Linkedln的其它关键系统,如会员信息数据库。一个通常的解决方案是做垂直扩展-即增加更多的CPU和内存!虽然换取了时间,但我们以后还要扩展。会员信息数据库受理了读和写请求,为了扩展,一个复制的从数据库出现了,这个复制从库,是会员主库的一个拷贝,用早期的databus來保证数据的同步(现在开源了)。从库接管了所有的读请求,同时添加了保证从库与主库一致的逻辑。当主■从架构工作了一段时间后,我们转向了数据库分区当网站开始看起来越来越多流量,

4、我们的应用服务Leo在生产环境经常宕机,排查和恢复都很困难,发布新代码也很困难,高可用性对Linkedln至关重要,很明显我们要“干掉”Leo,然后把它拆分成多个小功能块和无状态服务。面向服务的架构-SOA工程师从分解负担API接口和业务逻辑的微服务开始,如搜索、个人信息、通讯及群组平台,然后是展示层分解,如招募功能和公共介绍页。新产品和新服务都放在Leo之外了,不久,每个功能区的垂直服务栈完成了。我们构建了从不同域抓取数据模型的前端服务器,用于表现层展示,如生成HTML(通过JSPs)。我们还构建了中间层服务提供API接口访问数据模型及提供数据

5、库一致性访问的后端数据服务。到2010年,我们已经有超过150个单独的服务,今天,我们已经有超过750个服务。Browser/AppFrontendWebApp因为无状态,可以直接堆叠新服务实例及用硬件负载均衡实现扩展。我们给每个服务都画了警戒红线,以便知道它的负载,从而制定早期对策和性能监控。缓存Linkedln可预见的增长,所以还需要进一步扩展。我们知道通过添加更多缓存可以减少集屮压力的访问。很多应用开始使用如memcached/couchbase的中间层缓存,同时在数据层也加了缓存,某些场景开始使用useVoldemort提供预结果生成。又

6、过一了段时间,我们实际上去掉了很多屮间层缓存,屮间层缓存数据往往来自多个域,但缓存只是开始时对减少负载有用,但更新缓存的复杂度和生成图表变得更难于把控。保持缓存最接近数据层将降低潜在的不可控影响,同时还允许水平扩展,降低分析的负载。Kafka为了收集不断增长的数据,Linkedln开始了很多自定义的数据管道来流化和队列化数据,例如,我们需要把数据保存到数据仓库、我们需要发送批量数据到Hadoop工作流以分析、我们从每个服务聚合了大量日志、我们跟踪了很多用户行为,如页面点击、我们需要队例化InMail消息服务、我们要保障当用户更新个人资料后搜索的数

7、据是最新的等等。当站点还在增长,更多定制化管道服务出现了,因网站需要可扩展,单独的管道也要可扩展,有些时候很难取舍。解决方案是使用kafka,我们的分布式发布■订阅消息平台。Kafka成为一个统一的管道服务,根据提交的日志生成摘要,同吋一开始就很快速和具有可扩展性。它可以接近于实时的访问所有数据源,驱动了Hadoop任务,允许我们构建实时的分析,广泛的提升了我们站点监控和告警的能力,同时支持将调用可视化。今天,Kafka每天处理超过5亿个事件。FrontendFrontendBackendserviceserviceServiceKafkaJDW

8、HOracleMonitoringAnalyticsHadoop反转扩展可从多个维度来衡量,包括组织结构。20H年晚些时候,Linked

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。