深入了解开源软件驻扎地 Github 已翻译 100%

有时候处理规模问题最好的办法就是让事情变得简单并尽你可能去避免出现这种情况。这是 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 有这么多的工程创造力。