在微服务(投影，逻辑复制)之间同步Postgres表

Question

在面向微服务的架构中，我们需要"同步"。或";project"表或表的一部分几乎实时地从一个服务传送到另一个服务。给定以下场景:

服务

SchemaA.account

id   | firstName   | lastName   | createdAt            | deletedAt
1    | Hello       | Name       | 2022-07-05T15:05:39Z | Null
2    | Test        | Name       | 2022-07-05T16:05:39Z | Null

服务B

SchemaB.account应与SchemaA.account同步

id   | deletedAt
1    | Null
2    | Null

术语"Projection"是一个主要用于事件源系统的术语，所以这里有点误导。我们的源是另一个关系数据库(Postgres)作为目标。我假设逻辑复制在这里是正确的术语，但我可能错了。

需求

1. 正如您所看到的，我只需要复制表SchemaA.account的一部分，即列的子集。
2. 服务B不需要写入到该表，只需读取即可。所以同步可以是单向的。
3. 解决方案应该尽可能健壮和容错。设想服务B在一段时间内不可用，以接收来自服务a的更改。
如果它是一个低级数据库解决方案/工具，它必须在AWS RDS中可用。
4. 快!接近实时，非计划同步。

可能的解决方案我不想重新发明轮子!我想，当我使用SNS + SQS时，我将拥有最大的灵活性(例如，服务A向SNS发布关于数据突变的消息，服务B的SQS队列订阅并添加数据)。但是，我认为这会产生很多开销。

我目前缺乏正确的搜索词。术语逻辑复制乍一看似乎很有前途，但我不确定复制工具是否能解决我的问题。我不想为备份集群复制整个模式，而是在微服务之间进行数据同步。逻辑似乎也很有前途，并且存在如何在AWS RDS中启用它的说明。

问题真的很简单:我是走在正确的轨道上，还是有一些明显的东西我没有考虑到?

Answer 1

听起来最有希望的方法是Change Data Capture，它在Postgres中利用逻辑复制协议来捕获对数据的更改;这些更改可用于将数据更新传播到其他服务。

例如，在Postgres等数据库中实现CDC的一个非常常用的工具是Debezium，它有一个指南(不知道它是否最新，但至少应该是一个开始)在RDS Postgres中使用Debezium。Debezium会将更改发布到Kafka(注意主题的保留设置:Kafka的默认值对于这个用例来说通常是一个定时炸弹)，并且一些其他组件会消耗来自Kafka的更改，例如更新表。

这种方法的一个好处是，它意味着您可以在源数据库的表中引入一个新列，而不必更改目标数据库中的任何内容:更改使用者将看到新字段，但它没有义务传播。