在整个微服务中组织和共享您的数据，这些是每个开发人员或建筑师在某个时候开始问自己的问题。这正是我意识到自己建造的架构出现问题时问自己的问题。

我们将要谈论的问题是古老而简单的，并且已经有几种方法可以解决它。在本文中，我的目标是分享我处理它的经验，以及使您的生活更轻松的方法:)
现在，我们完成了介绍，让我们深入研究问题。

当系统中有1个以上的服务时，您需要决定如何在整个系统中共享数据。您之所以问这个问题的原因是，使用手册和共同实践几乎不可能建立正确的微服务架构。这不仅是不可能的，我真的相信没有正确的微服务架构。它可能或多或少有光泽，但总的来说，在某些时候必须违反一些准则。
因此，让我们看一下在系统中共享数据的几种方法

1.直接致电微服务

可能是从不同的微服务中获取数据的最简单方法。大多数开发人员之所以选择这种方法，是因为它快速，易于理解并且实现很简单。但是，这种方法还有另一面。 Cascading failure。这是我很长时间以来一直面临的事情。这正是我开始寻找另一种共享数据并增加系统的总体可用性的方式。

。

2. Eversing架构

通常，我不介意在构建微服务时使用事件采购。这是共享数据的好方法，因为每个微服务只能存储所需的数据，因此没有数据重复。但是它要求开发人员编写更多代码来处理异步事件处理。基本上，每次创建新服务时 - 您需要编写一个代码以将您的服务与活动总线集成在一起。如果某些问题出现问题，因为很难确定错误发生的位置。

很难进行调试。

3.选择性/逻辑数据复制

当开发人员不编写代码来同步服务之间的数据时，选择性或逻辑数据复制是方法。他们只是继续处理服务查询数据库的数据，就像该数据属于服务一样。一致性和数据复制由基础架构保证。由于更改data捕获，这种选择性/逻辑复制是可能的。

change-data-capture的想法很简单。

您有一个数据库，该数据库不断地做某事，插入数据，删除数据等，而我们要做的就是“订阅”这些更改的日志。我们读取数据库中发生的事件的流。从那里我们可以对其进行处理，读取插入的数据，对其进行转换等。
有很多数据库支持Change-DATA捕获集成。诸如Postgres之类的数据库，MySQL可以导出其更改日志，您可以使用不同的工具来解析并使用日志中的数据。

pglogrepl和Debezium之类的软件包和技术可以帮助您在基础架构中构建自己的变更data捕获框架/图层。

在这一点上，您可能已经猜到了我们如何使用它来实现一种更好的方法来共享微服务之间的数据。通过使用复制，我们可以在服务共享数据时实现系统，但不会耦合并且不会影响一个。

值得一提的是，为您的微服务构建复制是一个复杂且耗时的过程。但它有自己的好处。

作为一个例子：您不必编写代码即可从另一个微服务中获取数据，例如EventerCorcing，这意味着您将能够更快地创建新服务（因此增长）。您还将能够更轻松地调试不一致，最重要的是，您将能够通过具有初始同步来恢复数据，从而将所有服务与来自源的数据填充所有服务。

在DataBrew中，这正是我们正在努力的事情。我们的目标是为开发人员一种简单的方式来建立其服务的复制。无需构建或维护这个复杂的基础架构。请访问我们的网站，看看我们如何帮助您调整数据复制。