Netflix如何在雲端使用事件溯源實現可靠的物聯網裝置管理？

在 Netflix，從流媒體棒到智慧電視，每天都會通過自動化測試數百種不同的裝置型別，需要確保新軟體版本繼續提供我們客戶喜歡的 Netflix 體驗質量。此外，Netflix 不斷與其合作伙伴（如 Roku、三星、LG、亞馬遜）合作，將 Netflix SDK 移植到他們的新裝置和即將推出的裝置（電視、智慧盒子等），以確保在允許裝置上的 Netflix 應用程式可以走出去走向世界。Netflix 的合作伙伴基礎設施團隊提供解決方案，通過大規模啟用裝置管理來支援這兩項重大工作。

背景

為了規範 Netflix 和合作夥伴網路中網路環境的多樣性，並建立一個一致且可控的計算環境，使用者可以在該環境上對裝置執行迴歸和 Netflix 應用程式認證測試，合作伙伴基礎設施團隊提供了一個定製的嵌入式計算機，稱為參考自動化環境。 (RAE)。硬體的補充是 RAE 和雲端的軟體，橋接兩端的軟體是雙向控制平面。它們共同構成了裝置管理平臺，這是Netflix Test Studio (NTS)的基礎設施。然後使用者通過以即插即用的方式將他們的裝置連線到 RAE 來有效地執行測試。

該平臺允許大規模有效的裝置管理，其功能集大致分為兩個領域：

1. 為控制裝置及其環境（硬體和軟體拓撲）提供服務級抽象。
2. 收集和彙總連線到佇列中 RAE 的所有裝置的資訊和狀態更新。在這篇博文中，我們將重點介紹後一個功能集。

在連線到 RAE 的裝置的整個生命週期中，裝置可以隨時更改屬性。例如，在執行測試時，裝置的狀態將從“可用於測試”變為“在測試中”。此外，由於這些裝置中有許多是預生產裝置，因此會經常更改韌體，因此生產裝置中通常是靜態的屬性有時也會發生變化，例如分配給的 MAC 地址和電子序列號 (ESN)。裝置上的 Netflix 安裝。

因此，能夠使裝置資訊保持最新以便裝置測試正常工作是非常關鍵的。在裝置管理平臺中，這是通過將裝置更新設為事件源來實現的通過控制平面到雲，以便 NTS 將始終擁有有關可用於測試的裝置的最新資訊。那麼，挑戰在於能夠以可擴充套件的方式攝取和處理這些事件，即隨著裝置數量的增加而擴充套件，這將是本博文的重點。

下圖總結了架構描述：

RAE 配置為有效地成為被測裝置 (DUT) 所連線的路由器。在 RAE 上，有一個稱為 Local Registry 的服務，它負責檢測、載入和維護有關連線到 RAE 的 LAN 側的所有裝置的資訊。當連線新的硬體裝置時，Local Registry 會檢測並收集有關它的一組資訊，例如網路資訊和 ESN。本地登錄檔定期探測裝置以檢查其連線狀態。隨著裝置屬性和屬性隨時間發生變化，這些更改將儲存到本地登錄檔中，並同時向上遊釋出到裝置管理平臺的控制平面。除了屬性變化，本地註冊中心定期向上遊釋出裝置記錄的完整快照，作為狀態協調的一種形式。這些檢查點事件使資料饋送的消費者能夠更快地重建狀態，同時防止錯過更新。

在雲端，名為 Cloud Registry 的服務會攝取 Local Registry 例項釋出的裝置資訊更新，對其進行處理，然後將物化資料推送到CockroachDB支援的資料儲存中。之所以選擇 CockroachDB 作為後備資料儲存，是因為它提供了 SQL 功能，並且我們的裝置記錄資料模型已經過規範化。此外，與其他 SQL 儲存不同，CockroachDB 從頭開始​​設計為可水平擴充套件，這解決了我們對 Cloud Registry 能夠隨著裝置管理平臺上載入的裝置數量進行擴充套件的能力的擔憂。

控制平面

