LinkedIn 創(chuàng)建于 2003 年，主要目標(biāo)是連接你的個人人脈以得到更好的的工作機(jī)會。上線***周只有 2700 個會員，之后幾年，LinkedIn 的產(chǎn)品、會員、服務(wù)器負(fù)載都增長非常快。

今天，LinkedIn 全球用戶已經(jīng)超過 3.5 億。我們每天每秒有上萬個頁面被訪問，移動端流量已占到 50% 以上。所有這些接口請求都從后臺獲取，達(dá)到每秒上***。

那么，我們是怎么做到的呢？

早些年 – Leo

LinedIn 開始跟很多網(wǎng)站一樣，只有一臺應(yīng)用服務(wù)做了全部工作。這個應(yīng)用我們給它取名叫“Leo”。它包含了所有的網(wǎng)站頁面（JAVA Servlets），還包含了業(yè)務(wù)邏輯，同時連接了一個輕量的 LinkedIn 數(shù)據(jù)庫。

哈!早年網(wǎng)站的形態(tài)-簡單實(shí)用

會員圖表

***件要做的是管理會員與會員間的社交網(wǎng)絡(luò)。我們需要一個系統(tǒng)來圖形化遍歷用戶之間連接的數(shù)據(jù)，同時又駐留內(nèi)存以達(dá)到有效和高性能。從這個不同的需 求來看，很明顯我們需要可以獨(dú)立可擴(kuò)展的 Leo。一個獨(dú)立的會員圖示化系統(tǒng)，叫“云”的服務(wù)誕生了 – LinkedIn 的***個服務(wù)。為了讓圖表服務(wù)獨(dú)立于 Leo，我們使用了 Java RPC 用來通訊。

也大概在這期間我們也有搜索服務(wù)的需求了，同時會員圖表服務(wù)也在給搜索引擎-Lucene 提供數(shù)據(jù)。

復(fù)制只讀數(shù)據(jù)庫

當(dāng)站點(diǎn)繼續(xù)增長，Leo 也在增長，增加了角色和職責(zé)，同時自然也增加了復(fù)雜度。負(fù)載均衡的多實(shí)例 Leo 運(yùn)轉(zhuǎn)起來了。但新增的負(fù)載也影響了 LinkedIn 的其它關(guān)鍵系統(tǒng)，如會員信息數(shù)據(jù)庫。

一個通常的解決方案是做垂直擴(kuò)展 – 即增加更多的 CPU 和內(nèi)存！雖然換取了時間，但我們以后還要擴(kuò)展。會員信息數(shù)據(jù)庫受理了讀和寫請求，為了擴(kuò)展，一個復(fù)制的從數(shù)據(jù)庫出現(xiàn)了，這個復(fù)制從庫， 是會員主庫的一個拷貝，用早期的 databus 來保證數(shù)據(jù)的同步（現(xiàn)在開源了）。從庫接管了所有的讀請求，同時添加了保證從庫與主庫一致的邏輯。

當(dāng)主-從架構(gòu)工作了一段時間后，我們轉(zhuǎn)向了數(shù)據(jù)庫分區(qū)

當(dāng)網(wǎng)站開始看起來越來越多流量，我們的應(yīng)用服務(wù) Leo 在生產(chǎn)環(huán)境經(jīng)常宕機(jī)，排查和恢復(fù)都很困難，發(fā)布新代碼也很困難，高可用性對 LinkedIn 至關(guān)重要，很明顯我們要“干掉”Leo，然后把它拆分成多個小功能塊和無狀態(tài)服務(wù)。

面向服務(wù)的架構(gòu) – SOA

工程師從分解負(fù)擔(dān) API 接口和業(yè)務(wù)邏輯的微服務(wù)開始，如搜索、個人信息、通訊及群組平臺，然后是展示層分解，如招募功能和公共介紹頁。新產(chǎn)品和新服務(wù)都放在 Leo 之外了，不久，每個功能區(qū)的垂直服務(wù)棧完成了。

我們構(gòu)建了從不同域抓取數(shù)據(jù)模型的前端服務(wù)器，用于表現(xiàn)層展示，如生成 HTML（通過 JSPs）。我們還構(gòu)建了中間層服務(wù)提供 API 接口訪問數(shù)據(jù)模型及提供數(shù)據(jù)庫一致性訪問的后端數(shù)據(jù)服務(wù)。到 2010 年，我們已經(jīng)有超過 150 個單獨(dú)的服務(wù)，今天，我們已經(jīng)有超過 750 個服務(wù)。

