簡(jiǎn)介：?2021 年，Netflix 會(huì)將大部分的工作負(fù)載從 Reloaded 轉(zhuǎn)移到 Cosmos 平臺(tái)。Cosmos 是一個(gè)計(jì)算平臺(tái)，它將微服務(wù)的最佳特性與異步工作流以及 Serverless 結(jié)合在一起。

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

2021 年，Netflix 會(huì)將大部分的工作負(fù)載從 Reloaded 轉(zhuǎn)移到 Cosmos 平臺(tái)。Cosmos 是一個(gè)計(jì)算平臺(tái)，它將微服務(wù)的最佳特性與異步工作流以及 Serverless 結(jié)合在一起。

介紹

Cosmos 是一個(gè)計(jì)算平臺(tái)，它將微服務(wù)的最佳特性與異步工作流以及 Serverless（無(wú)服務(wù)器）結(jié)合在一起。它的最佳應(yīng)用是用于涉及到資源密集型算法的應(yīng)用程序中，這些算法通過復(fù)雜的層次化工作流進(jìn)行協(xié)調(diào)，可以持續(xù)幾分鐘到幾年。它既支持一次消耗數(shù)十萬(wàn)個(gè) CPU 的高吞吐量服務(wù)，也支持需要等待計(jì)算結(jié)果對(duì)延遲敏感的工作負(fù)載。

（一個(gè) Cosmos 服務(wù)）

本文將會(huì)解釋我們建造 Cosmos 的原因以及它的工作原理，同時(shí)也會(huì)分享一些我們?cè)诖诉^程中學(xué)到的知識(shí)。

背景

Netflix 的媒體云工程和編碼技術(shù)團(tuán)隊(duì)共同運(yùn)營(yíng)一個(gè)系統(tǒng)，處理來(lái)自我們的合作伙伴以及工作室的輸入媒體文件，使它們可以在所有設(shè)備上播放。該系統(tǒng)的第一代于 2007 年推出了流媒體技術(shù)。第二代增加了擴(kuò)縮容，但操作極為困難。第三代被稱為 Reloaded，也已經(jīng)上線 7 年了，并且已被證明是穩(wěn)定的且可進(jìn)行大規(guī)模擴(kuò)縮容的。

在設(shè)計(jì) Reloaded 時(shí)，我們是一個(gè)由開發(fā)人員組成的小團(tuán)隊(duì)，操作一個(gè)受限的計(jì)算集群，并專注于唯一的用例：視頻 / 音頻處理管道。隨著時(shí)間的推移，開發(fā)人員的數(shù)量增加了三倍多，我們的用例廣度和深度也都擴(kuò)大了，我們的規(guī)模增長(zhǎng)了十多倍。單體架構(gòu)大大降低了新特性的交付速度。我們不能再期望每個(gè)人都擁有構(gòu)建和部署新特性所必需的專業(yè)知識(shí)了。由于基礎(chǔ)設(shè)施代碼和應(yīng)用程序代碼都混在了一起，導(dǎo)致處理生產(chǎn)問題成為一項(xiàng)繁重的瑣事，這給所有開發(fā)人員都帶來(lái)了負(fù)擔(dān)。當(dāng)我們還是一個(gè)小團(tuán)隊(duì)的時(shí)候，集中式數(shù)據(jù)模型能很好地服務(wù)于我們，但現(xiàn)在它成了我們的累贅。

我們的響應(yīng)是創(chuàng)建 Cosmos，這是一個(gè)由工作流驅(qū)動(dòng)、以媒體為中心的微服務(wù)平臺(tái)。我們的首要目標(biāo)是在保留我們當(dāng)前能力的同時(shí)提供以下功能：

