云原生正在徹底改變應用程序和服務的交付方式，云原生計算基金會 (CNCF)在推動行業內的標準化和供應商中立解決方案方面做得很好。在最近的一篇文章中，我們從上到下探索了 CNCF 的云原生工具格局。我們在那里討論的工具和技術將在未來幾年塑造云原生的面貌。

云原生流媒體和消息服務是該領域最重要的方面之一。這些服務充當云原生的中間件。作為“云原生的中間件”，它們使微服務能夠在保持松散耦合和輕量級的情況下進行通信。在這篇文章中，我們將定義云原生消息傳遞和流媒體，探索它們的用例，并討論當今可用的一些流行的流媒體和消息傳遞應用程序。

什么是云原生消息傳遞？

在我們構建云原生流之前，讓我們先解釋一下云原生消息傳遞。云原生消息傳遞是一種通信模型，可在微服務之間實現基于異步推送的通信。

那么它是怎樣工作的？

正如您所預料的那樣，一旦深入了解具體細節，消息傳遞就會變得相當復雜，但讓我們從基礎開始。

在高層次上，使用消息服務發送信息包含 3 個關鍵組件：

• 生產者——創建消息并將它們發送給代理。
• 經紀人 - 從消費者那里接收消息并將其分發給消費者。代理負責隊列、路由消息和協議之間的轉換。
• 消費者 - 從代理接收消息。

這看起來很簡單，但是代理如何確定應將哪些消息路由到特定的消費者？實現各不相同，這就是大部分復雜性所在。消息傳遞的發布/訂閱方法在云原生中廣泛使用，以概念化該過程。首先，消息按“主題”排序。生產者（發布者）然后將消息發送到特定主題，代理將它們路由到訂閱該主題的消費者（訂閱者）。

云原生消息傳遞的優勢

剛接觸云原生消息傳遞的人常問的一個問題是“HTTP 和 RESTful API 無處不在，我為什么要使用消息傳遞服務？”?簡短的回答是，消息傳遞支持微服務之間的輕量級、可擴展、事件驅動的通信。要了解原因，讓我們來看看一些具體的好處。

• 啟用一對多和多對一通信 - 通過異步通信，單個消息或事件可以廣播給許多消費者。同樣，來自多個生產者的消息可以發送給單個消費者，比如一個數據庫。消息服務為基于拉的同步架構（如 RESTful API）提供了一種更簡單的替代方案。它還減少了消息生產者的工作量。
• 安全性——使用消費者和生產者之間的代理，無需公開 API 來啟用服務之間的通信。生產者和消費者可以互不相識。
• 松耦合和可擴展性——松耦合是健全的微服務架構的核心原則。使用 RESTful API，客戶端應用程序必須“知道”服務器端 API 的工作方式以及要查詢的端點。通過消息傳遞，服務不需要任何關于彼此的信息；他們只需要連接到經紀人。

當然，這并不是說我們應該取消 RESTful API。這里的要點是了解適合這項工作的正確工具。

常見的云原生消息傳遞協議

與 HTTP(S) 獲勝的 API 空間不同，云原生應用程序沒有單一的“消息傳遞協議”。了解哪種協議對您的應用程序有意義需要了解不同的選項，所以讓我們來看看三種最常見的消息傳遞協議并探索它們的用例。

AMQP

AMQP（Advanced Message Queuing Protocol）是當今最流行的云原生消息協議，幾乎已經成為事實上的標準。AMQP 具有高度可擴展性，如幾個真實世界的用例所證明，包括 NASA 的 Nebula 云計算服務和 JP Morgan Chase，據報道 AMQP 每天發送 10 億條消息。除了可擴展性之外，AMQP 還支持對消息路由進行精細控制，并具有強大的功能集。如果您需要支持復雜的路由和消息傳遞或超可擴展性，AMQP 可能是正確的選擇。

MQTT

MQTT（消息隊列遙測傳輸）是一種輕量級消息傳遞協議，旨在減少帶寬消耗和資源利用率。因此，MQTT 是物聯網和 M2M（機器對機器）通信領域的熱門選擇。如果您正在設計優先考慮資源消耗和簡單性的應用程序，MQTT 是一個很好的選擇。

踩踏

