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