深入了解開源軟體駐紮地 Github

有時候處理規模問題最好的辦法就是讓事情變得簡單并盡你可能去避免出現這種情況。這是 github 所采用的方法，林納斯·托瓦茲（linus torvalds）在十年前開發了git源代碼控制工具，github 為該工具提供資料庫服務（repository service），目前已經有了爆炸性的發展，并成為開源軟體開發工作的重心之一。

可以了解為什麼程式員們會精挑細選他們創作代碼用的工具并與他人分享，反過來，他們也會去調整和改進這些工具。一種非常現實的感覺就是，軟體開發者們“住進”這些系統中後，源代碼版本控制系統的工作方式會對合作者們的創作過程提供積極或消極的影響。

github 的成立可以追溯到2007年，它的建立者包括目前公司的首席營運官（coo，chief operating officer）pj hyett，首席執行官（ceo，chief executive officer）chris wanstrath，前首席執行官tom preston-werner，首席資訊官（cio，chief information officer）scott chacon。這些人當時都在 rails 架構下開發 ruby 應用程式，并希望通過一個更好的方式合作編碼，為此他們開始搭建了預計在2008年開始運作的 github。與其說這是一個商業計劃，他們的開發更多是為了能有一個工具幫助他們自動化地協助自己的軟體開發工作。

“基本上它就是一個簡單的棧，對我們來說它真的很重要，“lambert 說。“我們試圖采用盡可能少的東西來保持這個棧的簡單”。

另一方面，2008 年是創業公司的一個分界線（兩年後 amason web service 釋出了 ec2 計算雲），github 可以使用雲，第一次不需要在基礎建設上做投資。但是，沒有那麼做，公司創始人和他們聘請的工程師已經繪制了技術棧草圖，通過聊天工具見獵購買了一系列創造性的系統管理，軟體布署工具，基本的 it 操作都在 github 上運作。

當然，公司在 github 上有自己的私有倉庫來開發 github。雖然 lambert 沒有透露這個構成 github 的 ruby 應用的具體大小，但是他告訴我們這個平台在 github 的倉庫裡有25萬個 commit，有上百人貢獻了他們的代碼和送出這些變動的 commit，盡管不是所有人都在 github 工作。

“github 最初是為我們自己建立的，我們基本上都是軟體工程師是以我們想要一個好的工具做開發。”，lambert 如是說道，“我們使用 github 去建構 github，同時這也是我們每天去管理所有事物的東西。人力資源和法律團隊在他們的工作流程上也在使用 github。不僅僅隻是程式員在使用 github。我們非常幸運能夠用其他公司不一定能做的方式完成了我們的代碼。如果你招一些開發者為廣告系統做開發，除非他們根本不在乎讨不讨厭廣告，否則他們是不會願意幹的。而我們所有的開發人員都喜歡git并且所有的工作都圍繞着它，是以我們有為我們每天使用的工具而工作的特殊待遇。 ”

github 棧的底端是硬體，它由幾百台分布在各地資料中心的x86伺服器組成。(github 沒有透露這些伺服器位于何處，但 lambert 确實說過，由于全球使用者基數增長，github 正在考慮在全球其他地區建立資料中心。)

“我們使用标準供應商的現成機器，” lambert 說道, 但沒有提及供應商的名字和配置. “我們對軟體運作做了很多優化，但針對硬體我們并沒有做不合适的大規模定制化。随着規模變大，我們試圖讓軟體容錯性更好，并且将資料拷貝到一次性機器上，這樣我們就用不着維修機器了。你隻需要毀掉它，重新将資料放到另一台機器上。這會讓購買機器變得便宜，同時擴充的成本也更低。”

硬體明顯沒有那麼有趣 ——尤其對于軟體工程師來說。但是 lambert 尤其對自家開發的部署系統 gpanel 感到興奮，它用 ruby 開發，挂鈎到 puppet 配置工具，讓公司裡的任何人都可以準備機器并在上面釋出軟體。

“這讓我們像在公有雲上一樣部署軟體，卻又允許我們享受擁有自己的硬體的所有好處。”

