使用 Materialize 解耦微服务架构

介绍

在微服务架构中处理数据的方法有多种，在本文中我们将介绍为每个微服务设置单独数据库的方法。

先决条件

本文将以Houssem Dellai的以下视频中涵盖的概念为基础：

• 微服务架构中的数据

架构概述

我们将使用上述视频中描述的架构。下图展示了该架构：

架构快速概览：

• 我们有一个电子商务网站，由以下两个微服务组成：
  • 目录服务：此微服务负责管理产品。
  • 购物篮服务：此微服务负责管理订单。
• 这两个微服务都位于 API 网关后面。
• 每个微服务都有自己的数据库。
• 为了让后端与目录服务通信，我们使用 REST API。这就是购物篮服务从目录服务获取产品数据的方式。

上述架构的问题在于购物篮服务与目录服务紧密耦合。这种架构存在一些缺点：

• 如果目录服务宕机，购物篮服务将无法获取产品数据。这意味着购物篮服务将无法处理订单，并且也会宕机。
• 当扩大规模时，购物篮服务将开始对目录服务产生负载，这意味着目录服务也需要扩大规模。
• 每次更新目录服务时，购物篮服务也需要更新。

为了解耦微服务，我们将使用第三个微服务，称为Gateway。该微服务将负责将请求路由到其他微服务。但是，采用这种方法，API 网关将处理所有请求和微服务，这可能会成为瓶颈，因为它将承担很多职责。

让我们看一下解耦微服务的另一种方法。

松散耦合的微服务

由于每个微服务都是独立的并且拥有自己的数据，为了解耦微服务，我们可以使用物化视图来存储微服务的聚合数据。

下图显示了具有物化视图的架构：

上述架构的快速概览：

• 我们正在向购物篮服务添加一个新的物化视图，它将存储购物篮服务和目录服务的聚合数据。
• 目录服务现已扩展，可以向购物篮服务发送变更事件。
• 变化事件可以存储在 Apache Kafka 或 RedPanda 等服务中。
• 现在，购物篮服务将处理变更事件，并随着目录服务中的数据发生变化而相应地更新物化视图。
• 物化视图将用作购物篮服务的只读数据源。

这种方法的缺点是：

• 聚合器中将会有重复的数据。
• 变化事件会给微服务增加很多复杂性。
• 如果您不具备专业知识，添加额外的组件和更改意味着开发团队将面临陡峭的学习曲线。

使用 Materialize

Materialize 是一个流数据库，它从 Kafka、PostgreSQL、S3 buckets 等不同来源获取数据，并允许用户编写聚合/具体化该数据的视图，并允许您使用纯 SQL 查询这些视图。

与传统的物化视图不同，Materialize 旨在保持数据处于连续状态，并持续更新视图。这意味着，如果您有一个持续更新的视图，您可以实时查询数据。普通的物化视图每次需要更新时都会进行全表扫描，这可能会非常昂贵。

有关 Materialize 的更详细说明，请参阅Materialize 文档。

您还可以观看这个简短的视频，了解什么是 Materialize。

使用 Materialize 解耦微服务架构

借助 Materialize，我们可以解耦微服务架构，并使用实时的物化视图来存储聚合数据。Materialize 会持续更新物化视图，让我们能够以亚秒级延迟实时查询数据。

这将消除对事件驱动架构的需求，也将消除扩展目录服务以向购物篮服务发送变更事件的需求。

下图展示了使用 Materialize 的架构：

使用 Materialize 快速概览架构：

• 我们将再次使用物化视图来存储购物篮服务和目录服务的聚合数据。这次，我们将使用 Materialize 来存储数据。
• 由于这将为我们提供数据的实时视图，我们不再需要更改事件，因为我们可以实时查询聚合数据。
• 这样，如果产品价格发生变化，购物篮服务就会立即意识到这一变化。

由于 Materialize 与 Postgres 线路兼容，我们不需要使用任何第三方库来使用 Materialize，并且没有学习曲线。

需要注意的是，Materialize 目前不支持持久化。这意味着如果您重启服务，物化视图将需要重新聚合数据。此功能已列入我们的路线图，即将上线。

演示

为了将其付诸实践，您可以查看并运行以下演示：

• 如何在实时物化视图中连接 MySQL 和 Postgres

结论

有用的链接：

• 物化文档
• 物化演示
• 物化云
• 实现 GitHub
• 物化微服务演示