• 可觀察性——通過內(nèi)置的日志、跟蹤、監(jiān)控、報(bào)警以及錯(cuò)誤分類來(lái)實(shí)現(xiàn)。
• 模塊化——用于構(gòu)造服務(wù)并支持編譯時(shí)和運(yùn)行時(shí)模塊化的一個(gè)“自以為是”的框架。
• 生產(chǎn)力——本地開發(fā)工具，包括專門的測(cè)試運(yùn)行程序、代碼生成器和命令行界面。
• 交付——一個(gè)被全面管理的管道、持續(xù)集成作業(yè)和端到端測(cè)試的持續(xù)交付系統(tǒng)。當(dāng)你合并 pull 請(qǐng)求時(shí)，它可以在沒有人干預(yù)的情況下將其投入到生產(chǎn)環(huán)境中。

在此期間，我們還對(duì)可伸縮性、可靠性、安全性和其他系統(tǒng)質(zhì)量進(jìn)行了改進(jìn)。

概述

Cosmos 服務(wù)不是微服務(wù)，但是它們有很多相似之處。典型的微服務(wù)是一個(gè)具有無(wú)狀態(tài)業(yè)務(wù)邏輯的 API，它可以根據(jù)請(qǐng)求負(fù)載自動(dòng)擴(kuò)縮容。該 API 提供了與對(duì)等方之間的強(qiáng)契約，同時(shí)將應(yīng)用數(shù)據(jù)和二進(jìn)制依賴關(guān)系與其他系統(tǒng)隔離開來(lái)。

（一個(gè)典型的微服務(wù)）

Cosmos 服務(wù)保留了微服務(wù)的強(qiáng)契約和相隔離的數(shù)據(jù) / 依賴關(guān)系，但添加了多步工作流和計(jì)算密集型異步 Serverless 函數(shù)。下圖展示了一個(gè)典型的 Cosmos 服務(wù)，在該服務(wù)中，客戶端將請(qǐng)求發(fā)送到視頻編碼器服務(wù)的 API 層。一組規(guī)則編排工作流步驟，一組 Serverless 函數(shù)執(zhí)行特定領(lǐng)域的算法。函數(shù)被打包為 Docker 鏡像，并帶有它們自己特定于媒體的二進(jìn)制依賴項(xiàng)（例如 debian 包）。它們根據(jù)隊(duì)列的大小進(jìn)行擴(kuò)縮容，可以在成千上萬(wàn)的不同容器上運(yùn)行。請(qǐng)求可能需要數(shù)小時(shí)或數(shù)天才能完成。

（一個(gè)典型的 Cosmos 服務(wù)）

關(guān)注點(diǎn)分離

Cosmos 有兩條分離軸。一方面，邏輯被劃分為 API、工作流和 Serverless 函數(shù)。另一方面，邏輯在應(yīng)用程序和平臺(tái)之間也是分離的。平臺(tái) API 為應(yīng)用程序開發(fā)人員提供了特定于媒體的抽象，同時(shí)隱藏了分布式計(jì)算的細(xì)節(jié)。例如，視頻編碼服務(wù)是由與擴(kuò)縮容無(wú)關(guān)的組件構(gòu)建的：API、工作流和函數(shù)。他們對(duì)自己的擴(kuò)縮容沒有特別的了解。這些特定于領(lǐng)域的、擴(kuò)縮容不可知的組件構(gòu)建在三個(gè) 擴(kuò)縮容可感知的 Cosmos 子系統(tǒng)上，這些子系統(tǒng)負(fù)責(zé)處理分發(fā)工作的細(xì)節(jié)：

• Optimus，一個(gè)將外部請(qǐng)求映射到內(nèi)部業(yè)務(wù)模型的 API 層。
• Plato，一個(gè)用于業(yè)務(wù)規(guī)則建模的工作流層。
• Stratum，一個(gè) Serverless 層，用于運(yùn)行無(wú)狀態(tài)以及計(jì)算密集型函數(shù)。

所有這些子系統(tǒng)都通過 Timestone（一種大規(guī)模、低延遲的優(yōu)先級(jí)隊(duì)列系統(tǒng)）進(jìn)行異步通信。每個(gè)子系統(tǒng)處理服務(wù)的不同關(guān)注點(diǎn)，并且可以通過專門構(gòu)建的托管持續(xù)交付流程獨(dú)立部署。這種關(guān)注點(diǎn)的分離使得編寫、測(cè)試和操作 Cosmos 服務(wù)更加容易。

