Aditya Agarwal：Facebook 技術規模化的4個秘密

導語前的導語：

之前發的 Larry Page 的長文反響格外好，在此謝謝大家。我們未來還會努力提供些好內容，包括，好故事。

好故事當然是「創業」這個母題的一部分，但我們也不會忽略一些「硬」的東西。今天的這篇文章，是技術向的一點趣味。

我們曾經也推薦過一些技術向的文章，內容倒是不錯，只是作為一個沒什麼技術功底的人，每次寫導語的時候我都痛不欲生...於是這次我們找來「墨軌跡」的聯合創始人和 CTO 沈曉龍來客串，介紹一下這篇文章的作者和內容。

當然，看不懂你也不用硬撐，直接發給你身邊的工程師吧...

客座導語@沈曉龍：

這篇文章的作者 Aditya Agarwal, 也許並不過多的出現在任何一個創業的頻道里。並不是因為他不輸出方法論，而是他的方法論更多的應用在了一個相對難以理解的領域: Scale Engieering.

思來想去，所以對他的介紹，總讓語文不好的我手足無措...

從Oracle出來，他在 Facebook 有15人的時候加入，幾乎一個人完成了 Facebook 最初的搜索引擎。2011年從 Facebook 離開，他做了一個協同平台 Cove 並被 Dropbox 收購，之後他作為 Dropbox 的 Engineering VP 再一次出現在公眾面前。Aditya Agarwal 還參與投資了許多公司，包括天天管理我工作的 Asana，和以教編程為由常介紹給各色姑娘的 Codecademy...

其實談到 scale engineering，如今風生水起的招聘市場告訴著我們，創業公司在拓展自己工程開發能力的過程中的第一道坎是——找到性價比高的人，或者在如今的創業市場，更多的是找到性價比高的工程師。而風風火火地招完人回來，做著夢覺得這樣我們就可以10X速的迭代產品，就可以快速佔領市場擁有用戶，就可以融起ABCD輪然後IPO了。然後回過頭髮現，也許每個人都在貢獻代碼，但是調試的周期變長了，溝通的成本變高了，為什麼有人忙瘋了有人卻天天按時上下班了。或者，開始陷入無休止的掙扎，糾結於我們用A架構還是B架構去迎接未來也許出現井噴的業務需求和用戶量，用C語言還是D語言去進行開發來保證效率和維護性的平衡。而這，恰恰是 scale engineering 的過程中不得不經歷的痛。於是這個市場開始從搶工程師走向了搶CTO...但這真的理性么？

2010年的 Aditya Agarwal 已經成為 Facebook 的 Director of Product Engineering，最多帶領過2000人的團隊，服務著近7億用戶。而同為CMU畢業的我，實在是......更讓人感慨的是，無論在多麼細分領域內的探討，最終是術無窮而道有盡。就好像文章里所說：

You can get the code right, you can get the products right, but you need to get the culture right first. If you dont get the culture right, your company wont scale.

The Four Meta Secrets Of Scaling At Facebook

作者：General Chicken

翻譯：愛小逗逗的@Fish

原文鏈接：The Four Meta Secrets of Scaling at Facebook

Facebook 的技術主管 Aditya Agarwal 發表了一篇關於 Facebook 規模化的演講，這篇演講講述了 Facebook 的體系結構，但是它更多的談及如何通過保存公司文化中最優異的部分來實現規模化。這篇演講的精華部分如下：

你可以寫出好的代碼，你可以做出好的產品，但是你需要先建立好的公司文化。如果你的公司文化不對，你的公司無法實現規模化。

這就引出了 Facebook 規模化的4個秘密：

1. 規模化需要迭代；

2. 不要過度設計；

3. 選擇正確的工具，但要注意你選擇帶來的管理成本；

4. 建立正確的文化。快速行動，破舊立新（Move fast, break things）；大的影響力，小的團隊（Huge Impact, small teams）；勇敢，創新（Be bold, innovate）。

一些背景

• Facebook 很大：它擁有4億活躍用戶；用戶每天平均花20分鐘用 Facebook；每周 Facebook 上分享50億個板塊（狀態更新，評論，點贊，照片上傳，視頻上傳，聊天，收件箱，群組事件，粉絲界面，朋友聯絡）；每月上傳30億照片；每個月有250個應用的用戶超過100萬用戶；8萬個連接應用程序，50萬個應用程序；200萬開發人員；每秒鐘1.5億緩存操作；上千台擁有數十T內存的緩存伺服器；300名開發人員。

• Facebook 的規模化很難。每個版塊都有它自己的訪問模式而導致規模化很難實現。每個人都以不同方式使用 Facebook。每一個體驗都是獨一無二的。大多數網頁都是通過增加伺服器來實現規模化的，因為它們的數據可以被分割，這是水平式規模化。但是，因為 Facebook 的用戶可以訪問任意的網路，所以用戶不能被分割。它是一個全球化的網路，讓全球每個人都能使用，它讓每個人都可以加其他人為好友，用戶間可以呈現任何關係。任何新的用戶能夠訪問其他用戶的數據，這意味著不可能從地理上或其他方式來分割用戶。Facebook 的每個用戶平均有130個好友，沒有其他方法來分割這些數據，所以訪問只在一個群集。

