![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/42eddfc796fe4a2fb5cf0e20f5d28fdd.png)

作者 | Frank San Miguel
策劃 | 田曉旭

2021 年，Netflix 會將大部分的工作負載從 Reloaded 轉移到 Cosmos 平臺。Cosmos 是一個計算平臺，它將微服務的最佳特性與非同步工作流以及 Serverless 結合在一起。

# 介紹

Cosmos 是一個計算平臺，它將微服務的最佳特性與非同步工作流以及 Serverless（無伺服器）結合在一起。它的最佳應用是用於涉及到資源密集型演算法的應用程式中，這些演算法透過複雜的層次化工作流進行協調，可以持續幾分鐘到幾年。它既支援一次消耗數十萬個 CPU 的高吞吐量服務，也支援需要等待計算結果對延遲敏感的工作負載。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/d83032c052a440f787d4f17c5776248c.jpg)

（一個 Cosmos 服務）

本文將會解釋我們建造 Cosmos 的原因以及它的工作原理，同時也會分享一些我們在此過程中學到的知識。

# 背景

Netflix 的媒體雲工程和編碼技術團隊共同運營一個系統，處理來自我們的合作伙伴以及工作室的輸入媒體檔案，使它們可以在所有裝置上播放。該系統的第一代於 2007 年推出了流媒體技術。第二代增加了擴縮容，但操作極為困難。第三代被稱為 Reloaded，也已經上線 7 年了，並且已被證明是穩定的且可進行大規模擴縮容的。

在設計 Reloaded 時，我們是一個由開發人員組成的小團隊，操作一個受限的計算叢集，並專注於唯一的用例：影片 / 音訊處理管道。隨著時間的推移，開發人員的數量增加了三倍多，我們的用例廣度和深度也都擴大了，我們的規模增長了十多倍。單體架構大大降低了新特性的交付速度。我們不能再期望每個人都擁有構建和部署新特性所必需的專業知識了。由於基礎設施程式碼和應用程式程式碼都混在了一起，導致處理生產問題成為一項繁重的瑣事，這給所有開發人員都帶來了負擔。當我們還是一個小團隊的時候，集中式資料模型能很好地服務於我們，但現在它成了我們的累贅。

我們的響應是建立 Cosmos，這是一個由工作流驅動、以媒體為中心的微服務平臺。我們的首要目標是在保留我們當前能力的同時提供以下功能：

- 可觀察性——透過內建的日誌、跟蹤、監控、報警以及錯誤分類來實現。
- 模組化——用於構造服務並支援編譯時和執行時模組化的一個“自以為是”的框架。
- 生產力——本地開發工具，包括專門的測試執行程式、程式碼 生成器和命令列介面。
- 交付——一個被全面管理的管道、持續整合作業和端到端測試的持續交付系統。當你合併 pull 請求時，它可以在沒有人干預的情況下將其投入到生產環境中。

在此期間，我們還對可伸縮性、可靠性、安全性和其他系統質量進行了改進。

# 概述

Cosmos 服務不是微服務，但是它們有很多相似之處。典型的微服務是一個具有無狀態業務邏輯的 API，它可以根據請求負載自動擴縮容。該 API 提供了與對等方之間的強契約，同時將應用資料和二進位制依賴關係與其他系統隔離開來。

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/abab9d1aa88e4658babca8bb1ef6db40.jpg)

（一個典型的微服務）

Cosmos 服務保留了微服務的強契約和相隔離的資料 / 依賴關係，但新增了多步工作流和計算密集型非同步 Serverless 函式。下圖展示了一個典型的 Cosmos 服務，在該服務中，客戶端將請求傳送到影片編碼器服務的 API 層。一組規則編排工作流步驟，一組 Serverless 函式執行特定領域的演算法。函式被打包為 Docker 映象，並帶有它們自己特定於媒體的二進位制依賴項（例如 debian 包）。它們根據佇列的大小進行擴縮容，可以在成千上萬的不同容器上執行。請求可能需要數小時或數天才能完成。

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/1924253f7eaa4fc18f828b3c76fce813.jpg)

