Github的系統內部都在用什么開源軟件？
英文原文：Inside The GitHub Systems Where Open Source Lives
有時候處理規模問題最好的辦法就是讓事情變得簡單并盡你可能去避免出現這種情況。這是 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 是每個人都在用的數據庫。如果你使用它時碰到問題，這個問題別人也會碰到過，你自然不會碰到誰都無法理解的故障。”
</blockquote>硬件明顯沒有那么有趣 ——尤其對于軟件工程師來說。但是 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。我們保持精益，做優化，以保持這種方式。
我們現階段不完全，不像 非死book 的 HipHop 和 非死book 用 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 里一切都使用它。
來自: 開源中國社區本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！