（平臺(tái)與應(yīng)用程序分離）

Cosmos 服務(wù)請(qǐng)求

（Cosmos 服務(wù)請(qǐng)求的跟蹤圖）

上圖是我們的觀察門戶網(wǎng)站 Nirvana 的截圖。它展示了 Cosmos 中的一個(gè)典型服務(wù)請(qǐng)求（在本例中是一個(gè)視頻編碼器服務(wù)）：

• 有一個(gè)用于編碼的 API 調(diào)用，其中包括視頻源和“配方”。
• 視頻被分成 31 個(gè)塊，并且有 31 個(gè)編碼函數(shù)并行運(yùn)行。
• 組裝函數(shù)只被調(diào)用一次。
• 索引函數(shù)只被調(diào)用一次。
• 8 分鐘后工作流完成。

服務(wù)分層

Cosmos 支持服務(wù)的分解和分層。由此產(chǎn)生的模塊化架構(gòu)允許團(tuán)隊(duì)專注于他們自己的專業(yè)領(lǐng)域，并控制自己的 API 和發(fā)布周期。

例如，上面提到的視頻服務(wù)只是眾多用于創(chuàng)建可在設(shè)備上播放的流的服務(wù)之一。這些服務(wù)還包括檢查、音頻、文本和包裝，它們是用更高級(jí)別的服務(wù)精心編排的。其中最大、最復(fù)雜的是 Tapas，它負(fù)責(zé)從工作室獲取資源，并使這些資源可以在 Netflix 服務(wù)上播放。另一個(gè)高級(jí)服務(wù)是 Sagan，它用于工作室的操作，如營(yíng)銷剪輯或日常制作編輯代理等。

（Cosmos 服務(wù)分層）

當(dāng)制作工作室有新作品時(shí)，它會(huì)觸發(fā)一個(gè) Tapas 工作流，該工作流會(huì)編排執(zhí)行檢查的請(qǐng)求、編碼視頻（多種分辨率、質(zhì)量、視頻編解碼器）、編碼音頻（多種質(zhì)量、編解碼器）、生成字幕（多種語(yǔ)言）并打包結(jié)果輸出（多個(gè)播放器格式）。因此，對(duì) Tapas 的單個(gè)請(qǐng)求可能導(dǎo)致對(duì)其他 Cosmos 服務(wù)的數(shù)百個(gè)請(qǐng)求以及數(shù)千個(gè) Stratum 函數(shù)調(diào)用。

下面的跟蹤示例展示了一個(gè)頂級(jí)服務(wù)中的請(qǐng)求是如何向下流到較低級(jí)別的服務(wù)中，從而導(dǎo)致許多不同操作的。在這種情況下，請(qǐng)求需要 24 分鐘才能完成，數(shù)百個(gè)不同的行動(dòng)涉及 8 個(gè)不同的 Cosmos 服務(wù)和 9 個(gè)不同的 Stratum 函數(shù)。

（通過多個(gè)層的服務(wù)請(qǐng)求跟蹤圖）

工作流規(guī)則

或者我們應(yīng)該說(shuō)是一些工作流規(guī)則？Plato 是一種粘合劑，它通過為服務(wù)開發(fā)人員提供一個(gè)定義領(lǐng)域邏輯和編排無(wú)狀態(tài)函數(shù) / 服務(wù)的框架來(lái)將 Cosmos 中的一切內(nèi)容聯(lián)系在一起。Optimus API 層具有內(nèi)置的工具，可以調(diào)用工作流并檢查它們的狀態(tài)。Stratum 的 Serverless 層生成強(qiáng)類型的 RPC 客戶端，使調(diào)用 Serverless 函數(shù)變得簡(jiǎn)單且直觀。

