如何使用微服务架构处理共享数据源

Posted 2023-03-08

【中文标题】如何使用微服务架构处理共享数据源

【英文标题】：How to handle shared datasources using microservices architecture

【发布时间】：2016-05-22 17:53:36

【问题描述】：

我的微服务架构中有几个服务。

两个服务（服务 A，服务 B）有不同的 api 并提供不同的域逻辑。然而，它们确实共享一些应该返回的逻辑——来自 Redis 的用户状态。

当用户状态发生变化时，我会从第三个服务发布到我的所有微服务

解决方案：

我可以创建另一个服务来负责“用户状态”并将所有用户数据保存在 Redis 上。 缺点： 我的客户将对每个 api 请求进行额外调用（以获取用户状态）。

复制每个微服务的用户状态数据源（持有多个redis实例）并为每个请求独立返回。 缺点： 我将复制我的数据并复制 Redis 实例（每个微服务都将访问它自己的）

拥有一个 redis 数据源，而所有服务都将使用它。 缺点： 在服务之间复制redis-logic（为了检索数据）并使用一个共享数据源打破微服务原则

你会建议做什么？

【参考方案1】：

如果你想保持微服务架构稳固，我肯定会选择第一；如果您将“用户/用户状态”视为可以自行运行的完全独立的产品。

我认为防止冗余实现/数据的额外调用是可行的方法，如果 Redis 在它后面，并且前面的 API 正在执行，那么额外调用应该没有问题。尽可能保持系统解耦，您将获得胜利。

如果不是这样，那么 2 将是一个很好的解决方案。您将面临有关数据完整性和复制问题的挑战，但这是其中一种方法。

【讨论】：

这里使用这种方法的问题：1。如果用户真的必须对他的状态结果采取行动，它甚至可能会花费我第三次调用（例如从用户服务刷新用户详细信息），所以如果我正在第二次调用检查状态，我可以直接从用户服务请求.找我？

我明白，我会考虑衡量我的用户更改状态的频率与整个系统逻辑相比，如果它不是系统的重要部分，那么我不会担心。再一次，您正在辩论绕过微服务的概念，最终创建它是为了以更有效的方式管理技术组件和团队，如果您在没有它的情况下继续前进，那么第 3 号也是可能的。

你认为 3 会比 2 更好吗？同时为每个服务复制用户数据（仅用户状态）

2：你的意思是只要有变化就在不同服务的实例之间复制所有数据？如果是这样的话，它将开始成为复制地狱。我更喜欢处理代码而不是一直处理数据完整性。

Userservice 本身就是一项服务，但用户状态只是针对 redis 的 api。顺便说一句，我解耦了这两个 coz.userservice 是一个沉重的组件，而 userstate 只是对 redis 的 api 调用（由 vertx 包装）