（一個典型的 Cosmos 服務）

# 關注點分離

Cosmos 有兩條分離軸。一方面，邏輯被劃分為 API、工作流和 Serverless 函式。另一方面，邏輯在應用程式和平臺之間也是分離的。平臺 API 為應用程式開發人員提供了特定於媒體的抽象，同時隱藏了分散式計算的細節。例如，影片編碼服務是由與擴縮容無關的元件構建的：API、工作流和函式。他們對自己的擴縮容沒有特別的瞭解。這些特定於領域的、擴縮容不可知的元件構建在三個 擴縮容可感知的 Cosmos 子系統上，這些子系統負責處理分發工作的細節：

- Optimus，一個將外部請求對映到內部業務模型的 API 層。
- Plato，一個用於業務規則建模的工作流層。
- Stratum，一個 Serverless 層，用於執行無狀態以及計算密集型函式。

所有這些子系統都透過 Timestone（一種大規模、低延遲的優先順序佇列系統）進行非同步通訊。每個子系統處理服務的不同關注點，並且可以透過專門構建的託管持續交付流程獨立部署。這種關注點的分離使得編寫、測試和操作 Cosmos 服務更加容易。

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/454f14e2d681489088f24417cecd2a74.jpg)

（平臺與應用程式分離）

# Cosmos 服務請求

![5.png](https://ucc.alicdn.com/pic/developer-ecology/5da77d67b30d43ab987e92b8f9c9f320.png)

（Cosmos 服務請求的跟蹤圖）

上圖是我們的觀察入口網站 Nirvana 的截圖。它展示了 Cosmos 中的一個典型服務請求（在本例中是一個影片編碼器服務）：

- 有一個用於編碼的 API 呼叫，其中包括影片源和“配 方”。
- 影片被分成 31 個塊，並且有 31 個編碼函式並行執行。
- 組裝函式只被呼叫一次。
- 索引函式只被呼叫一次。
- 8 分鐘後工作流完成。

# 服務分層

Cosmos 支援服務的分解和分層。由此產生的模組化架構允許團隊專注於他們自己的專業領域，並控制自己的 API 和釋出週期。

例如，上面提到的影片服務只是眾多用於建立可在裝置上播放的流的服務之一。這些服務還包括檢查、音訊、文字和包裝，它們是用更高階別的服務精心編排的。其中最大、最複雜的是 Tapas，它負責從工作室獲取資源，並使這些資源可以在 Netflix 服務上播放。另一個高階服務是 Sagan，它用於工作室的操作，如營銷剪輯或日常製作編輯代理等。

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/ad76a69993384c5caa1db346b814e15c.jpg)

（Cosmos 服務分層）

當製作工作室有新作品時，它會觸發一個 Tapas 工作流，該工作流會編排執行檢查的請求、編碼影片（多種解析度、質量、影片編解碼器）、編碼音訊（多種質量、編解碼器）、生成字幕（多種語言）並打包結果輸出（多個播放器格式）。因此，對 Tapas 的單個請求可能導致對其他 Cosmos 服務的數百個請求以及數千個 Stratum 函式呼叫。

下面的跟蹤示例展示了一個頂級服務中的請求是如何向下流到較低階別的服務中，從而導致許多不同操作的。在這種情況下，請求需要 24 分鐘才能完成，數百個不同的行動涉及 8 個不同的 Cosmos 服務和 9 個不同的 Stratum 函式。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/b6bd39af5f1c4bb3bdb598020ffd3ddd.png)

（透過多個層的服務請求跟蹤圖）

# 工作流規則

或者我們應該說是一些工作流規則？Plato 是一種粘合劑，它透過為服務開發人員提供一個定義領域邏輯和編排無狀態函式 / 服務的框架來將 Cosmos 中的一切內容聯絡在一起。Optimus API 層具有內建的工具，可以呼叫工作流並檢查它們的狀態。Stratum 的 Serverless 層生成強型別的 RPC 客戶端，使呼叫 Serverless 函式變得簡單且直觀。

