Reddit 的代码部署演化进程

Reddit 的资深工程师 Neil Williams 和 Saurabh Sharma 在 Reddit 官方博客上以编年史的方式分享了 Reddit 代码部署的演化进程。

故事开端：可重复的一致性部署（2007 年至 2010 年）

在 Reddit 刚刚起步的时候，只有几名工程师，整个网站是一个使用 Python 开发的大单体，部署在几台固定的服务器上。大部分部署工作通过一个叫作 push 的 Perl 脚本进行。

他们使用了负载均衡器，对请求进行分类，把流量分配给不同类型的服务器群。分流带来的好处显而易见，一方面可以轻松应对流量高峰，一方面避免不同服务器群之间的互相影响。

在部署应用时，push 工具遍历服务器清单，通过 SSH 登录服务器，运行一些列命令更新服务器的代码，然后重启服务器。整个部署过程是串行化的，也就是逐台服务器部署。这样做有个好处，如果在部署了几台服务器后发生异常，可以立即停止后续的部署，并回滚已经部署的服务器，避免将问题扩散到整个生产环境。

团队增长（2011 年）

随着团队成员越来越多，在进行部署时需要做更多的协调工作。他们修改了 push 工具，通过 IRC 聊天机器人来触发部署事件。大体的部署流程没有太大变化，只是引入了机器人，使用机器人可以帮团队成员节省一些时间和精力。

随着网站流量的增长，他们加入了更多的服务器。这个时候他们仍然需要通过人工来更新 push 的主机清单。他们使用 uWSGI 来管理工作进程，在重启应用程序时，uWSGI 会杀掉运行中的进程并启动新的进程。因为启动新进程需要一小段时间，所以如果重启的是整个服务器群，在这段时间内服务器群就无法提供服务。随着服务器数量越来越多，部署的时间也相应变长。

重构部署工具（2012 年）

后来他们使用 Python 重写 push 工具，不再使用硬编码的方式提供主机清单，而是从 DNS 服务器上获取主机清单，所以如果有新的服务器加入，就不需要再去修改工具本身了。

他们还把主机清单的顺序打乱，来自不同服务器群的主机都有机会得到优先的部署，而不是像之前那样需要一个服务器群接着一个服务器群地部署。不过打乱主机顺序也会带来一个问题，就是在出现问题时很难回退。所以他们使用种子（seed）的方式来打乱主机清单顺序，在回退代码时可以使用之前的顺序。

另外，在部署代码时，他们使用了 Git 的修订版（revision）代替了原先的 master 分支，避免在部署过程中有人意外提交代码到 master 上，这样可以办证部署的总是相同版本的代码。

自动伸缩（2013 年）

他们开始使用云服务，云服务的自动伸缩功能可以在流量不是很大的时候节约成本，而在流量增长时又可以自动伸缩。在向云端迁移的过程中，push 工具从 DNS 获取主机清单的能力让整个迁移过程变得相当顺畅。不管主机清单如何发生变动，对于工具来说都没有任何影响。他们还使用 Cunicorn 代替了 uWSGI。

服务器增长（2014 年）

随着流量和服务器数量的增长，部署时间也越来越长，最糟糕的情况下，一个正常的部署需要将近一个小时的时间。于是，他们再次重写了部署工具，并将其改名为 rollingpin 。新工具可以进行并行部署，加快了部署速度，把部署时间再次降回到 5 分钟。新工具也比旧工具更加智能，在挑选服务器时可以交错地从不同服务器群中选择服务器进行部署，避免一次性重启整个服务器群导致服务不可用。

员工增长（2015 年）

工程师团队的规模也在不断增长，需要部署的东西也越来越多。遵循一次只进行一次部署的规则变得越来越困难，工程师们在协调发布顺序方面也耗费了不少时间和精力。于是，他们给聊天机器人使用了协调部署队列。工程师向机器人申请部署锁，要么获得部署锁，要么被放入队列。这样就可以保证部署次序，工程师在等待部署锁的过程中可以做一些其他的事情。

他们还修改了部署工具，让它向 Graphite 发送度量指标，这样就可以很容易地跟踪部署变更。

两种服务（2015 年）

后来，移动版的网站上线，它采用了完全不同的技术栈，有自己的服务器和构建流程。部署工具的解耦 API 在这个时候才真正派上用场。因为每个项目可以在不同的位置进行构建，他们就可以通过同一个系统来管理所有的服务。

25 种服务（2016 年）

此时，Reddit 的服务种类从两个发展到几十个，团队数量也从两个变成 15 个。他们通过后端服务框架 Baseplate 来构建新服务，或者使用 nodejs 构建移动 Web 应用。rollingpin 不再关心部署的是哪一种应用，他们的部署基础设施已经具备了足够的通用性。

安全网（2017 年）

高度的并行部署会导致多台服务器同时重启，降低了处理请求的能力，还会让其他服务器过载。Gunicorn 的主进程使用了与 uWSGI 类似的模型，会一次性重启所有的工作进程，在新工作进程启动过程中无法处理任何请求。于是他们使用 Stripe 的 Einhorn 代替了 Gunicorn。Einhorn 在重启工作进程时会先创建新的工作进程，等新进程准备就绪之后才会把旧进程停掉。

不过新的模型也存在一个问题，因为重启一个工作进程需要 30 秒钟的时间，如果新代码里包含了 bug，在 30 秒之内是无法发现它们的，可是在这段时间内可能已经部署了好几台服务器了。为了解决这个问题，他们引入了一种机制，他们轮询 Einhorn 的状态，等待新工作进程准备就绪，在这之前不允许部署下一台服务器。为了加快速度，他们加大了并行数，因为现在进行并行部署是安全的。

为此，部署时间下降了很多，部署 800 台服务器只需要 7 分钟。

未来

Reddit 的基础设施在支持团队增长的同时，还要不断地进行构建。Reddit 的增长速度处于历史制高点，他们现今面临的问题主要来自两个方面：提高工程师自制能力，同时保证生产环境基础设施的安全，并为工程师提供一个安全网，让他们能够放心地进行快速的部署。

感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。