如何在微服务体系结构中处理共享状态？
在我们公司，我们正在从一个巨大的单体应用程序过渡到微服务架构。这一决定的主要技术驱动因素是能够独立扩展服务的需求和开发的可扩展性——我们有十个Scrum团队在不同的项目（或“微服务”）中工作。
过渡过程很顺利，我们已经开始受益于这种新的技术和组织结构的优势。现在，另一方面，我们正在努力解决一个主要的痛点：如何管理这些微服务之间依赖关系的“状态”。
让我们举一个例子：其中一个微服务处理用户和注册。该服务（我们称之为X）负责维护身份信息，因此是用户“ID”的主要提供者。其余的微服务都强烈依赖于此。例如，有些服务负责用户配置文件信息（A）、用户权限（B）、用户组（C）等，这些服务依赖于这些用户ID，因此需要在这些服务之间保持一些数据同步（即服务A不应包含未在服务X中注册的用户ID的信息）。目前，我们通过使用RabbitMQ通知状态更改（例如新注册）来维护此同步。
可以想象，有许多Xs：许多“主”服务，它们之间有许多更复杂的依赖关系。
主要问题是在管理不同的开发/测试环境时。每个团队（因此，每个服务）都需要经历几个环境，以便使一些代码处于活动状态：持续集成、团队集成、验收测试和活动环境。
显然，我们需要在所有这些环境中工作的所有服务来检查系统是否作为一个整体工作。现在，这意味着为了测试依赖服务（A、B、C、...），我们不仅必须依赖服务X，还必须依赖它的状态。因此，我们需要以某种方式保持系统完整性并存储一个全局
我们目前的做法是从实时环境中获取所有数据库的快照，进行一些转换以缩小和保护数据隐私，并在特定环境中测试之前将其传播到所有环境。这显然是一个巨大的开销，无论是在组织上还是在计算资源上：我们有十个连续集成环境、十个集成环境和一个验收测试环境，所有这些环境都需要经常使用来自实时和最新版本代码的共享数据进行“刷新”。
我们正在努力寻找更好的方式来缓解这种痛苦。目前，我们正在评估两个选项：
- 为所有这些服务使用类似docker的容器
这些解决方案都无法缓解服务之间共享数据的痛苦。我们想知道其他一些公司/html" target="_blank">html" target="_blank">开发人员是如何解决这个问题的，因为我们认为这在微服务体系结构中一定很常见。
你们怎么做到的？你也有这个问题吗？有什么建议吗？
抱歉解释这么长，非常感谢！
共有3个答案
从我的角度来看，只有使用服务的对象才应该具有状态。让我们考虑您的示例：服务X负责用户ID，服务A负责配置文件信息等。让我们假设用户Y具有一些安全令牌（例如，可以通过使用其用户名和密码创建-应该是唯一的）系统条目。然后客户端包含用户信息，将安全令牌发送到服务X。服务X包含有关链接到此类令牌的用户ID的信息。如果是新用户，服务X创建新ID并存储其令牌。然后服务X将ID返回给用户对象。用户对象通过提供用户ID向服务A询问用户配置文件。服务A获取ID并询问服务X是否存在该ID。服务X发送肯定的答案，然后服务A可以通过用户ID搜索配置文件信息或要求用户提供此类信息以创建它。相同的逻辑应该适用于B和C服务。它们必须相互交谈，但它们不需要知道用户状态。
关于环境的几句话。我建议使用木偶。这是自动化服务部署过程的方法。我们正在使用木偶在不同的环境中部署服务。木偶脚本是可达的，允许灵活配置。
让我重新解释一下这个问题：
演员：
- 十： 用户ID（帐户状态）
- 提供服务以获取帐户的ID（基于凭据）和状态
- 使用X检查用户帐户的状态。存储名称和帐户链接
- 提供基于ID获取/编辑名称的服务
- 以相同的方式使用X。当用户编写一个时，存储博客文章以及帐户链接
- 使用A根据用户名搜索博客文章
- 提供服务根据ID获取/编辑博客条目列表
- 提供基于姓名搜索博文的服务（依赖A）
- 将X、A、B的功能包装到移动应用程序中
- 提供上述所有服务，依靠与所有其他人的明确定义的通信合同（遵循@neleus声明）
要求：
- 团队X、A、B、C的工作需要解耦
遵循@eugene的想法：对每个团队提供的每个服务进行模拟将允许1）和2）
- 成本是团队的更多发展
- 还维护了模拟以及主要功能
- 障碍是您有一个单一的系统（您还没有一组干净的定义良好/隔离的服务）
建议解决方案：
拥有一个与要解决的主数据集共享的环境怎么样3）？每个“交付的服务”（即在生产中运行）都是可用的。每个团队都可以选择在这里使用哪些服务，以及在自己的环境中使用哪些服务
我能看到的一个直接缺点是数据的共享状态和一致性。
让我们考虑针对主数据运行的自动化测试，例如：
- B更改名称（归A所有）以便在其博客服务上工作
- 可能会打破A，或C
- 可能会破坏X，B
- 打破所有其他
主数据集将很快变得不一致，并失去上述要求3）的价值。
因此，我们可以在共享主数据上添加一个“常规”层：任何人都可以从全集中读取，但只能修改他们创建的对象？
这次我从不同的角度看了你的问题，所以这里有一个“不同的观点”。我知道这可能为时已晚，但希望这有助于进一步发展。
看起来共享状态是错误解耦的结果。在“正确”的微服务架构中，所有的微服务都必须在功能上而不是逻辑上隔离。我的意思是，所有这三个用户配置文件信息（A）、用户权限（B）、用户组（C）在功能上都是相同的，在功能上或多或少是一致的。它们似乎是一个具有一致存储的单一用户服务，尽管它可能看起来不像一个微型服务。在这里，我看不出有什么理由将它们解耦（或者至少你没有告诉他们）。
从这一点开始，将其拆分为更小的独立部署单元可能会带来更多的成本和麻烦，而不是好处。这应该有一个重要的原因（有时是政治原因，有时只是缺乏产品知识）
因此，真正的问题与微服务隔离有关。理想情况下，每个微服务都可以作为完整的独立产品存在，并提供定义明确的业务价值。在详细说明系统架构时，我们将其分解为微小的逻辑单元（在您的情况下为A、B、C等，甚至更小），然后定义功能一致的子组。我不能告诉你如何做到这一点的确切规则，也许是一些例子。单元之间复杂的通信/依赖关系，在它们无处不在的语言中有许多通用术语，因此看起来这些单元属于同一个功能组，因此属于单个服务。
因此，从您的示例来看，因为只有一个存储，所以您只有一种方法可以像以前那样管理其一致性。
顺便说一句，我想知道你解决问题的实际方法是什么？
-
我不清楚如何取回购买服务不保存的数据--例如：用户的全名。当试图通过购买用户名进行更复杂的搜索购买时，问题会变得更严重。 我认为，显然可以通过在两个服务之间同步用户来解决这个问题，方法是在用户创建时广播某种类型的事件（并在购买服务端只保存相关的用户属性）。在我看来，这远非理想。当你有数百万用户时，你如何处理这个问题？您会在每个使用用户数据的服务中创建数百万条记录吗？ 另一个明显的选择是在用户服务端
-
我最近开始使用Node.js，我必须构建一个应该使用多个Express.js服务的体系结构。其中一些服务必须位于一台服务器上，另一台则位于其他服务器上。我想构建一个基础服务（像API网关），但是我不知道在这个网关和微服务之间，或者在两个微服务之间进行通信的合适方式是什么。 目前我正在研究一个基于此的解决方案：
-
背景： 我正在构建一个应用程序，建议的体系结构是基于微服务体系结构的事件/消息驱动的。 做事情的单一方式是，我有一个，它操作一些具有直接的命令。因此，响应相同的用户/HTTP请求是“无忧无虑的”。 问题： 用户向UI服务（有多个UI服务）发送一个，该服务向队列（Kafka/RabbitMQ/any）触发一些事件。N个服务拾取该事件/消息，并在此过程中发挥一些魔力，然后在某个时刻，相同的UI服务应拾
-
我的微服务架构中有几项服务。 其中两个服务（服务A、服务B）有不同的api，并提供不同的域逻辑。然而，它们确实共享一些应该从Redis返回的逻辑-用户状态。 当用户状态更改时，我正在从第三个服务发布到我的所有微服务 解决方案： > 我可以创建另一个服务，负责“用户状态”并将保存Redis上的所有用户数据。缺点：我的客户端将对每个api请求进行额外调用（以获取用户状态）。 为每个微服务复制用户状态数
-
问题内容： 在面向服务的体系结构中处理实体类型的多态性和继承时，最不邪恶的道路是什么？ SOA的原理（据我所知）是将实体类作为纯数据构造，而没有任何业务逻辑。所有业务逻辑都包含在范围狭窄，松耦合的服务中。这意味着服务实现应尽可能小，以进一步促进松散耦合，并且意味着实体避免必须了解系统可能对其执行的 每种 行为。 ，因此服务实现中的任何多态行为都将替换为一系列条件检查或using 。在OOPL中，这
-
总而言之，我们有： 产品类别: 产品ID、产品名称 订单类别: 订单ID、产品ID、用户ID、订单日期 这些方法中的任何一种可以被认为是最佳实践吗？还是有不同的解决方案？