BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Buzzfeed部署架构的改进

| 作者 Hrishikesh Barua 关注 15 他的粉丝 ,译者 Rays 关注 3 他的粉丝 发布于 2017年6月23日. 估计阅读时间: 7 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

 

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT