Netflix如何部署代碼

　　著名的電影流媒體網站 Netflix 每天都會進行上百遍部署，它們沒有使用 Chef 或 Puppet，沒有一個質量保證部門，也沒有發布工程師。為了實現自己的目標，Netflix 構建了一個先進的內部 PaaS（平臺即服務）平臺，所有的團隊都能夠通過這個平臺部署自己的基礎設施部分，同時部署也沒有時間和次數上的限制。在 QCon New York 2013期間，Jeremy Edberg 介紹了這個 Netflix 為了滿足快速迭代的需要而基于 Amazon AWS 構建的基礎設施。

　　Netflix 在實現 API 的時候使用了面向服務的架構，該架構會處理網站的大部分請求（每天有 20 億次請求）。在幕后，API 被分離成了很多服務，每一個服務都由一個團隊進行管理，這使得團隊能夠相對獨立地進行工作，也能夠獨立決定何時以何種頻率部署新軟件。

　　Netflix 在 DevOps 方面的投入很大。開發者構建、部署并維護他們自己的服務器集群，同時還需要對錯誤負責。如果發生了錯誤，便需要組織一個會議調查問題出現的根本原因，討論防止此類問題將來繼續發生的方案——類似于5 個為什么。

　　Netflix 中的部署完全是自動化的。如果一個服務需要部署，那么開發者首先會將代碼推到一個源代碼倉庫。之后 Jenkins 會捕獲到這個代碼推動事件并執行構建生成一個應用程序包。再往后便會基于基礎鏡像（包含一個 Linux 發布版本）和所有 Netflix 服務器上運行的軟件（包括 JVM 和 Tomcat，將來可能會允許團隊做進一步的自定義）產生一個新的 VM 鏡像（AMI）。在上面這些基礎內容安裝完成之后會安裝應用程序包。由此，一個 AMI 便產生并注冊到系統中了。

　　為了將 VM 鏡像部署到它的基礎設施中， Netflix 構建了 Asgard。VM 鏡像能夠通過 Asgard Web 接口實例化并創建新的 EC2 集群。每一個集群都會包含至少 3 個 EC2 實例用于冗余，這些實例會散步到多個可用區域中。部署新版本的時候，在新版本被實例化運行的同時，運行之前版本的集群仍將繼續運行。在新版本啟動并將自己注冊到稱為 Eureka 的 Netflix 服務注冊表之后，負載均衡器便會進行切換將所有的流量導向到新集群。新集群會被仔細地監控并保持運行一整夜。如果所有的事情都運行良好，舊集群便會被銷毀。如果有任何問題發生，那么負載均衡器便會切換回舊集群。

　　在 Netflix 基礎設施中會不斷地產生錯誤。軟件需要能夠處理硬件故障、網絡連接故障以及其他類型的錯誤。雖然錯誤并不會自然而然地產生，但是使用 Simian Army 還是極有可能誘發錯誤。Simian Army 中包含了很多（軟件）“猴子”能夠隨機地引入錯誤。例如，Chaos 猴子會隨機地導致服務器崩潰，而 Latency 猴子會隨機地引發網絡延遲。如果團隊認清了錯誤會時常發生的事實，那么他們就有可能忽略錯誤并創建一種錯誤彈性至上的文化。

　　Netflix 基礎設施中的很多部分現在都已經開源了，你可以通過 GitHub 獲取。Netflix 的最終目標便是完全發布它的基礎設施，讓其他的公司能夠從中受益。　　

英文原文：How Netflix Deploys Code