“ Josh Clemm是LinkedIn的高级工程经理，他写了一篇文章介绍LinkedIn针对用户规模急速扩大带来的架构方面的变革。自2003年创立至今，LinkedIn全球用户数已经从第一周的2700增长到了现在的超过3.5亿，它每秒都要提供成千上万的网页请求，移动端流量占了50%以上。所有这些请求都是从后台系统获取数据，而这个后台系统每秒需要处理数以百万计的查询。


那么问题来了，这些都是怎么做到的？
早年间—Leo刚开始的时候，LinedIn只有一台应用服务做了全部工作。这个应用名叫“Leo”，它包含了所有的Web Servlet，处理业务逻辑，同时连接一个轻量的LinkedIn数据库。
会员关系图作为一个社交网络，第一件事要做的就是管理会员之间的连接关系。需要一个系统，使用图遍历的方式查询连接数据，并且要常驻内存以保证效率和性能。同时，它还需要能够独立于Leo进行扩展。因此，他们为实现会员图创建了一个单独的系统Cloud。LinkedIn的第一个服务就此诞生。为了实现图服务与Leo的分离使用了Java RPC通信。


大约正是这个时候，产生了搜索功能需求。会员关系图服务开始为一个基于Lucene的搜索服务提供数据。
多个只读数据库副本随着站点的增长， Leo系统也在扩大， 也更加复杂。 通过负载均衡可以运行多个Leo实例，但是新增的负载也使LinkedIn最关键系统——会员信息数据库不堪重负。
一个最容易的解决方案就是垂直扩展——在其上增加更多的CPU和内存。这虽然可以支撑一段时间，但是将来还是会遇到规模扩展的问题。会员信息数据库既处理读又处理写。 为了扩展，引入了从属副本数据库。 复制数据库是会员数据库的一个拷贝， 使用 databus （现已开源）的早期版本保持同步。副本数据库负责处理所有的读请求， 并且增加了保证主库和从库数据一致性的逻辑。

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

Kill Leo这个咒语在内部传颂了很多年

面向服务的架构—SOA工程师开始抽取出一些微服务，这些微服务提供API和一些业务逻辑，接着表现层也被抽取出来，比如招聘产品和公共信息页。新产品新服务都独立于Leo。


还构建了前端服务器， 可以从不同的域获取数据，处理展示逻辑以及通过JSP生成HTML。还构建了中间层服务提供API接口访问数据模型以及提供数据库一致性访问后端数据服务。到2010年有超过150个独立的服务，如今，已经有超过750个服务。


至此已可以针对单个服务进行扩展。期间还构建了早期的配置和性能监控功能。缓存由于发展迅猛，LinkedIn需要进一步扩展，通过增加更多的缓存层来减少整体负载。比如，引入类似memcache或couchbase的中间层缓存，向数据层添加缓存，并在必要的时候使用Voldemort进行预计算。但随着时间推移，考虑到缓存失效增加了系统复杂性，而“调用图”难以管理，于是又去掉了许多中间层缓存，而只保留了离数据存储最近的缓存，在保证低延迟和横向扩展能力的同时，降低了可知的负载。

Kafka为了收集日益增长的数据量，LinkedIn开发了许多自定义的数据管道，用于对数据进行流式处理。例如，要让数据流入数据仓库，需要将数据批量发送给Hadoop工作流用于分析，需要收集和汇总每个服务的日志信息，等等。随着网站的发展，这样的自定义管道越来越多。

随着网站还在壮大，更多的定制管道出现。因此又基于提交日志的概念开发了一个分布式的发布订阅消息平台作为通用的数据管道，也就是Kafka。该平台支持对任何数据源的准实时访问，有效地支撑了Hadoop作业和实时分析，极大了提升了站点监控和预警功能，使我们可以可视化和跟踪调用图。现在，Kafka每天处理超过5千亿事件。




