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

EN

这一次我从不同的角度阅读了你的问题，所以这里有一个“不同的观点”。我知道这可能太晚了，但希望这有助于进一步的发展。

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

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

因此，从您的示例中可以看出，由于只有一个存储，因此您只有一种方法来管理其一致性。

顺便说一句，我想知道你到底是怎么解决你的问题的？另外，如果你喜欢我的想法，你可以随意接受它。

让我试着重新表述这个问题：

演员：

• X: UserIds (帐户状态)
  • 提供服务以获取ID (基于凭据)和account

的状态

​

• A: UserProfile
  • 使用X检查用户帐户的状态。存储名称以及指向account
  • provide服务的链接，以基于ID

获取/编辑名称

​

• B: UserBlogs
  • 以同样的方式使用X。当用户使用A根据用户名搜索博客文章时，将博客文章与指向帐户的链接一起存储
  • 提供服务获取/编辑基于ID的博客条目列表
  • 提供服务以根据名称搜索博客文章(依赖于A)

​

• C: MobileApp
  • 将X、A、B的功能封装到一个移动应用程序中
  • 依赖于与所有其他应用程序之间定义良好的通信契约(遵循@neleus语句)提供上述所有服务

​

Requirements:

对于X、A、B、C团队的uncoupled

• Integration环境，需要使用最新的功能进行更新(为了执行集成，针对X、A、B、C的环境需要有“足够”的数据集(以便执行负载测试和发现边缘情况)

遵循@eugene的想法:让每个团队提供的每个服务都有mock将允许1)和2)

• 成本更多的是来自团队的开发
• 以及模拟和主要
• 的维护是这样一个事实，即您拥有一个整体系统(您还没有一组干净的、定义良好的/隔离的服务)

建议的解决方案：

如果有一个共享环境，需要解析一组主数据3)呢？每个“交付的服务”(即在生产中运行)都是可用的。每个团队都可以选择在这里使用哪些服务，以及在自己的环境中使用哪些服务

我能看到的一个直接缺点是数据的共享状态和一致性。

让我们考虑一下针对主数据运行的自动化测试，例如：

• B为了在其博客服务上工作而更改名称(归A所有)，
  • 可能会中断A，也就是C

​

为了在某些权限方案中工作，

• A会更改帐户的状态
  • 可能会破坏X，

​

• C会在相同的帐户上更改所有内容
  • 会破坏所有帐户

​

主数据集将很快变得不一致，并失去上面要求3)的价值。

因此，我们可以在共享的主数据上添加一个“常规”层:任何人都可以从全集读取，但只能修改他们创建的对象？

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

关于环境的几句话。我建议使用puppets。这是自动化服务部署过程的方法。我们使用傀儡在不同的环境中部署服务。可以到达傀儡脚本并允许灵活配置。