因?yàn)闊o狀態(tài)，可以直接堆疊新服務(wù)實(shí)例及用硬件負(fù)載均衡實(shí)現(xiàn)擴(kuò)展。我們給每個服務(wù)都畫了警戒紅線，以便知道它的負(fù)載，從而制定早期對策和性能監(jiān)控。

緩存

LinkedIn 可預(yù)見的增長，所以還需要進(jìn)一步擴(kuò)展。我們知道通過添加更多緩存可以減少集中壓力的訪問。很多應(yīng)用開始使用如 memcached/couchbase 的中間層緩存，同時在數(shù)據(jù)層也加了緩存，某些場景開始使用 useVoldemort 提供預(yù)結(jié)果生成。

又過一了段時間，我們實(shí)際上去掉了很多中間層緩存，中間層緩存數(shù)據(jù)往往來自多個域，但緩存只是開始時對減少負(fù)載有用，但更新緩存的復(fù)雜度和生成圖表變得更難于把控。保持緩存最接近數(shù)據(jù)層將降低潛在的不可控影響，同時還允許水平擴(kuò)展，降低分析的負(fù)載。

Kafka

為了收集不斷增長的數(shù)據(jù)，LinkedIn 開始了很多自定義的數(shù)據(jù)管道來流化和隊(duì)列化數(shù)據(jù)，例如，我們需要把數(shù)據(jù)保存到數(shù)據(jù)倉庫、我們需要發(fā)送批量數(shù)據(jù)到 Hadoop 工作流以分析、我們從每個服務(wù)聚合了大量日志、我們跟蹤了很多用戶行為，如頁面點(diǎn)擊、我們需要隊(duì)例化 InMail 消息服務(wù)、我們要保障當(dāng)用戶更新個人資料后搜索的數(shù)據(jù)是***的等等。

當(dāng)站點(diǎn)還在增長，更多定制化管道服務(wù)出現(xiàn)了，因網(wǎng)站需要可擴(kuò)展，單獨(dú)的管道也要可擴(kuò)展，有些時候很難取舍。解決方案是使用 kafka，我們的分布式發(fā)布-訂閱消息平臺。Kafka 成為一個統(tǒng)一的管道服務(wù)，根據(jù)提交的日志生成摘要，同時一開始就很快速和具有可擴(kuò)展性。它可以接近于實(shí)時的訪問所有數(shù)據(jù)源，驅(qū)動了 Hadoop 任務(wù)，允許我們構(gòu)建實(shí)時的分析，廣泛的提升了我們站點(diǎn)監(jiān)控和告警的能力，同時支持將調(diào)用可視化。今天，Kafka 每天處理超過 5 億個事件。

反轉(zhuǎn)

擴(kuò)展可從多個維度來衡量，包括組織結(jié)構(gòu)。2011 年晚些時候，LinkedIn 內(nèi)部開始一個創(chuàng)新，叫”反轉(zhuǎn)”（Inversion）。我們暫停了新功能開發(fā)，允許所有的開發(fā)部門集中注意力提升工具和布署、基礎(chǔ)架構(gòu)及實(shí)用性開發(fā)。這對 于今天敏捷開發(fā)新的可擴(kuò)展性產(chǎn)品很有幫助。

近幾年 – Rest.li

當(dāng)我們從 Leao 轉(zhuǎn)向面向服務(wù)的架構(gòu)后，之前基于 JAVA 的 RPC 接口，在團(tuán)隊(duì)中已經(jīng)開始分裂了，并且跟表現(xiàn)層綁得太死，這，只會變得更壞。為了搞定這個問題，我們開發(fā)了一套新的 API 模型，叫 Rest.li，它是一套以數(shù)據(jù)為中心的架構(gòu)，同時保證在整個公司業(yè)務(wù)的數(shù)據(jù)一致性且無狀態(tài)的 Restful API。

基于 HTTP 的 JSON 數(shù)據(jù)傳遞，我們新的 API 最終很容易支持到非 java 編寫的客戶端，LinkedIn 今天依然主要用 Java，但同時根據(jù)已有的技術(shù)分布也利用了 Python、Ruby、Node.js 和C++。脫離了 RPC，同時也讓我們從前端表現(xiàn)層及后端兼容問題解耦，另外， 使用了基于動態(tài)發(fā)現(xiàn)技術(shù)（D2）的 Rest.li，我們每個服務(wù)層 API 獲得了自動負(fù)載均衡、發(fā)現(xiàn)和擴(kuò)展的能力。

今天，LinkedIn 所有數(shù)據(jù)中心每天已經(jīng)有超過 975 個 Rest.li 資源和超過千億級 Rest.li 調(diào)用。

Rest.li R2/D2 技術(shù)棧

