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

微服务数据复制模式

  •  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 年前

    有两种选择:

    1. 您可以为单个主题启用Kafka的日志压缩。它将保留给定密钥的最新值以丢弃旧更新。这样可以节省空间,并且在给定的保留期内比正常模式保存更多的数据

    2. 假设您每天备份服务B DB,在引入新的服务C时,您需要首先从B的最新备份创建C的初始状态,然后从表示备份后数据的特定偏移id重播Kafka主题事件。

        2
  •  1
  •   Imran Arshad    6 年前

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

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

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