MQTT構成裝置管理平臺控制平面的基礎。MQTT 是用於物聯網 (IoT) 的 OASIS 標準訊息傳遞協議，被設計為高度輕量級但可靠的釋出/訂閱訊息傳遞傳輸，非常適合連線具有少量程式碼佔用和最小網路頻寬的遠端裝置。

MQTT 客戶端連線到 MQTT 代理併傳送帶有主題字首的訊息。相比之下，代理負責接收所有訊息，過濾它們，確定誰訂閱了哪個主題，並相應地將訊息傳送給訂閱的客戶端。使 MQTT 對我們非常有吸引力的關鍵特性是它支援分層主題、客戶端身份驗證和授權、每個主題的 ACL 以及雙向請求/響應訊息模式，

在控制平面內，裝置命令和裝置資訊更新以主題字串為字首，該主題字串包括 RAE 序列號和device_session_id，這是與裝置會話對應的 UUID。將這兩部分資訊嵌入到每條訊息的主題中，使我們能夠應用主題 ACL 並有效控制使用者可以看到哪些 RAE 和 DUT 並與之互動，以安全和隔離其他使用者的裝置。

由於Kafka是 Netflix 支援的訊息傳遞平臺，因此在兩個協議之間建立了一座橋樑，以允許雲端服務與控制平面進行通訊。通過橋接器，MQTT 訊息直接轉換為 Kafka 記錄，其中記錄鍵設定為訊息分配到的 MQTT 主題。由於在 MQTT 上釋出的裝置資訊更新包含device_session_id在主題中，這意味著給定裝置會話的所有裝置資訊更新將有效地出現在同一個 Kafka 分割槽上，從而為我們提供了一個明確定義的訊息消費順序。

 。。。

採用流處理框架

有許多框架可用於可靠的流處理以整合到 Web 服務中（例如，Kafka Streams、Spring[url=https://docs.spring.io/spring-kafka/reference/html/]KafkaListener[/url]、Project Reactor、Flink、Alpakka-Kafka等等）。我們選擇 Alpakka-Kafka 作為 Kafka 處理解決方案的基礎，原因如下。

1. 事實證明，Alpakka-Kafka 可以滿足我們提出的所有系統要求，包括對 Netflix Spring 整合的需求。它還進一步提供了對流處理的高階和細粒度控制，包括自動背壓支援和流監控。
2. 與可能滿足我們所有系統需求的其他解決方案相比，Akka 是一個更加輕量級的框架，它與 Spring Boot 應用程式的整合相對較短和簡潔。此外，Akka 和 Alpakka-Kafka 程式碼比其他解決方案簡潔得多，這降低了維護人員的學習曲線。
3. 基於 Alpakka-Kafka 的解決方案隨著時間的推移維護成本遠低於其他解決方案，因為 Akka 和 Alpakka-Kafka 在文件和社群支援方面都是成熟的生態系統，已經存在至少 12 年和 6 年年，分別。

基於Alpakka的Kafka處理流水線的構建可以用下圖來概括：

。。。。

更多點選標題見原文。

結論

Kafka 流處理可能很難正確處理。許多系統實現細節需要根據業務需求來考慮。幸運的是，Akka 流和 Alpakka-Kafka 提供的原語使我們能夠通過構建與我們現有的業務工作流相匹配的流解決方案，同時在構建和維護這些解決方案時提高開發人員的生產力來實現這一目標。藉助 Cloud Registry 中基於 Alpakka-Kafka 的處理器，我們確保了控制平面消費者端的容錯能力，這是在裝置管理平臺內實現準確可靠的裝置狀態聚合的關鍵。

雖然我們實現了訊息容錯消費，但這只是裝置管理平臺設計和實現的一個方面。平臺及其控制平面的可靠性取決於在多個領域所做的重要工作，包括 MQTT 傳輸、身份驗證和授權以及系統監控，我們計劃在未來的部落格文章中詳細討論所有這些。同時，作為這項工作的結果，隨著我們將越來越多的裝置加入我們的系統，我們可以預期裝置管理平臺會隨著時間的推移繼續擴充套件以增加工作負載。