Plato 是一個前向連結規則引擎，它有助於我們演算法的非同步性和計算密集性。與 Netflix 的 Conductor 這樣的程式化工作流引擎不同，Plato 使建立“始終線上”（“always on”）的工作流變得更容易。例如，當我們開發出更好的編碼演算法時，我們基於規則的工作流會自動管理更新現有的影片，而無需觸發和管理新的工作流。此外，任何工作流都可以呼叫另一個工作流，從而實現上述服務的分層。

Plato 是一個多租戶系統（使用 Apache Karaf 實現），可以極大地減少操作工作流的操作負擔。使用者在自己的原始碼庫中編寫和測試他們的規則，然後透過將編譯後的程式碼上傳到 Plato 服務端來部署工作流。

開發人員透過用 Emirax（一種基於 Groovy 構建的特定領域語言）編寫的一組規則來指定他們的工作流，每條規則有 4 個部分：

- 匹配（match）：指定要觸發此規則必須滿足的條件。
- 動作（action）：指定觸發該規則時要執行的程式碼；在這裡，你可以呼叫 Stratum 函式來處理請求。
- 響應（reaction）：指定當動作程式碼成功完成時要執行的程式碼。
- 錯誤（error）：指定遇到錯誤時要執行的程式碼。

在這些部分中，你通常首先要記錄工作流狀態的變化，然後執行使工作流向前推移的步驟，例如，執行 Stratum 函式或返回執行結果。

# 延遲敏感型應用程式

像 Sagan 這樣的 Cosmos 服務對延遲敏感，因為它們是面向使用者的。例如，一位正在製作社交媒體帖子的藝術家，在剪輯最新一季的 《紙鈔屋》（Money Heist）的影片時不想等太久。對於 Stratum，延遲是執行工作的時間加上獲取計算資源的時間的函式。當工作非常繁忙時（通常是這樣），“獲取資源的時間”就成為了重要因素。舉個例子，假設你購物時通常會買衛生紙。正常情況下，把它放進購物車，透過收銀臺是沒有問題的，整個過程需要你花費 30 分鐘。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/ee86123925954dafbd47b5cc68461b5d.png)

（資源稀缺）

然後有一天，一種糟糕的病毒爆發了，並且每個人都決定要買更多的衛生紙。由於總需求超過了可用容量，你衛生紙的延遲時間現在從 30 分鐘增加到了兩週。Cosmos 應用程式（尤其是 Stratum 函式）在面對突發和不可預測的需求時也有同樣的問題。Stratum 透過以下幾種方式來管理函式的執行延遲：

- **資源池（Resource pools）**。終端使用者可以為自己的業務用例保留 Stratum 計算資源，並且資源池是分層的，允許使用者組共享資源。

- **容量預熱（Warm capacity）**。終端使用者可以提前請求計算資源（例如容器），以減少 Stratum 中的啟動延遲。

- **微批次（Micro-batches）**。Stratum 還使用微批次處理，這是在 Apache Spark 等平臺上學到的一種減少啟動延遲的技巧。其思想是將啟動成本分攤到許多函式呼叫中。如果你呼叫函式 10000 次，那麼該函式可能在 10000 個容器上執行一次，也可能在 1000 個容器上執行 10 次。

- **優先順序（Priority）**。當需要在成本和低延遲的需求之間進行平衡時，Cosmos 服務通常會落在中間的某個位置：有足夠的資源來處理典型的突發事件，但沒有足夠的資源來處理延遲最低的最大突發事件。透過對工作進行優先順序排序，即使在資源短缺的情況下，應用程式仍可以確保以較低的延遲處理最重要的工作。Cosmos 服務所有者可以允許終端使用者設定優先順序，或者在 API 層或工作流中自己設定優先順序。

# 吞吐量敏感型應用程式

像 Tapas 這樣的服務對吞吐量非常敏感，因為它們會消耗大量的計算資源（例如每天數百萬個 CPU 小時），並且更關心一段時間內（數小時或數天內）完成的任務，而不是完成單個任務的時間。換句話說，服務等級目標（SLO）是以每天的任務和每項任務的成本來衡量的，而不是以每秒的任務來衡量的。