github 的軟體基礎當然是 linux，lambert 也說過公司當然有足夠的專家來運轉自己的 linux。但它沒有這麼做，而是簡單地使用 canonical ubuntu 分布式伺服器。至于存儲 git 代碼和 github 代碼倉庫通路控制系統的其他部分的資料庫，github 依賴 mysql 關系資料庫。github 自己維護 linux 和 mysql 軟體，以及 ruby 和 rails。github 聘用了 ruby 和 rails 社群的主要維護者，是以可以推論，github 在社群做自己的技術支援。但事實上随着應用的規模擴大，github 同時擁有自定義版本的 ruby 和 rails。

"當資料來臨時，對我們來說真的是規模問題，我們正在使用一個高可用的方式彈性存儲資料，"lambert 說道，"它是關于适應 git 具有可擴充性和易用性，因為它從來沒有考慮過這一點。我們測量，github 是最大的 ruby on rails 程式之一 - 許多公司都沒有大規模的運作 ruby。我們保持精益，做優化，以保持這種方式。

我們現階段不完全，不像 facebook 的 hiphop 和 facebook 用 php 做什麼，但我們有人民奉獻 ruby 的核心，使其更快和精益。"

github 調整了 ruby 解釋器，并創立了自己的垃圾收集例程，但它也熱衷于定位 ruby 和 rails 的錯誤盡可能快和擷取代碼修複到 github 上，應用程式，以及輸出到 ruby 和 rails 社群。 （ ruby 開發托管在 github 上，因為這樣是為了 rails。mysql 的開發剛搬過來不久，用了甲骨文一些時間來做到這一點。）

github 可能是開發者的機器，用于瘋狂的 fork 代碼 - 好，瘋狂的 fork 代碼至少 - 讓 github 費力也不以為奇。蘭伯特解釋道：

"我們保持 github 作為一個 ruby on rails 應用程式的原因是，它是非常容易和快速的學會。人們在該公司第一天上班就開始在 github上 工作了。我們真的很需要一個的定制的和與衆不同的建構，因為如果我們這樣做，我們将失去了所有社群所帶來的好處。這就是告訴我們的資料庫選擇，因為 mysql是每個人都在使用的。如果你遇到 mysql 的問題，它是已知的，你不會遇到晦澀難懂并且沒人知道的錯誤資訊。沒有找不到答案的奇怪錯誤，因為你遇到的問題，有人已經遇到過"。

github 的基礎設施有 web 伺服器，代理伺服器，認證伺服器，和一堆執行有關倉庫的分析、上傳送出分析、數百萬托管項目分析的系統，但真正核心是存儲庫本身。大多數這類資料是文本，當然，這不會占用很大的空間，相比一些更豐富照片，視訊和音頻媒體更能充塞網際網路後面的磁盤驅動器。

奇怪的是，github 沒有使用傳統的資料壓縮方式壓縮文本資料，但它有自己的壓縮方式來節省空間。如果一個項目被 fork，隻在 fork 中儲存對原來的更改。 （我們假定這個方法也可以讓你輕松地找出變化，在每一個 fork 中疊代。）如果 github 上儲存每一個變化，每一個 fork，它會很快有數不清的pb級資料，傳統的資料壓縮會系統變慢。事實證明，即使每天從程式員接受數百 gb 位元組的新資料，整個 github 的資源庫的大小也是被度量在數百 tb 級。

在某些時候，在網際網路上有很多貓的照片，所有貓的照片來自 master 貓的照片，并根據變化方式存儲在 fork 中 （譯者注：這裡做個比喻，形容 github 的 fork 隻存儲與 fork 之前的差别）

（我們有點開玩笑。）

“有很多公司說他們已經到達 tb 和 pb 級的資料，你問他們那都是些什麼資料，它們通常隻是垃圾，” lambert 笑着說。“大多大資料公司僅僅用來存儲事件 —— 這些基本上都是沒用的。我們非常自豪于我們一直保持着精益和優化，我們不會存儲大量無用的資料。相對于我們的競争對手，存儲到倉庫的比率顯示了我們非常非常地精益。我們盡可能不去存儲資料，因為我們有一些非常智能的東西在後端讓我們保持松散和分叉。我們有很多 git，但我們還是會盡我們所能去優化。”

