专栏名称: 聊聊架构
聊聊架构
目录
相关文章推荐
高可用架构  ·  Feed 流系统的架构设计方案 ·  昨天  
架构师之路  ·  架构设计中的后台任务:3种场景,2.5种触发 ... ·  2 天前  
架构师之路  ·  高可用架构:fail-over的三种经典模式 ... ·  4 天前  
架构师之路  ·  架构师之路:流量从10万到10亿,一定会遇到 ... ·  3 天前  
51好读  ›  专栏  ›  聊聊架构

Reddit 的代码部署演化史

聊聊架构  · 公众号  · 架构  · 2017-08-10 20:35

正文

作者|薛命灯
编辑|雨多田光
Reddit 的资深工程师 Neil Williams 和 Saurabh Sharma 在 Reddit 官方博客上以编年史的方式分享了 Reddit 代码部署的演化进程,一步一步说明了部署工作是如何从一个简单的 Perl 脚本发展开来的。
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 获取主机清单的能力让整个迁移过程变得相当顺畅。不管主机清单如何发生变动,对于工具来说都没有任何影响。他们还 使用 Gunicorn 替代了 uWSGI

2014 年:服务器增长

随着流量和服务器数量的增长,部署时间也越来越长,最糟糕的情况下,一个正常的部署需要将近一个小时的时间。于是,他们 再次重写了部署工具,并将其改名为 rollingpin。

新工具可以进行并行部署,加快了部署速度,把部署时间再次降回到 5 分钟。新工具也比旧工具更加智能,在挑选服务器时可以交错地从不同服务器群中选择服务器进行部署,避免一次性重启整个服务器群导致服务不可用。

2015 年:员工增长

工程师团队的规模也在不断增长,需要部署的东西也越来越多。遵循一次只进行一次部署的规则变得越来越困难,工程师们在协调发布顺序方面也耗费了不少时间和精力。

于是,他们给聊天机器人使用了 协调部署队列。工程师向机器人申请部署锁,要么获得部署锁,要么被放入队列。这样就可以保证部署次序,工程师在等待部署锁的过程中可以做一些其他的事情。

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

2015 年 (+1):两种服务

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

2016 年:25 种服务

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

2017 年:安全网

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

不过新的模型也存在一个问题,因为重启一个工作进程需要 30 秒钟的时间,如果新代码里包含了 bug,在 30 秒之内是无法发现它们的,可是在这段时间内可能已经部署了好几台服务器了。

为了解决这个问题,他们引入了一种机制,他们 轮询 Einhorn 的状态,等待新工作进程准备就绪,在这之前不允许部署下一台服务器。为了加快速度,他们加大了并行数,因为现在进行并行部署是安全的。

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

未来:X

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

阅读原文

https://redditblog.com/2017/06/02/the-evolution-of-code-deploys-at-reddit/

今日荐文

点击下方图片即可阅读

2017 年,Serverless 何去何从?


更多关于精彩技术专题请关注QCon 全球软件开发大会,QCon 上海站目前 8 折优惠报名中,2017 年 08 月 20 日前,立减 1360 元,团购报名更多优惠~点击【阅读原文】跟技术大咖零距离。欲购票或咨询问题可联系购票经理 Hanna ,电话/微信:15110019061