近几年

## Rest.li 当我们从Leao转向面向服务的架构后，之前抽取的基于Java RPC的API, 在团队中开始变得不一致了，和表现层耦合太紧，这只会变得更糟。为了解决这个问题， 我们开发了一个新的API模型，叫做 [Rest.li](http://engineering.linkedin.com/architecture/restli-restful-service-architecture-scale). Rest.li 符合我们面向数据模型的架构， 确保在整个公司提供一致性的无状态的Restful API模型。 基于HTTP的JSON数据， 我们新的API最终很容易地编写非Java的客户端。 LinkedIn今天仍然主要使用Java栈，但是也有很多使用Python, Ruby, Node.js 和 C++的客户端，可能是自己开发的或者收购过来的。 脱离了RPC也让我们将变现层和后端兼容型的问题中挣脱出来。另外， 使用Dynamic Discovery (D2)的Rest.li, 我们可以得到自动的基于负载均衡，服务发现和可扩展的API客户端。 今天， LinkedIn有975 个Rest.li资源， 所有的数据中心每天有超过一千亿级Rest.li调用。 [](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-07-30_55b9e3a7c00ab.png "Rest.li R2/D2 技术站")Rest.li R2/D2 技术站 ## Super Blocks (超级块) 面向服务的架构很好的解耦了域之间的联系和可以独立地扩展服务。但是也有缺点， 很多应用获取各种类型的不同的数据， f(call graph)或者叫做"扇出" (fanout)。例如， 任意一次个人信息页的请求就会获取照片，会员关系， 组，订阅信息， 关注，博客，人脉，推荐等信息。 这个调用图很难管理，而且越来越难控制。 我们引入了超级块的概念。 为一组后台服务提供一个单一的访问API。这样我们就可以有一个team专门优化这个块，同时保证每个客户端的调用图可控。 ## Multi-Data Center (多数据中心) 作为一个会员快速增长的全球化公司，我们需要从一个数据中心进行扩展，我们通过几年的努力来解决这个问题，首先，从两个数据中心（洛杉矶 和 芝加哥）提供了公共个人信息，证明可行后，我们开始增强服务来处理数据复制、不同源的调用、单向数据复制事件、将用户分配到地理位置更近的数据中心。 我们大多的数据库运行在[Espresso](http://engineering.linkedin.com/espresso/introducing-espresso-linkedins-hot-new-distributed-document-store)（一个新的内部多用户数据仓库）上。 Espresso支持多个数据中心，提供了 主-主 的支持，及支持很难的数据复制。 多个数据中心对于高可用性具有不可思议的重要性，你要避免的单点故障不仅仅是某个服务失效，更要担心整个站点失效。今天，LinkedIn运行了3个主数据中心，同时还有全球化的[PoPs](http://engineering.linkedin.com/performance/how-linkedin-used-pops-and-rum-make-dynamic-content-download-25-faster)服务。 [](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2015-07-30_55b9e3aa5e1af.png "LinkedIn's operational setup as of 2015 (circles represent data centers, diamonds represent PoPs)")LinkedIn's operational setup as of 2015 (circles represent data centers, diamonds represent PoPs) ## 我们还做了哪些工作？ 当然，我们的扩展故事永远不会这么简单。我们的工程和运维团队这些年做了不计其数的工作，主要包括这些大的创新： 这些年很多最关键系统都有自己丰富的扩展演化历史，包括会员图服务（Leo之外的第一个服务），搜索（第二个服务），新闻种子，通讯平台及会员信息后台。 我们还构建了数据基础平台支持长期的增长，这是Databus和Kafka的第一次实战，后来用Samza做数据流服务，Espresso和Voldemort作存储解决方案，Pinot用来分析系统，以及其它自定义解决方案。另外，我们的工具也得到了提升，这样工程师就可以自动化布署这些基础架构。 我们还使用Hadoop和Voldemort数据开发了大量的离线工作流，用以智能分析，如“你可能认识的人”，“相似经历”，“感觉兴趣的校友”及“个人简历浏览地图”。 我们重新考虑了前端的实现，增加客户端模板到混合页面（个人中心、我的大学页面），这样应用可以更加可交互，只要我们的服务器发送JSON或部分JSON数据。此外，模板页面通过CDN和浏览器缓存。我们也开始使用了BigPipe和Play框架，把我们的模型从线程化的服务器变成非阻塞异步的服务器。 除了代码，我们使用了Apache Traffic Server做多层代理和用HAProxy做负载均衡，数据中心，安全，智能路由，服务端渲染等等。 最后，我们继续提升服务器的性能，包含优化硬件，内存和系统的高级优化，使用更新的JRE。 ## 下一步 LinkedIn今天仍在快速增长，仍有大量值得提升的工作要做，我们正在解决一些问题，看起来只解决了一部分 - [快来加入我们吧！](https://www.linkedin.com/company/linkedin/careers?trk=eng-blog) 感谢Steve, Swee, Venkat, Eran, Ram, Brandon, Mammad, 和 Nick的审阅和帮助