回顧 github 的發展經曆，從公司到老舊的學校，都可以快速簡單地擷取指定的存儲和計算能力并啟動它們。

"我們總是領先一步，我不能說是壓力驅使，但我們确實有壓力“lambert 沒有具體說明叢集是如何快速發展的。“我們每天有數百 g 的新資料，并且倉庫的使用規模快速增長，但我們建立了基礎設施，可以和業務增長保持同步擴充”，這是因為我們的計劃做得很好，現在也沒有變慢的迹象。“

如果 github 像其他 hyperscaler 一樣，它的基礎設施發展會滞後于推動基礎設施的因素發展。很難去擴充服務，存儲和使用者，這也是為什麼在 hyperscaler 有這麼多的工程創造力。

使用公共的 github 倉庫是免費的，但是上面的代碼可以被任何感興趣的人擷取和 fork。github 有償提供私有倉庫，這是它計劃盈利的方式。價格從 7 美元每個月的包含 5 個私有倉庫的個人計劃到200美元的程式員團隊可共享 125 個私有倉庫的商業計劃。對于那些需要在内部搭建 github 來開發代碼的公司，可以購買 github enterprise 授權，售價 2,500 美元，每年可安裝 10 個主機，并且跟 github 有同樣的外觀。github enterprise 可以在内部主機上搭建，也可以搭建在 amazon web services 或者 microsoft azure 公有雲上。目前 github 和 github enterprise 由同一個支援團隊維護，但是如果你要在 github enterprise 上做内部開發并想開源到 github，沒有自動化的方式來完成。但 lambert 表示存在空間。

除了核心ruby on rails應用程式和存儲算法把git中的代碼存放到檔案伺服器，github也正在工作于其它應用上。 "有些技術你隻是沒有把它下架，因為世界上我們是最大的代碼托管商，我們有很多定制領域的問題，" lambert說。

向前發展的其中一個重點領域是，提供了一組更豐富的關于程式員的項目分析和工作分析，因為很多公司都在使用開源軟體，以此來吸引人才。這就是為什麼github将擴充到新的市場，有很多變化的文檔和fork是協作過程的一部分。就像github裡面的團隊一樣，使用該工具來跟蹤項目，架構師，音樂家和其他工匠開始使用該工具，這可能為github提供了另一波增長。

github 在 2012 年的 7 月第一輪風險融，從 andressen horowitz 那裡資籌集了 1 億美元，和今年 7 月的第二輪融資，從紅杉資本和 andreessen horowitz，thrive capital 和 institutional venture partners 籌集了另外 2.5 億美元,該公司尚未公開，但鑒于其融資的估值約為 20 億美元，和現金增長其基礎,并擴大它的目标市場。

github 的一個重要創新，嚴格的講，不是代碼部分,但絕對是公司 hubot 的一部分，這是公司使用的一個聊天機器人系統管理接口。這種方法通常被稱為 chatops，給部署操作起别名，通過聊天機器人，用聊天的方式做 devops。在 github 裡一切都使用它。

它成立後不久後，github 的建立了一個名為 hubot 聊天機器人，它內建了 gpanel 和其他系統管理工具以及公司裡使用的其他功能。事實證明，在 github 上有 65％ 的員工，325 人遠端工作。是以，會議或教育訓練會議在辦公室裡是不會發生的。是以 hubot 就是執行的一切，每個人都可以看到别人都在做的事情。（etsy 的和 box 現在已經使用了 hubot。）

"這種文化，你将會錯過，我們已經圍繞着我們的聊天室裡工作，"蘭伯特說。 "這是一個引人入勝的方式。當我第一次開始使用它時，我們沒有任何的訓練。我剛走進聊天室，觀察着。聊天機器人為我們提供了立即回複。在很多公司，當人們做出更改，他們得來到自己的公司電腦前，來解釋他們都更改了什麼，這真的是笨方法。在這裡，如果你做出了更改，你直入聊天室，每個人都在那工作。我們所有的人都通過聊天機器人發送指令，每個人都可以看到它，基本上，你什麼都能做。我們是率先推出這種工作方式的公司之一，它越來越多被采用。它使我們能夠進行極其分布式和異步工作，而無需任何人走進辦公室"。

這就像我們數百萬的 github 使用者一樣。