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。與其說這是一個商業計劃，他們的開發更多是為了能有一個工具幫助他們自動化地協助自己的軟體開發工作。

事實證明，GitHub 是世界上最大的 Ruby on Rails 應用程式，GitHub 系統主管 reckons Sam Lambert 曾和 The Platform（譯者：一家網站 http://www.theplatform.net/）就該系統做過一次小的討論。Lambert  不方便公開討論 GitHub 有多少行程式碼構成，沒有公司公佈有多少行程式碼託管在 GitHub 倉庫，但 Lambert 確實給我了們一些指標資料，這些資料是關於 GitHub 的使用增長情況，以及系統如何支撐為大約 60000 個機構或個人工作的 1000 萬個程式設計師維護 2600 萬個開源專案。

“基本上它就是一個簡單的棧，對我們來說它真的很重要，“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 說道,  但沒有提及供應商的名字和配置. “我們對軟體執行做了很多優化，但針對硬體我們並沒有做不合適的大規模定製化。隨著規模變大，我們試圖讓軟體容錯性更好，並且將資料拷貝到一次性機器上，這樣我們就用不著維修機器了。你只需要毀掉它，重新將資料放到另一臺機器上。這會讓購買機器變得便宜，同時擴充套件的成本也更低。”

“我們確實需要構建定製化和非比尋常的東西，因為一旦我們做了，我們就失去了社群正在做的東西的好處。這也告訴了我們怎麼選擇資料庫，因為 MySQL 是每個人都在用的資料庫。如果你使用它時碰到問題，這個問題別人也會碰到過，你自然不會碰到誰都無法理解的故障。”

硬體明顯沒有那麼有趣 ——尤其對於軟體工程師來說。但是 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。

Fork 程式碼

“當資料來臨時，對我們來說真的是規模問題，我們正在使用一個高可用的方式彈性儲存資料，”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也正在工作於其它應用上。 “有些技術你只是沒有把它下架，因為世界上我們是最大的程式碼託管商，我們有很多定製領域的問題，”蘭伯特說。

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

GitHub 在 2012 年的 7 月第一輪風險融，從 Andressen Horowitz 那裡資籌集了 1 億美元，和今年 7 月的第二輪融資，從紅杉資本和 Andreessen Horowitz，Thrive Capital 和 Institutional Venture Partners 籌集了另外 2.5 億美元,該公司尚未公開，但鑑於其融資的估值約為 20 億美元，和現金增長其基礎,並擴大它的目標市場。

ChatOps 文化與分散式開發

GitHub 的一個重要創新，嚴格的講，不是程式碼部分,但絕對是公司 Hubot 的一部分，這是公司使用的一個聊天機器人系統管理介面。這種方法通常被稱為 ChatOps，給部署操作起別名，通過聊天機器人，用聊天的方式做 DevOps。在 GitHub 裡一切都使用它。