代码之家 › 专栏 › 技术社区 › Fabio Jim Dagg

微服务数据复制模式

eventual-consistency event-driven database-replication microservices apache-kafka

0

Fabio Jim Dagg · 技术社区 · 6 年前

在微服务架构中,我们通常有两种方式来传递两个微服务。假设服务A需要从服务B获取信息。第一个选项是远程调用,通常通过HTTPS同步,因此服务A查询由服务B托管的API。

第二种选择是采用事件驱动的体系结构,其中服务B的状态可以由服务A以异步方式发布和使用。使用此模型,服务A可以使用来自服务Bs事件的信息更新其自己的数据库,并且所有查询都在此数据库中本地进行。这种方法的优点是,从开发到运行,微服务的分离性更好。但它也带来了一些与数据复制相关的缺点。

第一个是磁盘空间的高消耗,因为相同的数据可以驻留在需要它的微服务的数据库中。但第二个是我认为最糟糕的:如果服务B不能按需要快速处理其订阅,或者由于模型的最终一致性,它不能在服务A创建于服务B的同时提供给服务A,那么数据可能会变得陈旧。

我们可以使用什么模式来实现这种微服务数据库扩展

1 回复 | 直到 6 年前

1

3

Saptarshi Basu 6 年前

有两种选择:

2

1

Imran Arshad 6 年前

你的担心是对的,但同时微服务的方法是给予和接受。您将以每个服务的单个数据库为代价获得松耦合。微服务体系结构没有正确的答案,这取决于您要实现的目标。

根据CAP定理,您必须在一致性和可用性之间做出折衷,在大多数情况下,我们采用最终一致性。如果你的服务A与B不一致,那么它最终将是,这是以可用性为代价的权衡。

对于后期加入系统的新服务,事件源是用于此类场景的模式。它的复杂模式,但它会将新添加的服务带到您希望它们处于的状态。基本上,您将所有事件保存在一个事件存储中并重播它们,以获得系统的当前状态,并用这些事件预填充ServiceC数据库。