GitLab Workhorse 简史 已翻译 100%

Gitlab-workhorse 是一个以 Go 而不是以 Ruby 编写的'周末项目'，在过去 8 个月，它从一个提供 git-clone 超时通知的组件小程序，成长为几乎涉及所有对 GitLab 的 HTTP 请求的部件。 在这篇博文中，我简单回顾了这一过程。

技术和个人动机

GitLab 是一个使用 Unicorn Ruby Web 服务器的 Ruby on Rails Web 应用程序。我是 Unicorn 的粉丝，因为它使应用程序资源泄漏变得可管理，还因为它很好地服务了 GitLab，修补了我们发现但难以“合理”解决的问题。

同时，Unicorn 的设计与 Gitlab 的主函数之一不兼容，即通过 HTTP(S) 的 Git 存储库访问（git clone，git push 等）。不兼容的原因是 Unicorn 严重依赖于（相对）短的请求超时。你不会希望配置 Unicorn 时的超时变慢而不是变快。另外，如果获得一个大型 Git 库，git clone 将花费很长时间。我以前 GitLab 服务工程师的时候，经常向客户解释这一问题。而我们提供的唯一的解决途径就是使用 ssh 代替 git。

另一个创建 gitlab-workhorse 的动机是我对 Go 编程语言的无限好奇心。有时 Go 被认为（或被怀疑）在背后有强有力的市场推动。市场就对我产生了影响：我有一个毛绒的 Go 吉祥物，它在我的桌子待了差不多三年。

将周末项目合并到主分支

在去年的七月的一个周末，我突然想用 Go 来构建一些东西，我想：我能否使用 Go 语言写一个 gitlab-grack 呢？这个 GitLab 组件是用于相应 Git 的 HTTP 客户端请求。我花了好几个月的时间开发这个项目。

几个月后，一个叫做 gitlab-git-http-server 的 Go 程序就上线了，但在通过 Unicorn 进行 clone 时并没有产生超时问题。把它合并到 GitLab 时使用了一个讨巧的方法，即让 NGINX 把 Git 的 HTTP 请求从 Unicorn 转移到 gitlab-git-http-server。GitLab Rails 要求的更改很小，我可以轻松将它们隐藏在功能标志后面。为给该项目画上圆满的句号，我向团队公布了 gitlab-git-http-server 的存在。

我的团队让我设法检验下 gitlab-git-http-server 程序（方法：把这个程序 merge 到 master 里面，然后配置在我们的开发服务器上），然后就开始测试了。不到一个月后，GitLab 7.14 里面就有了 gitlab-git-http-server 的功能标签。于是我们需要花一个月时间在 GitLab.com 上面测试这个程序。在我们的开发环境和 GitLab.com 之间，我们找出了最糟的 bug。在 GitLab 8.0（在 7.14 之后一个月发布的）中，我们使得 gitlab-git-http-server 成为了 GitLab 的官方组件（被 GitLab 官方要求的！）。

团队对于 gitlab-git-http-server 程序的接受可能是因为 GitLab 的 Git-over-HTTP 解决方案没有完全解决问题，并且我们已经在 gitlab-ci-multi-runner 上使用了 Go 语言。而在此之前，我们并没有预留解决 Git-over-HTTP 出现的问题的方法。

功能进化

至此 gitlab-git-http-server 能处理的还不多：只处理 Git 的 HTTP 客户端请求。但这就像你有了一个锤子，于是什么东西都想钉一下。在 GitLab 8.1 中，我们让 gitlab-git-http-server 也能够处理网页端 'download zip'  的访问接口。在整个过程中，这一阶段的发生似乎是理所当然，但在当时却是摆在我们面前的鸿沟：我们认为 gitlab-git-http-server 只是一个守护进程，能够理解(无状态) HTTP 基本认证，但并不会作为会话 cookies 识别不同的用户。但会话 cookie 只是一个 HTTP 头，因此在整个过程中，没有什么能够阻止 gitlab-git-http-server '扮演'登录用户，也无法阻止它临时产生 zip 文件。

新名称时刻

在 GitLab 8.2 中我们想要发布两个新的特性，用于解决过去我们认为困扰 Git-over-HTTP 的 Unicorn 超时问题： Git LFS 支持 (由 Marin 开发)和 CI build artifacts (由 Kamil 开发)。这两个特性同时依赖于用户上传和下载任意的大文件。

此次开发为 gitlab-git-http-server 带来了很多新的改进。首先，越来越多的人需要说或写 'gitlab-git-http-server' 这一词，用的人多，这个名字叫起来就显得过于拗口。并且增加了一些新的特性，这个名字就不再合适了，因为程序已经不仅仅只处理 Git-over-HTTP。我们要谢谢 Marin 起的 'gitlab-workhorse'这个名字，我非常喜欢它，因为它点出了 Unicorn 的缺陷。

Kamil 是 Go 领域的常驻专家，自 gitlab-workhorse 得到他的关注后，取得了很大的进步。我们有信心让 gitlab-workhorse 发挥效用。

有段时间 Marin 和我试图在 gitlab-workhorse 中实现文件上传/下载，而 Kamil 则使用 NGINX 插件为 CI 工件实现了同样的功能。后来我们发现是重复劳动后，决定在代码发布之前，在 gitlab-workhorse 和 GitLab 8.2 中同时实现该功能。

我们最终得到了一个在 gitlab-workhorse 上下载文件的优秀解决方案，灵感来自 Kamil 打算在 NGINX 中使用的机制：X-Sendfile 文件头。大多数时候，当你想使用 gitlab-workhorse 在 GitLab 中做出更快或更健壮的功能时，你必须同时编写 Ruby 版本和 Go 版本。但因为 Ruby on Rails 已经支持 X-Sendfile，GitLab 开发人员可以在无需编写任何 Go 代码的情况下获得 gitlab-workhorse 对文件下载的优化支持！

孤注一掷

此时，通过在 gitlab-workhorse 中完成部分工作我们可以构建新的 GitLab 特性了，取得成功的同时相应的也会产生问题。每次我们向 gitlab-workhorse 添加新功能，都意味着在 NGINX配置 中将更多的 HTTP 请求转移到 gitlab-workhorse 上。 这个复杂性被隐藏在那些使用 Omnibus 包安装 GitLab 的人身上，但我可以从 gitlab-workhorse 问题跟踪器中看出来，使用源代码安装是问题的主要来源。

在 gitlab-workhorse 之前，NGINX 提供静态文件或将请求转发到 Unicorn 上：

+----------+      +-------------+
|          |      |             |
|  NGINX   +----> |   Unicorn   |
|          |      |             |
+------+---+      +-------------+
       |
       |
       |          +------------+
       |          |            |
       +--------> |   static   |
                  |   files    |
                  |            |
                  +------------+