Streaming & Messaging #

为了实现共同的目标，服务需要相互通信并相互通知。每当一个服务执行某个操作时，它会发送一条关于该特定事件的消息。

流处理和消息传递工具通过在系统之间传递消息（即事件）来实现服务间的通信。各个服务可以连接到消息服务，执行发布事件、读取来自其他服务的消息，或同时进行两者。这种动态关系创造了一个环境，其中单个应用程序既可能是发布者，即负责编写事件的服务，也可能是订阅者，即负责读取事件的服务，或者更常见的是两者兼具。

解决的问题 #

随着服务不断增多，应用环境变得日益复杂，管理应用之间的通信也变得更加困难。流处理或消息传递平台提供了一个中心化的平台，用于发布和读取系统中发生的所有事件，使应用程序能够在彼此无需了解的情况下协同工作。

提供的帮助 #

当一个服务执行了其他服务需要了解的操作时，它会将事件“发布”到流处理或消息传递工具中。需要了解这些事件的服务会“订阅”并监控流处理或消息传递工具。这就是发布-订阅（简称 pub-sub）方法的本质，也是这些工具的核心功能之一。

通过引入一个管理所有通信的“中介”层，我们实现了服务之间的解耦。服务只需监听事件，执行相应操作，并发布新的事件。

以下是一个示例。当您首次注册 Netflix 时，“注册”服务会将一个“新注册事件”发布到消息传递平台，事件中包含姓名、电子邮件地址、订阅级别等详细信息。“账户创建”服务订阅了注册事件，它会接收到该事件并创建您的账户。同样，订阅了新注册事件的“客户通信”服务会将您的电子邮件地址添加到客户邮件列表中，并生成一封欢迎邮件，以此类推。

这种架构实现了高度解耦的系统，各服务可以在彼此无需了解的情况下协作。这种解耦使工程师能够在不更新下游应用（通常称为消费者）或发送大量查询的情况下添加新功能。系统解耦程度越高，其灵活性和可变性就越强，而这正是工程师在系统设计中追求的目标。

技术基础 #

消息传递和流处理工具早在云原生成为主流之前就已存在。为了集中管理关键业务事件，许多组织构建了大型企业服务总线（Enterprise Service Bus, ESB）。然而，当我们在云原生环境中谈论消息传递和流处理时，通常指的是像 NATS、RabbitMQ、Kafka 或云提供的消息队列这样的工具。

这些系统的共同点在于它们支持的架构模式。在云原生环境中，应用程序的交互通常分为两种模式：编排（orchestrated）和协作（choreographed）。简单来说，编排模式由中心化系统管理，而协作模式允许各个组件独立行动。

消息传递和流处理系统为协作系统提供了一个中心化的通信场所。消息总线作为一个通用平台，使所有应用程序都可以通过发布消息告诉其他应用自己在做什么，或者通过订阅消息了解当前的活动情况。

NATS 和 Cloudevents 项目是 CNCF 的孵化项目。其中，NATS 提供了一个成熟的消息系统，而 Cloudevents 致力于标准化系统间的消息格式。Strimzi、Pravega 和 Tremor 则是 CNCF 的沙箱项目，这些项目处于早期开发阶段，并各自针对流处理和消息传递的独特用例进行了优化。

Keywords #

• Choreography - 协作
• Streaming - 流处理
• MQ - 消息队列
• Message bus - 消息总线

Projects #