云原生正在彻底改变应用程序和服务的交付方式，云原生计算基金会 (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 和其他高度分布式文件系统）和流处理。
结论
从容器化和微服务到分布式数据库，云原生正在改变软件工程的完成方式。为了保持竞争力，应用程序开发人员必须了解如何设计健壮、有弹性的分布式服务。通过使微服务能够以松散耦合和轻量级的方式进行通信，流式传输和消息传递是实现这一目标的重要部分。
