云原生应用程序中的同步和异步通信解码

云原生应用程序中的同步和异步通信解码
设计云原生应用程序涉及管理由微服务和无服务器组件组成的复杂系统，这些组件需要有效地相互通信。同步通信通过 HTTP 或 gRPC 调用，在指定的时间范围内等待响应，提供实时反馈，适用于需要立即响应的场景。异步通信利用消息代理（如 RabbitMQ 或 Kafka），交换消息而不要求立即响应，增强了系统的可扩展性。通过理解每种通信模式的优点和缺点，架构师可以设计出有效协调这些独立元素的系统，从而提供高性能、可扩展且可靠的云原生应用程序。
设计云原生应用程序涉及管理由微服务和无服务器组件组成的复杂系统，这些组件需要有效地相互通信。同步通信通过 http 或 grpc 调用，在指定的时间范围内等待响应，提供实时反馈，适用于需要立即响应的场景。异步通信利用消息代理（如 rabbitmq 或 kafka），交换消息而不要求立即响应，增强了系统的可扩展性。通过理解每种通信模式的优点和缺点，架构师可以设计出有效协调这些独立元素的系统，从而提供高性能、可扩展且可靠的云原生应用程序。

想象一下构建一台具有许多独立部件的复杂机器，每个部件都执行其功能，但所有部件都需要彼此有效地通信才能完成任务。这是我们在设计由互连的微服务和无服务器组件组成的云原生应用程序时面临的挑战。在本文中，我们探讨了设计强大且有弹性的通信系统的细节，该系统可以有效地协调应用程序边界内外的这些独立元素。

这些细粒度的服务采用各种同步或异步通信方法进行内部和外部交互。在同步通信中，一个服务使用 HTTP 或 gRPC 调用另一个服务，在指定的时间范围内等待响应，然后再继续。相反，异步通信涉及交换消息而不期望立即响应。 RabbitMQ 或 Kafka 等消息代理充当中介，缓冲消息以确保可靠传递。在云原生应用程序中，采用通信模式的组合通常是一种实用的方法。我们首先从同步通信开始。

什么是同步通信？

同步通信就像对话。一项服务（我们称之为服务 A）发起请求，然后等待另一项服务（服务 B）或外部 API 的响应。这类似于提出问题并等待答案。服务 A 通过 HTTP 发送请求并等待。它要么等待服务 B 的响应，要么等待最长等待时间到期。在此等待期间，服务 A 暂时被阻止，就像一个人暂停其活动以等待响应一样。这种模式通常称为请求-应答模式，实现起来相对简单。然而，广泛使用它可能会带来需要仔细考虑的挑战。

同步通信的挑战

虽然同步通信是我们的云原生工具包中的一个强大工具，但它也面临着一系列需要仔细考虑的挑战。

时间耦合

在整个解决方案中过度依赖同步通信可能会导致时间耦合问题。当大量同步调用链接在一起时，就会发生这种情况，导致客户端应用程序接收响应的等待时间延长。

可用性依赖性

同步通信需要所有通信服务同时可用。如果后端服务出现意外负载，客户端应用程序可能会因超时错误而出现故障，从而影响整体性能。

网络质量影响

网络质量可以直接影响同步通信的性能，包括可用带宽和响应在服务后端服务之间遍历所需的持续时间。

尽管存在这些挑战，同步通信在特定场景中仍具有无价的价值。让我们在下一节中探讨一些用例，其中同步通信可能是更好的选择。

何时使用同步通信

在某些情况下，使用同步通信可能是更好的选择。

实时数据访问或保证结果

当需要立即或实时反馈时，同步通信可以提高效率。例如，当客户在电子商务网站上下订单时，电子商务前端需要检查库存系统以确保该商品有库存。这是同步操作，因为应用程序需要等待库存系统的响应才能继续处理订单。

编排相关任务的顺序

在服务必须执行一系列任务（每个任务都依赖于前一个任务）的情况下，同步通信可以维持顺序。它特别适合任务顺序至关重要的工作流程。

维护交易完整性

当维护多个组件之间的数据一致性至关重要时，同步通信可以帮助维护原子事务。它与数据完整性至关重要的金融交易等场景相关。

同步通信是一个强大的工具，但也面临着挑战。好消息是，我们还可以选择异步通信——这是一种可以与同步方法一起工作的补充风格。让我们在下一节中进一步探讨这一点。

什么是异步通信？

异步通信模式为服务间通信提供了动态且高效的方法。与同步通信不同，异步通信允许服务发起请求而无需等待立即响应。在此模型中，响应可能不是立即的或异步到达单独的通道（例如回调队列）。这种通信模式依赖于高级消息队列协议 (AMQP) 等协议和消息中间件，包括消息代理或事件代理。 

