问如何处理微服务架构中的共享状态？

EN

在我们公司，我们正在从一个巨大的单片应用程序过渡到一个微服务架构。这一决定的主要技术驱动因素是能够独立扩展服务的需求和开发的可扩展性-我们有十个scrum团队在不同的项目(或“微服务”)中工作。

过渡过程正在顺利进行，我们已经开始从这种新的技术和组织结构的优势中受益。现在，另一方面，有一个我们正在努力解决的主要痛点:如何管理这些微服务之间的依赖关系的“状态”。

让我们举个例子:其中一个微服务处理用户和注册。这个服务(让我们称它为X)负责维护身份信息，因此是用户“ids”的主要提供者。其余的微服务对此有很强的依赖性。例如，有一些服务负责依赖于这些用户in的用户简档信息(A)、用户许可(B)、用户组(C)等，因此需要维护这些服务之间的某些数据同步(即，服务A不应具有用于未在服务X中注册的userId的信息)。我们目前通过使用RabbitMQ通知状态更改(例如，新注册)来维护此同步。

正如您可以想象的那样，有许多X:许多“主”服务以及它们之间更复杂的依赖关系。

主要问题出现在管理不同的开发/测试环境时。每个团队(因此，每个服务)都需要经历几个环境，以便将一些代码放在活动的环境中:持续集成、团队集成、验收测试和活动环境。

显然，我们需要在所有这些环境中工作的所有服务，以检查系统是否作为一个整体工作。现在，这意味着为了测试依赖服务(A，B，C，...)我们不仅要依赖服务X，还要依赖它的状态。因此，我们需要以某种方式保持系统的完整性，并存储全局和相干状态的。

我们当前的方法是从实时环境中获取所有数据库的快照，进行一些转换以缩小和保护数据隐私，并在特定环境中进行测试之前将其传播到所有环境。这显然是一个巨大的开销，无论是在组织上还是在计算资源上:我们有十个持续集成环境，十个集成环境和一个验收测试环境，所有这些环境都需要用来自实时的共享数据和最新版本的代码频繁地“刷新”。

我们正在努力寻找一种更好的方法来缓解这种痛苦。目前我们正在评估两个选项：

1. 对所有这些服务使用类似docker的容器
2. 具有每个服务的两个版本(一个用于该服务的开发，另一个用作沙箱，供其他团队在其开发和集成测试中使用)

这些解决方案都不能缓解服务之间共享数据的痛苦。我们想知道其他一些公司/开发人员是如何解决这个问题的，因为我们认为这在微服务架构中一定很常见。

你们是怎么做到的？你也有这个问题吗？有什么建议吗？

很抱歉长篇大论的解释，非常感谢！