Buzzfeed 部署架构的改进

Buzzfeed 工程师团队分享了他们的部署演化做法。他们构建了一个称为Rig 的内部框架，在其中使用了Docker、AWS ECS 和Jenkins 等工具，将先前需数日的基于单体应用的部署，演化为每日可达150 次部署。由此实现了迁移到面向服务的架构，并构建了一个协作度更高的工程团队。

有一些工程团队已经分享了他们在改进架构、部署和 DevOps 文化中的做法。Buzzfeed 作为一家媒体和技术站点，是最近实施了架构改进的企业之一。一开始，Buzzfeed 是一个小型单体应用。随着特性与用户的逐步增加，Buzzfeed 的规模和发布范围上也在同步增长。其整套产品在不断的扩展，其中每个产品具有不同的需求，因而部署过程也变得繁琐。部署的推送和验证开始需要数日的时间。

为改进部署，架构团队中的一个小组在 Buzzfeed 内部启动了一个采用了容器技术的 PaaS 项目。为详细了解这一部署架构转换的情况，InfoQ 采访了 Buzzfeed 的工程副总 Matt Reiferson：

针对如何巩固并改进我们的配置管理系统及相关工具，我们进行了多次讨论。最终，我们认识到，方法只会对现有的工作流产生很小的改进。我们的设想是，与其从 Puppet、Chef 或 Ansible 这类工具中选取，不如完全避免用户与工具交互的必要性。首要的一点是，我们缺失一种高层抽象，使得团队可以聚焦于解决自身的实际问题，并快速地迭代。容器是一种天然的解决方案，极大地简化了“配置管理”，并为统一的“服务”抽象提供了基底。我们认识到，所有的容器编排解决方案需要关联在一起，以给出我们所想要提供的一致的开发和配置体验。

除了这样的工具集之外，团队还决定对自身的应用采用一种面向服务的架构（SOA，Service Oriented Architecture）。SOA 本身尚具有一系列的挑战，无论是文化上的，还是技术上的。为采用 SOA，团队必须得到授权，并需要在组织上是成熟的。Reiferson 详细介绍了 Buzzfeed 在采纳 SOA 上的体验：

我们已经采纳了一种基于 Spotify 模型的松散组织架构，分隔为由“小队”任务驱动的“组”所组成，其中每个小队的成员具有适当的技能集，可以完成自身的目标。这一转化的关键在于需要对架构进行投资。之后，Rig 将围绕开发流程、运营所有权、可观察性和一致性，对我们所寻求的那些团队和个人应具备的行为具体化，并加以鼓励。我们已制订了一系列的内部文档，称为《BuzzFeed 计算机使用指南》，其中详细地说明了我们的技术选择、工作流以及前端（FE）/ 后端（BE）/ 移动架构。最为重要的是，这些文档深入地研究了我们所考虑的权衡问题，不只是要做什么，而且包括做事的原因，这为在构建新系统时做出好的选择提供了场景。我们还组建了一个架构审核委员会，并提供了团队可用的项目提交模板。

Rig 的一些灵感来自于 paasta 开源项目。每个服务的架构需求可以使用 YAML 文件和 Dockerfile 定义，用于容器镜像的创建。设计人员采用了一些运行时的通用惯例，其中一些来自“十二要素（Twelve Factor）原则”，此外还有一些惯例，类似于对所有基于HTTP 的服务不给出本地状态和健康检查端点。架构层是基于虚拟机的，其中部署由Web 界面启动， Terraform 用于提供云架构服务。在容器编排上，团队使用了 Amazon 的 Elastic Container Service（ECS）。此外还采用了其它一些 AWS 服务，用于 DNS 和负载均衡等。

在改进旧系统的全部工作中，首当其冲的是使开发和部署流水线易于操作、对 App 接口的标准化，以及提高所有团队在部署后的参与度。这些工作的目标是实现更好的协作和站点可靠性。正确的工具集对于开发（Dev）、质量保证（QA）和运行（Ops）是必要的，尤其是那些改进可见性的工具。可观察性是 Buzzfeed 团队构建自身工具集中的首要原则之一，它将为“系统和应用的分布式日志、仪表化（Instrumentation）及监控提供开箱即可用的支持”。

Buzzfeed 使用 Datadog 做度量采集，监控工具是基于 Nagios 架构的。Nagios 是与 PagerDuty 集成的，关键的和应付诸行动的报警置于 Nagios 架构中。Reiferson 指出，“这些报警也发送给一些特定于团队的 Slack 通道，这是声明在各自的服务配置中的“。Buzzfeed 依然正在探索如何能更好地定义 Nagios 和 Datadog 间的集成，以构建逐步上升的有效策略。

一个从代码提交开始的典型部署流水线，将会经历一个基于 Jenkins 的构建服务，该服务还会构建一个容器镜像，并在容器上运行测试。镜像在成功完成运行测试后，就被推送到一个容器 Registry 中。

在从概念验证（POC，Proof Of Concept）迁移到生产级工具的过程中，团队曾面对一些挑战，例如能力不足以胜任 Docker 的操作，还有新发布（指在当时是新发布的，对此Infoq 曾专门撰文介绍）的AWS ECS。但是，ECS 是基于AWS 中已验证架构元素之上的，使得团队无需操作容器调度的繁琐事宜，可聚集于在ECS 中运行的机器和软件栈。

迁移是按阶段完成的。其中，低风险、小工作负载的系统率先迁移。这一影响是多个方面的，在Rig 上线后，平均每天有约150 次部署。从公司文化上看，团队在服务的一致性、低代价实验和更大的所有权上也发生了改变。

本文中的图片由 https://tech.buzzfeed.com/deploy-with-haste-the-story-of-rig-ca9a58b5719a 提供。

查看英文原文： Evolution of Deployment Architecture at Buzzfeed