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

时间:2016-02-11 19:14:25

标签: java architecture redis microservices bigdata

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

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

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

解决方案:

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

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

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

  4. 你会建议做什么?

1 个答案:

答案 0 :(得分:1)

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

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

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