Deployment 如何在微服务体系结构中处理共享状态？

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

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

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

可以想象，有许多Xs:many“main”服务，它们之间有许多更复杂的依赖关系

主要问题是在管理不同的开发/测试环境时。每个团队（因此，每个服务）都需要经历几个环境，以便使一些代码处于活动状态：持续集成、团队集成、验收测试和活动环境

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

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

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

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

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

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

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

---

对不起，解释得太长了，非常感谢

从我的角度来看，只有使用服务的对象才应该有状态。让我们考虑您的例子：服务X负责用户ID，服务A负责配置文件信息等。让我们假设用户Y有一些安全令牌（例如可以通过使用它的用户名和密码创建的）应该是系统的条目。然后，包含用户信息的客户端将安全令牌发送给服务X。服务X包含有关链接到该令牌的用户ID的信息。对于新用户，服务X创建新ID并存储其令牌。然后服务X将ID返回给用户对象。用户对象通过提供用户ID向服务A询问有关用户配置文件的信息。服务A获取ID并询问服务X该ID是否存在。服务X发送肯定回答，然后服务A可以按用户ID搜索配置文件信息，或者要求用户提供此类信息以创建它。同样的逻辑应该适用于B和C服务。他们必须相互交谈，但不需要了解用户状态

---

关于环境的几句话。我建议使用。这是自动化服务部署过程的方法。我们正在使用木偶在不同的环境中部署服务。木偶脚本是可触及的，允许灵活配置

让我重新解释一下这个问题：

演员：

• X：用户ID（帐户状态）
  • 提供服务以获取帐户的ID（基于凭据）和状态
• A:用户配置文件
  • 使用X检查用户帐户的状态。存储名称和帐户链接
  • 提供基于ID获取/编辑名称的服务
• B:用户博客
  • 以同样的方式使用X。当用户写博客文章时，存储博客文章以及到帐户的链接
  • 使用基于用户名的日志搜索
  • 根据ID提供服务获取/编辑博客条目列表
  • 提供基于姓名搜索博客文章的服务（依赖于A）
• C:MobileApp
  • 将X、A、B的功能包装到移动应用程序中
  • 提供上述所有服务，依靠与所有其他人的明确沟通合同（遵循@neleus声明）

要求：

团队X、A、B、C的工作需要解耦

X、A、B、C的集成环境需要更新最新的功能（在ord中