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

Question

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

两项服务（服务A，服务B）获得了不同的api，并提供不同的域逻辑。但是它们确实共享一些应该返回的逻辑 - 来自Redis的用户状态。

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

解决方案：

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

2. 复制每个微服务的用户状态数据源（保存多个redis实例）并为每个请求单独返回。 缺点： 我要复制我的数据并复制Redis实例（每个微服务都会自己访问它）

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

你会建议做什么？

Answer 1

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

我认为要防止冗余实现/数据的额外调用是可行的方法，如果Redis支持它，并且前面的API正在执行那么你应该没有额外调用的问题。并且通过尽可能地将系统分离来获得胜利。

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