scope - 微服务架构中的授权

Question

目前我正在开发基于微服务架构的后端。不幸的是，我在如何实现授权方面遇到了问题。

那么让我解释一下我的系统 - 有以下服务:

• OAuth 2.0 服务(发布 JWT)
• 团体服务
• 一些资源服务(例如 ToDos 服务)

每个用户都在一个或多个组中。每个资源(如 ToDo 列表)也属于一个组。这意味着如果某个用户创建了一个待办事项列表，该列表将存储在该组的名称中。

场景:

• 用户A在A组
• 用户B在A组和B组
• 用户C在C组
• 用户 A 在组 A 中创建了一个 ToDo 列表。
• 用户 B 修改此 ToDo 列表(他被允许这样做，因为他也在组 A 中)
• 用户 C 也尝试修改此 ToDo 列表，但他不应该被允许这样做，因为他只在组 C 中。

有没有人知道如何在微服务架构中实现这一点并将服务之间的依赖关系保持在最低限度？

当然，如果用户在资源所属的组中，我可以在每次请求时询问组服务。但是，因此我在资源服务和组服务的存在之间获得了非常强的依赖性——我想避免这种依赖性。另一种选择是将用户所属的所有组存储在访问 token 中。但是使用此选项，当用户成为新组的成员时，客户端每次都必须向 OAuth 服务询问新 token 。

那么有没有其他方法可以让我实现这个场景？

Answer 1

因此，您拥有三个域:

1. 身份验证:负责识别用户
2. 授权:负责限制对资源的访问
3. Todos:您的核心领域

你已经很好地识别了三个 bounded contexts ，每个域一个，并在三个微服务 (MS) 中实现。您正在遵守关于 DDD 的最佳实践.

不，您的问题是如何以系统为 resilient 的方式集成这三个微服务，即即使其他一些微服务失败，它的微服务也会继续工作。

关于集成(微服务之间的通信)，您有两种选择:

1. 同步通信:每次 Todos MS 收到请求时，它都会查询 Authorization MS 以检查用户是否被允许做它想做的事情。这具有易于实现的优点，但具有易受级联故障影响的缺点:如果授权 MS 发生故障，则该 MS 也将发生故障。所以，这个选项对你不利。

2. 异步通信:在后台，有一些数据从授权 MS 复制到 Todos MS。您至少有两个选项可以完成此复制:a) 在 cron 中或 scheduled tasks或类似 b) 使用 event driven architecture .这具有提供更多弹性的优势，但具有更复杂、更难实现的缺点。 这个选项似乎符合您的需要。

进一步阅读:

• Building microservices