netflix是什么公司？

netflix是什么公司呢？這家公司主要做的是游戲，但是他們的業務范圍非常廣泛，不僅僅局限于游戲領域，還涉及電影、音樂、動漫等多個領域。在全球范圍內擁有超過1.5億玩家，每天都有大量的游戲產品上線。而騰訊也是國內最大的游戲公司，旗下的王者榮耀、和平精英等游戲深受玩家喜愛。。

一：netflix是什么公司

Netflix, Inc. (Nasdaq: NFLX) Netflix是一家在線影片租賃提供商。公司能夠提供超大數量的DVD，而且能夠讓顧客快速方便的挑選影片，同時免費遞送。Netflix已經連續五次被評為顧客最滿意的網站。可以通過PC、TV及iPad、iPhone收看電影、電視節目，可通過Wii，Xbox360，PS3等設備連接TV。Netflix大獎賽從2006年10月份開始，Netflix公開了大約1億個1－5的匿名影片評級，數據集僅包含了影片名稱，評價星級和評級日期，沒有任何文本評價的內容。比賽要求參賽者預測Netflix的客戶分別喜歡什么影片，要把預測的效率提高10%以上。

二：NETFLIX是什么

是投資，并不是制作。Netflix現在每季都會去找有潛力的日漫投資，直接出品整一季后放自家播放，不得不說有錢的作品質量確實不錯，起碼畫面是一線動畫的水準（財大氣粗）是投資，并不是制作。Netflix現在每季都會去找有潛力的日漫投資，直接出品整一季后放自家播放，不得不說有錢的作品質量確實不錯，起碼畫面是一線動畫的水準（財大氣粗）樓主你想問什么呢 建議把問題表達清楚 謝謝！<br

三：NETFLIX是什么軟件

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

介紹

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

（一個 Cosmos 服務）

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

背景

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

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

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

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

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

概述

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

（一個典型的微服務）

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

（一個典型的 Cosmos 服務）

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

所有這些子系統都通過 Timestone（一種大規模、低延遲的優先級隊列系統）進行異步通信。每個子系統處理服務的不同

（平臺與應用程序分離）

Cosmos 服務請求

（Cosmos 服務請求的跟蹤圖）

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

有一個用于編碼的 API 調用，其中包括視頻源和“配方”。視頻被分成 31 個塊，并且有 31 個編碼函數并行運行。組裝函數只被調用一次。索引函數只被調用一次。8 分鐘后工作流完成。服務分層

Cosmos 支持服務的分解和分層。由此產生的模塊化架構允許團隊專注于他們自己的專業領域，并控制自己的 API 和發布周期。

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

（Cosmos 服務分層）

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

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

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

工作流規則

或者我們應該說是一些工作流規則？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 分鐘。

（資源稀缺）

然后有一天，一種糟糕的病毒爆發了，并且每個人都決定要買更多的衛生紙。由于總需求超過了可用容量，你衛生紙的延遲時間現在從 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 更易于使用，更具彈性，更快，更有效。請繼續

本文為阿里云原創內容，未經允許不得