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

Question

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

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

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

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

管理不同的开发/测试环境时出现的主要问题。每个团队(因此，每个服务)都需要经过几个环境才能使一些代码生效:持续集成、团队集成、验收测试和实时环境。

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

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

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

为所有这些服务使用类似 docker 的容器

每个服务有两个版本(一个用于开发该服务，另一个用作沙箱，供其他团队在开发和集成测试中使用)

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

你们怎么样？你也有这个问题吗？有什么推荐吗？

很抱歉解释太长，非常感谢!

Answer 1

这次我从不同的角度阅读了你的问题，所以这里是一个“不同的意见”。我知道这可能为时已晚，但希望它有助于进一步发展。

看起来像 shared state是错误解耦的结果。在“正确”的微服务架构中，所有微服务都必须在功能上而不是逻辑上隔离。我的意思是所有三个 user profile information (A), user permissions (B), user groups (C)看起来功能相同，或多或少在功能上是连贯的。他们似乎是一个 user microservice具有连贯的存储。我在这里看不到任何使它们脱钩的原因(或者至少您没有告诉它们)。

所以真正的问题与微服务隔离有关。理想情况下，每个微服务都可以作为 存在。完整的独立产品并提供定义明确的商业值(value) .在详细说明系统架构时，我们将其分解为微小的逻辑单元(在您的情况下为 A、B、C 等，甚至更小)，然后定义功能上一致的子组。我不能告诉你如何做到这一点的确切规则，也许是一些例子。单元之间复杂的通信/依赖关系，在其普遍存在的语言中有许多通用术语，因此看起来这些单元属于同一个功能组，因此属于微服务。

因此，从您的示例来看，由于只有一个存储，因此您只有像以前那样管理其一致性的方法。

顺便说一句，我想知道您解决问题的实际方法是什么？另外，如果您喜欢我的想法，请随意接受。