目前我开发了基于微服务架构的后端。 不幸的是，我有一个如何实现授权的问题。
让我解释一下我的系统 - 有以下服务：
每个用户都在一个或多个组中。 每个资源（如ToDo列表）也属于一个组。 这意味着如果某个用户创建待办事项列表，该列表将存储在该组的名称中。
SZENARIO：
我是否有任何机构知道如何在微服务架构中实现这一点并将服务之间的依赖关系保持在最低限度？
当然，如果用户位于资源所属的组中，我可以在每个请求中询问组服务。但是，我在资源服务和组服务的存在之间得到了非常严格的依赖 - 我喜欢避免这种依赖。 另一种选择是在访问令牌中存储用户所属的所有组。但是使用此选项，当用户获得新组的成员时，客户端必须每次向OAuth服务询问新令牌。
还有其他选择我怎么能实现这个szenario？
答案 0 :(得分：2)
所以，你有三个域：
您已经很好地识别了三个bounded contexts，每个域一个，并在三个微服务（MS）中实现。您遵守了有关DDD的最佳做法。
不，你的问题是如何以系统resilient的方式集成这三个微服务，即即使其他一些微服务失败，它的微服务也会继续工作。
有两种关于集成的选项（微服务之间的通信）：
同步通信：每当Todos MS收到请求时，它都会向授权MS查询是否允许用户按照自己的意愿行事。这具有易于实现的优点，但是其具有易于级联故障的缺点：如果授权MS失败，则该MS也失败。所以，这个选项对你不利。
异步通信：在某种程度上在后台，有一些数据从授权MS复制到Todos MS。您至少有两个选项可以完成此复制：a）在cron或scheduled tasks或类似情况下; b）使用event driven architecture。这具有提供更大弹性的优点，但是它具有更复杂，更难实现的缺点。 此选项似乎符合您的需求。
进一步阅读：
答案 1 :(得分：0)
我建议将授权处理放入API网关。收到传入请求时，将执行以下步骤
1。API网关访问OAuth服务器以获取一个透明令牌，其中包含用户的访问角色和组 2.API网关然后使用访问令牌调用do服务，do服务使用该令牌来确定是否授权了特定用户。
这种集成模式的优势在于，各个服务不必调用组服务即可获得角色。