Inversion扩展可以从很多维度来衡量，包括组织结构的扩展。2011年底，LinkedIn启动一个名为Inversion的内部项目，暂停了所有的功能开发，整个工程组织全部致力于改进工具、部署基础设施和开发效率。
近几年—Rest.li当我们从Leo转向面向服务的架构后，之前抽取的基于Java RPC的API, 在各团队之间开始变得不一致了，和表现层耦合太紧。为此我们开发了一个新的API模型Rest.li. 这是一种以数据模型为中心的架构，可以确保整个公司使用同一个无状态的Restful API模型，而且非Java客户端也可以轻松地使用。这一措施不仅实现了API与展示层的解耦，而且解决了许多向后兼容的问题。


此外，借助动态发现（D2），他们还针对每个服务API实现了基于客户端的负载均衡、服务发现和扩展。现在，LinkedIn有超过975个Rest.li资源和每天超过1000亿次的Rest.li调用。


超块（Super Blocks）面向服务的架构可以解耦域及实现服务的独立扩展，但它也有缺点。Linkedin的许多应用程序都需要获取许多类型的不同数据，发起数以百计的调用。所有的调用就构成了上文提到的“调用图”。该调用图非常难以管理，而且管理难度越来越大。为此引入了“超块”的概念，为一组后端服务提供一个可以独立访问的API。这样就可以有一个专门的团队对块进行优化，并控制每个客户端的调用图。多数据中心不仅要避免单个服务成为单点故障点，而且要避免整个站点成为单点故障点，因此多数据中心非常重要。现在LinkedIn主要通过三个数据中心提供服务，并在全球范围内提供PoPs服务。






Linkedin的故事远不止这么简单。许多关键系统的背后都有一段丰富的历史，比如，会员图服务、搜索、通信平台、客户端模板等等。
推荐阅读 1. 分布式消息系统Apache Kafka那些事儿
2. 深入理解git，从研究.git目录开始
3. 艰难的重构：10大常见的重构误区 
4. 函数式编程，想说爱你不容易
5. 专访人工智能专家吴恩达：不必对AI心怀恐惧 
6. 15个你必须知道的Facebook开源项目
7. NoHadoop时代，你需要了解Google  Percolator

微信公众号技术风向标，关注IT趋势，承载前沿、深入、有温度的内容。长按下方二维码加关注。

“ Josh Clemm是LinkedIn的高级工程经理，他写了一篇文章介绍LinkedIn针对用户规模急速扩大带来的架构方面的变革。自2003年创立至今，LinkedIn全球用户数已经从第一周的2700增长到了现在的超过3.5亿，它每秒都要提供成千上万的网页请求，移动端流量占了50%以上。所有这些请求都是从后台系统获取数据，而这个后台系统每秒需要处理数以百万计的查询。


那么问题来了，这些都是怎么做到的？
早年间—Leo刚开始的时候，LinedIn只有一台应用服务做了全部工作。这个应用名叫“Leo”，它包含了所有的Web Servlet，处理业务逻辑，同时连接一个轻量的LinkedIn数据库。
会员关系图作为一个社交网络，第一件事要做的就是管理会员之间的连接关系。需要一个系统，使用图遍历的方式查询连接数据，并且要常驻内存以保证效率和性能。同时，它还需要能够独立于Leo进行扩展。因此，他们为实现会员图创建了一个单独的系统Cloud。LinkedIn的第一个服务就此诞生。为了实现图服务与Leo的分离使用了Java RPC通信。


大约正是这个时候，产生了搜索功能需求。会员关系图服务开始为一个基于Lucene的搜索服务提供数据。
多个只读数据库副本随着站点的增长， Leo系统也在扩大， 也更加复杂。 通过负载均衡可以运行多个Leo实例，但是新增的负载也使LinkedIn最关键系统——会员信息数据库不堪重负。
一个最容易的解决方案就是垂直扩展——在其上增加更多的CPU和内存。这虽然可以支撑一段时间，但是将来还是会遇到规模扩展的问题。会员信息数据库既处理读又处理写。 为了扩展，引入了从属副本数据库。 复制数据库是会员数据库的一个拷贝， 使用 databus （现已开源）的早期版本保持同步。副本数据库负责处理所有的读请求， 并且增加了保证主库和从库数据一致性的逻辑。

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

Kill Leo这个咒语在内部传颂了很多年

