Buzzfeed部署架构的改进

架构

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

作者： Hrishikesh Barua

正文：

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