如今，我们通常会为单个产品构建多个服务，而客户应用需要从多个服务中消费功能。 Microservices architecture已成为构建可扩展和弹性应用的流行方法。在基于微服务的系统中，多个松散的耦合服务共同使用所需的功能。此类系统中的主要挑战之一是以可靠和有效的方式在微服务之间交换数据。可以帮助应对这一挑战的一种模式是Outbox pattern。
在本文中，我们将探讨如何使用 Outbox模式使用流数据库，它可以为微服务或多个服务数据交换提供可靠的解决方案。
需要可靠的微服务数据交换
在微服务体系结构中，每个微服务具有业务逻辑，负责其自己的数据，具有自己的本地数据存储，并在该数据（Data per service模式）上执行自己的操作。但是，在某些情况下，微服务需要彼此共享数据或将实时的任何特定数据更改通知其他服务，以保持一致性并为最终用户提供凝聚力的体验。例如，考虑在乘车服务中，可能会有多个微服务负责不同的功能，例如用户管理，乘车预订，驾驶员管理和付款处理。当用户请求乘车时，它会触发一系列事件，这些事件需要传播到各种微服务以处理和更新其数据。
微服务之间的传统同步通信会导致紧密的耦合以及潜在的性能和可靠性问题。发送服务需要了解其他微服务的位置，接口和合同，这可能会导致复杂的依赖网络。这可能会使它独立发展，测试和部署微服务挑战，因为一个微服务的任何变化都可能需要更改多个依赖的微服务。有时，这些目标服务可能暂时不可用，并且由于需要等待和阻止在收到响应之前，可能会引入性能开销。
。异步和解耦数据交换
另一方面， Outbox模式促进了微服务之间的异步和解耦的数据交换。当事件或更改以一种微服务发生时，它会写入事件或更改其发出框，该发出框充当缓冲区。 Outbox 可以作为服务拥有的单独数据库表实现。
然后，Microservice的发件箱由 Outbox处理器处理（通过单独的组件或服务，例如流媒体数据库RisingWave，在下一节中进行了解释），该部分读取事件或从该事件中进行更改。 OUTBOX并将它们发送到其他微服务或数据存储中，因此不同步。这允许微服务继续处理请求，而无需等待数据交换完成，从而提高了性能和可伸缩性。
。微服务B，需要随着微服务A的更改而更新，从Outbox处理器接收事件或更改，并将其应用于其自己的状态或数据存储。这样可以确保微服务B的数据与微服务A中的更改保持一致。
现在，让我们看看如何使用流媒体数据库以RisingWave的示例来实现Onbox模式。市场上还有其他流数据库选项，this post可帮助您了解什么是流数据库，何时以及为什么使用它，并讨论当选择选择时应该考虑的一些关键因素右流数据库用于您的业务。
RisingWave是一个流数据库，有助于构建实时事件驱动的服务。它可以从traditional databases binlogs or Kafka topics直接读取数据库更改事件，并通过将多个事件结合在一起来构建实现的视图。随着新事件的到来，RisingWave将使视图保持最新状态，并允许您使用SQL查询以访问对数据进行的最新更改。
带有流数据库的输出模式
流数据库可以充当实时流媒体平台（Outbox处理器）。它使用其内置的Change Data Capture (CDC) connector来听取指定数据库表中的任何写入/更新操作，捕获更改，并在Kafka主题的帮助下实时或接近实时地传播这些更改到其他微服务（请参阅如何沉没（请参阅如何沉没）数据from RisingWave to a Kafka broker）。
在this article中，作者 gunnar Molling 解释了基于CDC和Debezium connector的Outbox模式的另一个实现。
使用流数据库时，一些关键优势是您不需要同时使用Debezium和Kafka Connect来实现相同的功能，此外，它也具有自己的存储空间，您永远不会丢失流数据，并且可以创建用于查询Microservices的实质性视图这在我的其他博客文章中解释了。
加上，它使我们能够通过将数据传递给BI and data analytics platforms来分析数据，以根据您的应用程序使用来做出更好的业务决策。例如，旅行历史视图是乘车服务中的重要功能，可为乘客和驾驶员提供旅行历史记录。可以使用实现的视图来存储流媒体数据库中每个用户的预先计算的旅行历史信息，而不是查询单个旅行记录并计算各种统计数据，例如总行程，收入，评级等。
。
使用Outbox模式和流数据库，这是数据交换可以用于我们的示例乘车服务的方式：
- 乘车服务（微服务A）：当用户请求乘车服务时，乘车服务会创建骑行的详细信息，并在其自己的数据库中写下诸如“ Riderequest”之类的活动，例如“ Riderequest”，Lether MySQL。
- 默认情况下，流数据库使用其connector for MySQL CDC捕获了Ride Service Outbox表中的“ Riderequest”事件。它处理事件并将其发送到需要更新的其他微服务，例如驾驶员服务（微服务B），支付服务（微服务C）和通知服务（Microservice D）（Microservice d），使用Apache Kafka。 li>
- 驱动程序服务（微服务B）：驾驶员服务从Ontox处理器接收“ Riderequest”事件，并根据RIDE详细信息找到可用的驾驶员。然后，它将一个事件（例如“ Driver Assigned”）写入其自己的发件箱。
- 支付服务（微服务C）：付款服务还从另一个Kafka主题中接收“骑行的”事件，并根据乘车详细信息计算乘车票价。然后，它将一个事件（例如“ Farecalualder”）写入其自己的发件箱。
我们可以创建多个KAFKA主题，以提供消费者服务的选项以仅订阅特定的事件类型。
结论
我们了解到，微服务之间的同步通信可以引入紧密的耦合，性能开销，缺陷缺陷，有限的可扩展性，挑战挑战以及降低灵活性和敏捷性。通过利用RisingWave之类的实时流式流平台，并通过应用输出模式将数据交换过程从主要交易流中解耦，您可以在微服务体系结构中实现高性能，可靠性和一致性。
相关资源
- How Streaming database differs from a Traditional database
- Querying Microservices in Real-Time with Materialized Views
建议的内容
社区
1¶Join the Risingwave Community
关于作者
- 请访问我的博客：âwww.iambobur.com
- 在Twitter上关注我：@BoburUmurzokov