面向服务的架构—SOA工程师开始抽取出一些微服务，这些微服务提供API和一些业务逻辑，接着表现层也被抽取出来，比如招聘产品和公共信息页。新产品新服务都独立于Leo。


还构建了前端服务器， 可以从不同的域获取数据，处理展示逻辑以及通过JSP生成HTML。还构建了中间层服务提供API接口访问数据模型以及提供数据库一致性访问后端数据服务。到2010年有超过150个独立的服务，如今，已经有超过750个服务。


至此已可以针对单个服务进行扩展。期间还构建了早期的配置和性能监控功能。缓存由于发展迅猛，LinkedIn需要进一步扩展，通过增加更多的缓存层来减少整体负载。比如，引入类似memcache或couchbase的中间层缓存，向数据层添加缓存，并在必要的时候使用Voldemort进行预计算。但随着时间推移，考虑到缓存失效增加了系统复杂性，而“调用图”难以管理，于是又去掉了许多中间层缓存，而只保留了离数据存储最近的缓存，在保证低延迟和横向扩展能力的同时，降低了可知的负载。

Kafka为了收集日益增长的数据量，LinkedIn开发了许多自定义的数据管道，用于对数据进行流式处理。例如，要让数据流入数据仓库，需要将数据批量发送给Hadoop工作流用于分析，需要收集和汇总每个服务的日志信息，等等。随着网站的发展，这样的自定义管道越来越多。

随着网站还在壮大，更多的定制管道出现。因此又基于提交日志的概念开发了一个分布式的发布订阅消息平台作为通用的数据管道，也就是Kafka。该平台支持对任何数据源的准实时访问，有效地支撑了Hadoop作业和实时分析，极大了提升了站点监控和预警功能，使我们可以可视化和跟踪调用图。现在，Kafka每天处理超过5千亿事件。




Inversion扩展可以从很多维度来衡量，包括组织结构的扩展。2011年底，LinkedIn启动一个名为Inversion的内部项目，暂停了所有的功能开发，整个工程组织全部致力于改进工具、部署基础设施和开发效率。
近几年—Rest.li当我们从Leo转向面向服务的架构后，之前抽取的基于Java RPC的API, 在各团队之间开始变得不一致了，和表现层耦合太紧。为此我们开发了一个新的API模型Rest.li. 这是一种以数据模型为中心的架构，可以确保整个公司使用同一个无状态的Restful API模型，而且非Java客户端也可以轻松地使用。这一措施不仅实现了API与展示层的解耦，而且解决了许多向后兼容的问题。


此外，借助动态发现（D2），他们还针对每个服务API实现了基于客户端的负载均衡、服务发现和扩展。现在，LinkedIn有超过975个Rest.li资源和每天超过1000亿次的Rest.li调用。


超块（Super Blocks）面向服务的架构可以解耦域及实现服务的独立扩展，但它也有缺点。Linkedin的许多应用程序都需要获取许多类型的不同数据，发起数以百计的调用。所有的调用就构成了上文提到的“调用图”。该调用图非常难以管理，而且管理难度越来越大。为此引入了“超块”的概念，为一组后端服务提供一个可以独立访问的API。这样就可以有一个专门的团队对块进行优化，并控制每个客户端的调用图。多数据中心不仅要避免单个服务成为单点故障点，而且要避免整个站点成为单点故障点，因此多数据中心非常重要。现在LinkedIn主要通过三个数据中心提供服务，并在全球范围内提供PoPs服务。






Linkedin的故事远不止这么简单。许多关键系统的背后都有一段丰富的历史，比如，会员图服务、搜索、通信平台、客户端模板等等。
推荐阅读 1. 分布式消息系统Apache Kafka那些事儿
2. 深入理解git，从研究.git目录开始
3. 艰难的重构：10大常见的重构误区 
4. 函数式编程，想说爱你不容易
5. 专访人工智能专家吴恩达：不必对AI心怀恐惧 
6. 15个你必须知道的Facebook开源项目
7. NoHadoop时代，你需要了解Google  Percolator

微信公众号技术风向标，关注IT趋势，承载前沿、深入、有温度的内容。长按下方二维码加关注。