Plato 是一個(gè)前向鏈接規(guī)則引擎，它有助于我們算法的異步性和計(jì)算密集性。與 Netflix 的 Conductor 這樣的程序化工作流引擎不同，Plato 使創(chuàng)建“始終在線”（“always on”）的工作流變得更容易。例如，當(dāng)我們開發(fā)出更好的編碼算法時(shí)，我們基于規(guī)則的工作流會(huì)自動(dòng)管理更新現(xiàn)有的視頻，而無(wú)需觸發(fā)和管理新的工作流。此外，任何工作流都可以調(diào)用另一個(gè)工作流，從而實(shí)現(xiàn)上述服務(wù)的分層。

Plato 是一個(gè)多租戶系統(tǒng)（使用 Apache Karaf 實(shí)現(xiàn)），可以極大地減少操作工作流的操作負(fù)擔(dān)。用戶在自己的源代碼庫(kù)中編寫和測(cè)試他們的規(guī)則，然后通過將編譯后的代碼上傳到 Plato 服務(wù)端來(lái)部署工作流。

開發(fā)人員通過用 Emirax（一種基于 Groovy 構(gòu)建的特定領(lǐng)域語(yǔ)言）編寫的一組規(guī)則來(lái)指定他們的工作流，每條規(guī)則有 4 個(gè)部分：

• 匹配（match）：指定要觸發(fā)此規(guī)則必須滿足的條件。
• 動(dòng)作（action）：指定觸發(fā)該規(guī)則時(shí)要執(zhí)行的代碼；在這里，你可以調(diào)用 Stratum 函數(shù)來(lái)處理請(qǐng)求。
• 響應(yīng)（reaction）：指定當(dāng)動(dòng)作代碼成功完成時(shí)要執(zhí)行的代碼。
• 錯(cuò)誤（error）：指定遇到錯(cuò)誤時(shí)要執(zhí)行的代碼。

在這些部分中，你通常首先要記錄工作流狀態(tài)的變化，然后執(zhí)行使工作流向前推移的步驟，例如，執(zhí)行 Stratum 函數(shù)或返回執(zhí)行結(jié)果。

延遲敏感型應(yīng)用程序

像 Sagan 這樣的 Cosmos 服務(wù)對(duì)延遲敏感，因?yàn)樗鼈兪敲嫦蛴脩舻摹＠?#xff0c;一位正在制作社交媒體帖子的藝術(shù)家，在剪輯最新一季的 《紙鈔屋》（Money Heist）的視頻時(shí)不想等太久。對(duì)于 Stratum，延遲是執(zhí)行工作的時(shí)間加上獲取計(jì)算資源的時(shí)間的函數(shù)。當(dāng)工作非常繁忙時(shí)（通常是這樣），“獲取資源的時(shí)間”就成為了重要因素。舉個(gè)例子，假設(shè)你購(gòu)物時(shí)通常會(huì)買衛(wèi)生紙。正常情況下，把它放進(jìn)購(gòu)物車，通過收銀臺(tái)是沒有問題的，整個(gè)過程需要你花費(fèi) 30 分鐘。

（資源稀缺）

然后有一天，一種糟糕的病毒爆發(fā)了，并且每個(gè)人都決定要買更多的衛(wèi)生紙。由于總需求超過了可用容量，你衛(wèi)生紙的延遲時(shí)間現(xiàn)在從 30 分鐘增加到了兩周。Cosmos 應(yīng)用程序（尤其是 Stratum 函數(shù)）在面對(duì)突發(fā)和不可預(yù)測(cè)的需求時(shí)也有同樣的問題。Stratum 通過以下幾種方式來(lái)管理函數(shù)的執(zhí)行延遲：

