Netflix Cosmos平臺：微服務+工作流+無伺服器

Cosmos是一個計算平臺，將微服務的最佳方面與非同步工作流和無伺服器函式結合在一起。它的優點是應用程式涉及資源密集型演算法，這些演算法通過複雜的層次化工作流進行協調，持續時間長達數分鐘到數年不等。它既支援一次消耗數十萬個CPU的高吞吐量服務，又支援對延遲敏感的工作負載，在這些負載下，人們正在等待計算結果。

本文將說明我們構建Cosmos的原因，其工作方式並分享我們在此過程中學到的一些知識。

概述

Cosmos服務不是微服務，但是有相似之處。Cosmos服務保留了微服務的強大合同和隔離的資料/依賴關係，但新增了多步工作流和計算密集型非同步無伺服器功能。

傳統的微服務是具有無狀態業務邏輯的API，該API可根據請求負載自動縮放。該API與對等方提供了強有力的合同，同時將應用程式資料和二進位制依賴項與其他系統隔離開來。

在Cosmos服務的下圖中，客戶端將請求傳送到視訊編碼器服務API層。一組規則協調工作流步驟，以及一組無伺服器功能為特定於域的演算法提供支援。函式打包為Docker映像，並帶來它們自己的特定於媒體的二進位制依賴性（例如，debian軟體包）。它們根據佇列大小進行縮放，並且可以在成千上萬個不同的容器上執行。請求可能需要幾個小時或幾天才能完成。

關注點分離

Cosmos有兩個分離軸。一方面，邏輯在API，工作流和無伺服器功能之間劃分。另一方面，邏輯在應用程式和平臺之間是分開的。平臺API為應用程式開發人員提供了特定於媒體的抽象，同時隱藏了分散式計算的詳細資訊。例如，視訊編碼服務由與規模無關的元件構成：API，工作流和功能。

他們沒有關於其經營規模的專門知識。這些特定於域的，與規模無關的元件是建立在三個可感知規模的Cosmos子系統之上的，這些子系統處理分配工作的細節：

• Optimus，一個將外部請求對映到內部業務模型的API層。
• Plato，用於業務規則建模的工作流層。
• Stratum，一個無伺服器層，要求執行無狀態和計算密集型功能。

子系統都通過Timestone（一種大規模，低延遲優先順序排隊系統）彼此非同步通訊。每個子系統都解決了服務的不同問題，並且可以通過專門構建的託管連續交付流程來獨立部署。關注點的分離使編寫，測試和操作Cosmos服務變得更加容易。

工作流規則

Plato是通過為服務開發人員提供一個定義域邏輯和協調無狀態功能/服務的框架，將Cosmos中的所有內容聯絡在一起的粘合劑。

Plato是一個前向連結規則引擎，可使其適用於我們演算法的非同步和計算密集型性質。與Netflix的Conductor這樣的過程性工作流引擎不同，Plato使建立“始終線上”的工作流變得容易。例如，隨著我們開發更好的編碼演算法，基於規則的工作流程將自動管理更新現有視訊，而無需觸發和管理新的工作流程。此外，任何工作流程都可以呼叫另一個工作流程，從而實現了上述服務的分層。

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

開發人員通過以Emirax（一種基於Groovy構建的領域特定語言）編寫的規則來指定其工作流程。每個規則有4個部分：

• match：指定觸發此規則必須滿足的條件
• 動作：指定觸發該規則時要執行的程式碼；在這裡，您可以呼叫Stratum函式來處理請求。
• reaction：指定操作程式碼成功完成時要執行的程式碼
• 錯誤：指定遇到錯誤時要執行的程式碼。

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

我們於2018年開始構建Cosmos，並自2019年初開始投入生產。Optimus，Plato和Stratum是獨立構思的，最終融合為一個平臺的願景。團隊中的應用程式開發人員使每個人都專注於使用者友好的API和開發人員的生產力。基礎架構和媒體演算法開發人員之間建立了牢固的夥伴關係，以將願景變為現實。我們不可能在自上而下的工程環境中做到這一點。

微服務+工作流程+無伺服器

我們已經發現，“觸發工作流對無伺服器函式編排的微服務”的程式設計模型是一個強大的範例。它對我們的大多數用例都適用，但是某些應用程式非常簡單，以至於增加的複雜性是不值得的。

更多點選標題見原文。