STOMP（簡單/流式文本導向消息傳遞協議）是 AMQP 和 MQTT 的一種轉變。STOMP 是本著 HTTP 的精神設計的：一種基于文本的協議（AMQP 和 MQTT 都是二進制的），易于在客戶端實現并支持跨語言和平臺的互操作性。除了作為其他消息傳遞協議的簡單、基于文本的替代方案之外，STOMP 還具有許多新穎的用例。

什么是云原生流？

云原生流是對連續數據流的處理，常用于海量數據。作為一個粗略的類比，流式傳輸之于消息傳遞就像 NoSQL 之于關系數據庫。云原生流式傳輸與云原生消息傳遞有許多相似之處，并且許多操作方面都是相同的。流式傳輸是異步的，有消費者和生產者，并使用帶有“主題”的發布/訂閱模型。

那么，云原生流媒體和消息傳遞之間有什么區別？

• 使用單個“日志”——與具有離散消息 ID 的離散消息不同，使用流式傳輸時，給定主題中的數據將附加到日志中。事件僅通過它們在日志中的位置來標識。
• 消費者比代理“更聰明”——流媒體服務將大部分工作卸載給消費者，而不是讓代理處理大部分業務邏輯。消費者負責跟蹤他們消費了哪些流和訂閱了哪些主題。
• 保留歷史數據- Streaming 使消費者能夠讀取歷史數據。使用傳統的消息傳遞，無法倒帶舊消息。使用流媒體服務，數據會保留一段時間，消費者可以提取歷史信息。

云原生流式傳輸的優勢

有了這個定義，流媒體的一些好處可能會變得清晰起來。與消息傳遞相比，流式傳輸的優勢包括：

• 速度和性能——像 Apache Kafka 這樣的流媒體服務每秒可以處理數百萬條消息，計算資源比消息服務少。
• 數據持久性——通過流式傳輸，數據得以保留，以便消費者可以“重播”以前的事件。
• “無限”輸入的處理——流設計用于處理連續數據流。它適用于 GPS 或溫度傳感器數據等大容量數據流。

鑒于這些好處，很容易理解為什么流式處理在大數據分析和高性能計算領域得到了廣泛采用。

流行的云原生流媒體和消息服務

了解什么是云原生流媒體和消息傳遞后，讓我們來看看在現實世界中用于實現它們的一些軟件。

NATS

NATS是 CNCF 孵化的開源消息代理，其人氣正在飆升。正如凱文霍夫曼在他的Capital One Tech Medium 帖子中所描述的那樣，NATS 在云原生消息傳遞世界中占據了一個獨特的位置。它為開發人員提供了一種輕量級、簡單且基于文本的消息傳遞方法。它使用傳統的發布/訂閱方法進行消息傳遞，提供請求/回復機制。除了啟用簡單的部署模型外，NATS 還擁有比消息和流媒體領域的許多知名公司（包括 Kafka 和 Redis）更高的代理吞吐量。

兔MQ

RabbitMQ是一種開源消息代理，支持 AMQP、MQTT、STOMP 以及 HTTP 和 WebSockets（雖然 HTTP 并不是真正的消息傳遞協議，但存在用于瀏覽器集成和低容量消息傳遞的用例）。RabbitMQ 是業內部署最廣泛、最值得信賴的代理之一，被小型和大型企業所采用。

除了作為一個成熟、可擴展且可靠的平臺之外，RabittMQ 還具有許多使其對云原生用例具有吸引力的特性。可以使用 Chef 和 Puppet 等編排工具部署 RabittMQ。此外，它支持多種語言，包括 Java、Python、Go 和 .NET，并且集群和聯合支持跨多個區域的分布式、高可用性 (HA) 部署。

阿帕奇卡夫卡

近年來，Apache Kafka的人氣飆升。雖然它最初是作為一種消息服務（并且今天仍然支持“傳統”消息），但它已經發展成為一種強大的云原生流服務，能夠每秒處理數百萬個事件。Kafka 在云原生領域的常見用例包括日志聚合（想想 Hadoop 和其他高度分布式文件系統）和流處理。

結論

從容器化和微服務到分布式數據庫，云原生正在改變軟件工程的完成方式。為了保持競爭力，應用程序開發人員必須了解如何設計健壯、有彈性的分布式服務。通過使微服務能夠以松散耦合和輕量級的方式進行通信，流式傳輸和消息傳遞是實現這一目標的重要部分。