• 資源池（Resource pools）。最終用戶可以為自己的業(yè)務(wù)用例保留 Stratum 計(jì)算資源，并且資源池是分層的，允許用戶組共享資源。
• 容量預(yù)熱（Warm capacity）。最終用戶可以提前請(qǐng)求計(jì)算資源（例如容器），以減少 Stratum 中的啟動(dòng)延遲。
• 微批次（Micro-batches）。Stratum 還使用微批次處理，這是在 Apache Spark 等平臺(tái)上學(xué)到的一種減少啟動(dòng)延遲的技巧。其思想是將啟動(dòng)成本分?jǐn)偟皆S多函數(shù)調(diào)用中。如果你調(diào)用函數(shù) 10000 次，那么該函數(shù)可能在 10000 個(gè)容器上運(yùn)行一次，也可能在 1000 個(gè)容器上運(yùn)行 10 次。
• 優(yōu)先級(jí)（Priority）。當(dāng)需要在成本和低延遲的需求之間進(jìn)行平衡時(shí)，Cosmos 服務(wù)通常會(huì)落在中間的某個(gè)位置：有足夠的資源來(lái)處理典型的突發(fā)事件，但沒有足夠的資源來(lái)處理延遲最低的最大突發(fā)事件。通過對(duì)工作進(jìn)行優(yōu)先級(jí)排序，即使在資源短缺的情況下，應(yīng)用程序仍可以確保以較低的延遲處理最重要的工作。Cosmos 服務(wù)所有者可以允許最終用戶設(shè)置優(yōu)先級(jí)，或者在 API 層或工作流中自己設(shè)置優(yōu)先級(jí)。

吞吐量敏感型應(yīng)用程序

像 Tapas 這樣的服務(wù)對(duì)吞吐量非常敏感，因?yàn)樗鼈儠?huì)消耗大量的計(jì)算資源（例如每天數(shù)百萬(wàn)個(gè) CPU 小時(shí)），并且更關(guān)心一段時(shí)間內(nèi)（數(shù)小時(shí)或數(shù)天內(nèi)）完成的任務(wù)，而不是完成單個(gè)任務(wù)的時(shí)間。換句話說(shuō)，服務(wù)等級(jí)目標(biāo)（SLO）是以每天的任務(wù)和每項(xiàng)任務(wù)的成本來(lái)衡量的，而不是以每秒的任務(wù)來(lái)衡量的。

對(duì)于吞吐量敏感的工作負(fù)載，最重要的 SLO 是由 Stratum 的 Serverles 層提供的。構(gòu)建在 Titus 容器平臺(tái)之上的 Stratum 允許吞吐量敏感的工作負(fù)載通過靈活的資源調(diào)度使用“機(jī)會(huì)主義”計(jì)算資源。例如，如果一個(gè) Serverles 函數(shù)調(diào)用愿意等待一個(gè)小時(shí)再執(zhí)行，那么它的成本可能會(huì)更低。

Strangler Fig

我們知道，移動(dòng)一個(gè)像 Reloaded 這樣龐大而復(fù)雜的遺留系統(tǒng)將是一個(gè)跨越危險(xiǎn)鴻溝的大躍進(jìn)，這個(gè)鴻溝里到處都是失敗的重新設(shè)計(jì)后的項(xiàng)目碎片，但毫無(wú)疑問，我們必須跳下去。為了降低風(fēng)險(xiǎn)，我們采用了 Strangler Fig（絞殺榕）模式，讓新系統(tǒng)圍繞舊系統(tǒng)擴(kuò)展，并最終完全取代舊系統(tǒng)。

仍然在學(xué)習(xí)

我們于 2018 年開始建造 Cosmos，并從 2019 年初開始投入生產(chǎn)。今天，我們大約有 40 個(gè) Cosmos 服務(wù)，并且預(yù)計(jì)還會(huì)增長(zhǎng)更多。我們?nèi)蕴幱谥衅陔A段，但我們可以分享一些我們迄今為止所學(xué)到的重點(diǎn)知識(shí)：

1. Netflix 的文化起到了關(guān)鍵的作用