超級塊

面向服務(wù)的架構(gòu)對于域解耦和服務(wù)獨(dú)立擴(kuò)展性很有幫助，但弊端是，大都我們的應(yīng)用都需要很多不同類型的數(shù)據(jù)，按序會產(chǎn)品數(shù)百個延伸的調(diào)用。這就是通常 說的“調(diào)用線路圖”，或伴隨著這么多延伸調(diào)用的“扇出”（fan-out）。例如，任何個人信息頁都包含了遠(yuǎn)不止于相冊、連接、群組、訂閱、關(guān)注、博客、 人脈維度、推薦這些。調(diào)用圖表可能會很難管理，而且只會把事件搞得越來越不規(guī)則。

我們使用了”超級塊”的概念 – 一個只有單一 API 接口的群組化后臺服務(wù)。這樣可以允許一個小組去優(yōu)化一個“塊”，同時保證每個客戶端的調(diào)用情況可控。

多數(shù)據(jù)中心

作為一個會員快速增長的全球化公司，我們需要將數(shù)據(jù)中心進(jìn)行擴(kuò)展，我們努力了幾年來解決這個問題，首先，從兩個數(shù)據(jù)中心（洛杉磯和芝加哥）提供了公 共個人信息，這表明，我們已經(jīng)可以提供增強(qiáng)的服務(wù)用來數(shù)據(jù)復(fù)制、不同源的遠(yuǎn)程調(diào)用、單獨(dú)數(shù)據(jù)復(fù)制事件、將用戶分配到地理位置更近的數(shù)據(jù)中心。

我們大多的數(shù)據(jù)庫運(yùn)行在 Espresso（一個新的內(nèi)部多用戶數(shù)據(jù)倉庫）。Espresso 支持多個數(shù)據(jù)中心，提供了主-主的支持，及支持復(fù)雜的數(shù)據(jù)復(fù)制。

多個數(shù)據(jù)中心對于高可用性具有不可思議的重要性，你要避免因單點(diǎn)故障不僅只導(dǎo)致某個服務(wù)失效，更要擔(dān)心整個站點(diǎn)失效。今天，LinkedIn 運(yùn)行了 3 個主數(shù)據(jù)中心，同時還有全球化的 PoPs 服務(wù)。

我們還做了哪些工作？

當(dāng)然，我們的擴(kuò)展故事永遠(yuǎn)不止這么簡單。我們的工程師和運(yùn)維團(tuán)隊(duì)這些年做了不計其數(shù)的工作，主要包括這些大的初創(chuàng)性的：

這些年大多關(guān)鍵系統(tǒng)都有自己的豐富的擴(kuò)展演化歷史，包括會員圖表服務(wù)（Leo 之外的***個服務(wù)），搜索（第二個服務(wù)），新聞種子，通訊平臺及會員資料后臺。

我們還構(gòu)建了數(shù)據(jù)基礎(chǔ)平臺支持很長一段時間的增長，這是 Databus 和 Kafka 的***次實(shí)戰(zhàn)，后來用 Samza 做數(shù)據(jù)流服務(wù)，Espresso 和 Voldemort 作存儲解決方案，Pinot 用來分析系統(tǒng)，以及其它自定義解決方案。另外，我們的工具也進(jìn)步了，如工程師可自動化布署這些基礎(chǔ)架構(gòu)。

我們還使用 Hadoop 和 Voldemort 數(shù)據(jù)開發(fā)了大量的離線工作流，用以智能分析，如“你可能認(rèn)識的人”，“相似經(jīng)歷”，“感覺興趣的校友”及“個人簡歷瀏覽地圖”。

我們重新考慮了前端的方法，加了客戶端模板到混合頁面（個人中心、我的大學(xué)頁面），這樣應(yīng)用可以更加可交互，只要請求 JSON 或部分 JSON 數(shù)據(jù)。還有，模板頁面通過 CDN 和瀏覽器緩存。我們也開始使用了 BigPipe 和 Play 框架，把我們的模型從線程化的服務(wù)器變成非阻塞異步的。

在代碼之外，我們使用了 Apache 的多層代理和用 HAProxy 做負(fù)載均衡，數(shù)據(jù)中心，安全，智能路由，服務(wù)端渲染，等等。

***，我們繼續(xù)提升服務(wù)器的性能，包含優(yōu)化硬件，內(nèi)存和系統(tǒng)的高級優(yōu)化，利用新的 JRE。

下一步是什么

LinkedIn 今天仍在快速增長，仍然有大量值得提升的工作要做，我們正在解決一些問題，看起來只解決了一部分 – 快來加入我們吧！