微服务与外部遗留系统的集成

Question

我们正在将一个单一的遗留系统分解为微服务。当我们这样做时，我们不能完全消除对每个微服务所需的遗留系统中某些数据的依赖。

每个微服务应该直接与遗留数据库集成，在其域中读写数据，还是应该有一个集成服务负责将数据提取和写入遗留系统？

Answer 1

我要说的是，根据微观服务开发最佳实践，使用自己的持久层开发新服务会更好。数据隔离是微服务开发的主要对象。

现在说到这里，你不会像你的特殊情况一样，总是幸运地拥有一个能够实现这一目标的场景。在像您这样的情况下，我仍然建议您继续拆分您的大型应用程序的过程；为每个服务构建专用的持久性，并如您前面所提到的那样，使用一个集成服务，该服务负责确保最终与遗留持久性层的一致性。

如果您是在云本机环境中开发的，您可以使用类似Azure Cosmos DB这样的系列，它提供了一个令人惊奇的特性，他们称之为“变更日志”。此特性跟踪所有DB操作并触发事件，然后您可以监听这些事件，以便使用专用的集成服务。集成服务甚至可以使用一种无服务器技术来实现，在Azure平台上，这将通过Azure函数应用程序来实现，该应用程序带有Cosmos DB变更日志的触发器。这种无服务器策略将使您的成本保持在极低的水平，因为它们将为您提供每月一百万次的免费请求！

以这种方式使用集成服务的主要缺点是，您需要在设计软件时考虑到最终的一致性。这意味着应用程序中仍在使用遗留数据层的部分将与使用正确的基于服务的设计原则的更新服务稍有不同步。对于大多数用例来说，这并不是什么大问题，因为如果您要走上面描述的Azure函数路线，那么数据库在几秒钟后就应该是一致的。

补充意见..。(更新)我正在用下面的链接更新这个答案，链接到我写这个答案几个小时后碰巧遇到的MSDN博客文章，并认为它可能会让您更深入地了解数据同步化的整个问题！预测:多云分支与SQL Azure的节点同步，第2部分:基于服务的同步