眾所周知，Netflix 的工程文化依賴于個(gè)人判斷，而不是自上而下的控制。軟件開發(fā)人員有承擔(dān)風(fēng)險(xiǎn)和做出決策的自由和責(zé)任。我們中沒有人有軟件架構(gòu)師的頭銜；我們所有人都在扮演著這個(gè)角色。在這種背景下，Cosmos 從局部?jī)?yōu)化的不同嘗試中脫穎而出。Optimus、Plato 和 Stratum 是獨(dú)立構(gòu)思的，并最終整合成一個(gè)單一的平臺(tái)愿景。團(tuán)隊(duì)中的應(yīng)用程序開發(fā)人員讓每個(gè)人都專注于用戶友好的 API 和開發(fā)人員的生產(chǎn)力。基礎(chǔ)設(shè)施和媒體算法開發(fā)人員之間建立了強(qiáng)有力的合作關(guān)系，才將愿景變?yōu)楝F(xiàn)實(shí)。我們不可能在自上而下的工程環(huán)境中做到這一點(diǎn)。

2. 微服務(wù) + 工作流 + Serverless

我們發(fā)現(xiàn)，“觸發(fā)編排 Serverless 函數(shù)工作流的微服務(wù)”的編程模型是一個(gè)強(qiáng)大的范式。它適用于我們的大多數(shù)用例，但有些應(yīng)用程序非常簡(jiǎn)單，以至于由此而增加復(fù)雜性是不值得的。

3. 平臺(tái)心態(tài)

從大型分布式應(yīng)用程序遷移到“平臺(tái) + 應(yīng)用程序”是一個(gè)重大的范式轉(zhuǎn)變。每個(gè)人都必須改變他們的心態(tài)。應(yīng)用程序開發(fā)人員必須放棄一定的靈活性，以換取一致性、可靠性等。平臺(tái)開發(fā)人員必須培養(yǎng)更多的同理心，并優(yōu)先考慮客戶服務(wù)、用戶生產(chǎn)力和服務(wù)等級(jí)。有時(shí)候，應(yīng)用程序開發(fā)人員會(huì)感到平臺(tái)團(tuán)隊(duì)沒有適當(dāng)?shù)貙Ｗ⒂谒麄兊男枨?#xff0c;而有時(shí)候，平臺(tái)團(tuán)隊(duì)卻因用戶需求而感到負(fù)擔(dān)過重。我們彼此坦誠(chéng)相待，度過了這些難關(guān)。例如，在最近的一次回顧之后，我們加強(qiáng)了橫切系統(tǒng)質(zhì)量的開發(fā)跟蹤，例如開發(fā)人員的經(jīng)驗(yàn)、可靠性、可觀察性和安全性。

4. 平臺(tái)獲勝

我們創(chuàng)建 Cosmos 的目的是讓開發(fā)人員能夠更好更快地工作，將更多的時(shí)間花在解決業(yè)務(wù)問題上，而減少處理基礎(chǔ)設(shè)施的時(shí)間。有時(shí)目標(biāo)似乎遙不可及，但我們開始看到我們所希望的成果。在 Cosmos 中，開發(fā)人員最喜歡的一些系統(tǒng)特性是托管交付、模塊化、可觀察性和開發(fā)人員支持。我們正在努力使這些品質(zhì)變得更好，同時(shí)也在致力于薄弱環(huán)節(jié)，如本地開發(fā)、彈性和可測(cè)試性。

未來(lái)的規(guī)劃

2021 年對(duì) Cosmos 來(lái)說(shuō)將是重要的一年，因?yàn)槲覀儠?huì)將大部分工作從 Reloaded 轉(zhuǎn)移到 Cosmos 中，這將帶來(lái)更多的開發(fā)人員和更高的負(fù)載。我們計(jì)劃改進(jìn)編程模型以適應(yīng)新的用例。我們的目標(biāo)是使 Cosmos 更易于使用，更具彈性，更快，更有效。請(qǐng)繼續(xù)關(guān)注，以了解更多有關(guān) Cosmos 是如何工作以及我們是如何使用它的細(xì)節(jié)。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的微服务+异步工作流+ Serverless，Netflix 决定弃用稳定运行 7 年的旧平台的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。