该消息传递中间件充当具有最少业务逻辑的中介。它从源或生产者服务接收消息，然后将它们传送到预期的消费服务。集成消息中间件可以显着提高这种解耦方法的弹性和容错能力。异步通信包含各种实现。让我们进一步探讨这些。

一对一沟通

在一对一消息通信中，生产者使用消息代理将消息专门分派给接收者。通常，消息代理依靠队列来确保可靠的通信并提供传送保证，例如至少一次。该实现类似于命令模式，其中传递的消息充当订阅者服务使用的命令来触发操作。 

让我们考虑一个在线零售店的例子来说明它的用途。在线业务很大程度上取决于其网站的可靠性。该模式提供容错和消息保证，确保一旦客户在网站上下订单，后端履行系统就会收到要处理的订单。即使后端系统关闭，消息代理也会保留消息，并在可以处理这些消息时传送消息。例如，在电子商务应用程序中，当客户下订单时，可以使用消息代理将订单详细信息作为消息从订单服务（生产者）发送到履行服务（消费者）。这是一对一通信的示例。

云端异步一对一通信

一对一消息模式的扩展是异步请求-应答模式。在这种情况下，调度程序发送消息而不期望得到响应。但在一些特定场景中，使用者必须利用同一消息代理基础设施队列中的队列来响应生产服务。来自消费者的响应可能包含附加元数据，例如与初始请求或响应地址相关的 ID。由于生产者不期望立即响应，因此独立的生产者工作流程管理这些回复。订单发出后，履行服务（消费者）会响应前端订单服务（生产者），以便客户可以在网站上更新。

云端异步一对一请求回复通信

当两个服务点对点通信时，单一消费者通信会派上用场。但是，在某些情况下，发布者必须向多个订阅者发送特定事件，这导致我们出现以下模式。

一对多通信

当单个组件（发布者）需要将事件广播到多个组件和服务（订阅者）时，这种通信方式非常有价值。一对多通信使用主题的概念，类似于在线论坛。 

它就像一个在线论坛，多个用户可以在其中发布文章，他们的关注者可以在自己的时间阅读这些文章，并根据需要做出回应。同样，应用程序可以具有主题，生产者服务可以写入这些主题，而消费服务可以从该主题中读取。它是现实应用中最流行的模式之一。 

再次考虑电子商务平台有一个更新产品价格的服务，并且多个服务需要此信息（如订阅服务、推荐服务等），价格更新可以作为消息发送到消息代理中的主题。所有感兴趣的服务（订阅者）都可以收听该主题并接收价格更新。这是一对多通信的示例。有多种工具可用于实现此模式，其中 Apache Kafka、Redis Pub/Sub、Amazon SNS 和 Azure Event Grid 是最受欢迎的选择之一。

云端异步一对多通信

异步通信的挑战

虽然异步通信提供了许多好处，但它也带来了自己的一系列挑战。

弹性和容错能力

由于有大量的微服务和无服务器组件，每个组件都有多个实例，因此故障是不可避免的。实例可能会崩溃、不堪重负或出现暂时性故障。此外，发送方不会等待消息被处理，因此如果发生错误，它可能无法立即意识到。我们必须采取以下策略：

重试机制：针对暂时性故障重试失败的网络调用

断路器模式：防止重复调用失败的服务以避免资源瓶颈

分布式追踪

异步通信可以跨越多个服务，这使得监控整体系统性能变得具有挑战性。实施分布式跟踪有助于将日志和指标联系在一起以了解事务流。

复杂的调试和监控

异步通信可能更难以调试和监控，因为操作不遵循线性流程。通常需要专门的工具和技术来有效地调试和监控这些系统。

资源管理

异步系统通常涉及长期连接和后台处理，这可能会导致资源管理挑战。必须注意有效管理资源，以防止内存泄漏或 CPU 过度使用。

了解这些挑战有助于在云原生应用程序中设计更强大、更有弹性的异步通信系统。

最后的话

同步和异步通信模式之间的选择不是二元的，而是基于应用程序的特定要求的战略决策。

同步通信易于实现并提供即时反馈，使其适合实时数据访问、编排相关任务以及维护事务完整性。然而，它也面临着时间耦合、可用性依赖性和网络质量影响等挑战。

另一方面，异步通信允许服务发起请求而无需等待立即响应，从而增强了系统的响应能力和可扩展性。它提供了灵活性，非常适合不需要立即反馈的场景。然而，它带来了弹性、容错、分布式跟踪、调试、监控和资源管理方面的复杂性。

总之，为云原生应用程序设计强大且有弹性的通信系统需要深入了解同步和异步通信模式。通过仔细考虑每种模式的优点和缺点并使它们与需求保持一致，架构师可以设计出有效协调应用程序边界内外的独立元素的系统，以交付高性能、可扩展且可靠的云原生应用程序。

以上就是云原生应用程序中的同步和异步通信解码的详细内容，更多请关注讯客代码网其它相关文章！