• 總體系有5個主要部分：負載均衡器，網路伺服器（用PHP寫的），服務（快捷、複雜、搜索、廣告、劃線器），緩存（快速、簡單），資料庫（緩慢、持久）。

四個秘密（ Four meta secrets）

1. 規模化需要迭代。大部分解決方案在最初的時候可行，但是你需要隨時調整。在第一年適用的方法以後不一定適用。比如說，PHP 在最初是很容易使用的，但是當你有成千上萬的網路伺服器時，它並不是一個好的選擇。

另一個例子是照片。目前它們一秒鐘可處理120萬張照片。最初是用很簡單的方式建立的，不需要擔心大量規模化，只需要專註在功能的運行上不出錯。主頁上傳的文件存儲在 NFS，元數據存貯在 MySQL（資料庫系統）。最初的3個月能正常運作，之後就問題不斷。他今天或許仍會這麼做。上市的時間是他們最大的競爭優勢。比起確認它有個可行的規模化解決方案，具備功能更為重要。

第二階段是優化。是否有不同的優化路徑的方式？事實證明訪問最頻繁的是小的圖片，所以這些已經緩存過了。他們也開始使用CDN（內容傳遞網路）。NFS 不是用來存儲800億小的文件，所以所有的元數據不能存入內存中，因此需要2到3個磁碟操作系統來查找，這顯然很慢。

第三階段是覆蓋系統，它創建了一個可以存儲在文件系統的整體文件。圖像存儲在整體文件中，你知道圖片的在整體文件中的偏移量。每張照片一個IO。

2. 不要過度設計。當你的系統在規模化時，只使用你需要使用的。要明白迭代中你解決問題需要的東西，優化它，或者自己完整地創建出它的一部分。他們花了很多時間試圖優化 PHP，最後編寫了HipHop，一種將PHP語言轉化成 C++ 語言的代碼。它減少了大量的內存和 CPU（中央處理器）。你不需要第一天就這麼做，但是你將來可能需要這麼做。在你開始寫一項新的語言之前，專註在產品上。

3. 選擇正確的工具，但要注意你選擇帶來的代價。如果你真的要使用 Python，那麼盡情去做吧，我們會幫助你成功。意識到這個選擇伴隨著的代價，通常在資源配置、監測、操作等等。

如果你選擇使用服務體系結構，那麼你需要自己創建後端的大部分工作，這會花費你大量的時間。但是用 LAMP （Linux、Apache、MySQL 和 PHP）堆棧，大部分你可以免費獲得。一旦你不使用LAMP堆棧，將由你來決定如何操作例如伺服器構架和監測。當你更深入服務方法，你不得不做無謂的重複勞動。

4. 建立正確的文化。快速行動——破舊立新。大的影響力 ——小的團隊。勇敢——創新。建立好的內部環境有助於一開始就把事情做對，只有在需要時才調整，不需要去擔心創新，不需要擔心破舊立新，從大處著眼，在做第一步的時候就想好你下一步要做的是什麼。你可以寫出正確的代碼，你可以做出正確的產品，這些都基於你要一開始建立正確的文化。如果文化不對，你的公司無法規模化。

1）快速行動。先投入市場。破舊立新很正常的。比如，你現在運行他們整個 HipHop 網路層，它是由3個人開發的。這非常有風險，它會經常導致你的網站出問題（內存不足、無限循環），想出辦法來讓它運行是需要很大的代價的。備選方法可能是花3個月時間來做每個改變的測試過程，但它讓每件事都變慢。這是一個特有的例子，但是最重要的是文化，讓人們相信最重要的是他們能多快地行動。

2）大的影響力。小的團隊可以做很偉大的事情。搜索、圖片、聊天及 HipHop 都是由小的團隊做出主要的特性。招募正確的人，授權，然後放手讓他們做。

3）勇敢。不要害怕失敗。嘗試，然後失敗，這再正常不過了。想要做一個新的 JVM 或許很瘋狂，但是如果萬一成功了會多牛啊。

在 Facebook 並沒有所謂的產品的擁有者。每個人都擁有這個產品。你應該賦予人們他們所做之事的所有權（ownership）。如果你把所有權給一個人，那麼其他人不會推動它進一步發展。好的想法來源於內部用戶。如果你不把責任下放，你孤立了那些自認為是所有者的用戶，那麼你唯一能激勵的人就是那些認為自己是所有者的人。因此，為什麼不把整個責任下放呢？

保護那部分你珍視並且想保留的文化。它不會自發地出現。Facebook 組織編程馬拉松，它的意義是告訴新的工程師如果他們早上8點過來，他們能在12個小時內讓一個新的功能上線。「快速行動」不僅僅是陳詞濫調，公司要想辦法讓員工相信，它是真實存在的。