對於吞吐量敏感的工作負載，最重要的 SLO 是由 Stratum 的 Serverles 層提供的。構建在 Titus 容器平臺之上的 Stratum 允許吞吐量敏感的工作負載透過靈活的資源排程使用“機會主義”計算資源。例如，如果一個 Serverles 函式呼叫願意等待一個小時再執行，那麼它的成本可能會更低。

# Strangler Fig

我們知道，移動一個像 Reloaded 這樣龐大而複雜的遺留系統將是一個跨越危險鴻溝的大躍進，這個鴻溝裡到處都是失敗的重新設計後的專案碎片，但毫無疑問，我們必須跳下去。為了降低風險，我們採用了 Strangler Fig（絞殺榕）模式，讓新系統圍繞舊系統擴充套件，並最終完全取代舊系統。

# 仍然在學習

我們於 2018 年開始建造 Cosmos，並從 2019 年初開始投入生產。今天，我們大約有 40 個 Cosmos 服務，並且預計還會增長更多。我們仍處於中期階段，但我們可以分享一些我們迄今為止所學到的重點知識：

#### 1. Netflix 的文化起到了關鍵的作用

眾所周知，Netflix 的工程文化依賴於個人判斷，而不是自上而下的控制。軟體開發人員有承擔風險和做出決策的自由和責任。我們中沒有人有軟體架構師的頭銜；我們所有人都在扮演著這個角色。在這種背景下，Cosmos 從區域性最佳化的不同嘗試中脫穎而出。Optimus、Plato 和 Stratum 是獨立構思的，並最終整合成一個單一的平臺願景。團隊中的應用程式開發人員讓每個人都專注於使用者友好的 API 和開發人員的生產力。基礎設施和媒體演算法開發人員之間建立了強有力的合作關係，才將願景變為現實。我們不可能在自上而下的工程環境中做到這一點。

#### 2. 微服務 + 工作流 + Serverless

我們發現，“觸發編排 Serverless 函式工作流的微服務”的程式設計模型是一個強大的正規化。它適用於我們的大多數用例，但有些應用程式非常簡單，以至於由此而增加複雜性是不值得的。

#### 3. 平臺心態

從大型分散式應用程式遷移到“平臺 + 應用程式”是一個重大的正規化轉變。每個人都必須改變他們的心態。應用程式開發人員必須放棄一定的靈活性，以換取一致性、可靠性等。平臺開發人員必須培養更多的同理心，並優先考慮客戶服務、使用者生產力和服務等級。有時候，應用程式開發人員會感到平臺團隊沒有適當地專注於他們的需求，而有時候，平臺團隊卻因使用者需求而感到負擔過重。我們彼此坦誠相待，度過了這些難關。例如，在最近的一次回顧之後，我們加強了橫切系統質量的開發跟蹤，例如開發人員的經驗、可靠性、可觀察性和安全性。

#### 4. 平臺獲勝

我們建立 Cosmos 的目的是讓開發人員能夠更好更快地工作，將更多的時間花在解決業務問題上，而減少處理基礎設施的時間。有時目標似乎遙不可及，但我們開始看到我們所希望的成果。在 Cosmos 中，開發人員最喜歡的一些系統特性是託管交付、模組化、可觀察性和開發人員支援。我們正在努力使這些品質變得更好，同時也在致力於薄弱環節，如本地開發、彈性和可測試性。

# 未來的規劃

2021 年對 Cosmos 來說將是重要的一年，因為我們會將大部分工作從 Reloaded 轉移到 Cosmos 中，這將帶來更多的開發人員和更高的負載。我們計劃改進程式設計模型以適應新的用例。我們的目標是使 Cosmos 更易於使用，更具彈性，更快，更有效。請繼續關注，以瞭解更多有關 Cosmos 是如何工作以及我們是如何使用它的細節。

> 原文連結：[https://netflixtechblog.com/the-netflix-cosmos-platform-35c14d9351ad](https://netflixtechblog.com/the-netflix-cosmos-platform-35c14d9351ad)

微服務+非同步工作流+ Serverless，Netflix 決定棄用穩定執行 7 年的舊平臺

相關文章