Architecture 微服务体系结构中的授权方法

我希望在微服务环境中解决授权问题。我有一个网关服务和14个底层微服务。我使用IdentityServer4进行身份验证和资源授权。然后，我在每个单独的服务中使用基于策略的授权。这在大多数情况下都很好，但是

所有微服务都需要检查特定请求的复杂授权规则。想象一下Facebook检查你和资源所有者是否有联系。这些信息可以通过“连接服务”提供，我正在考虑如何最好地解决它：

1：在网关级别执行一次。让网关调用“连接服务”，并使所有服务假定该请求已授权用于此特定场景。这将使授权从服务级别向上移动，并将失去一些灵活性，但避免重复。虽然我不确定是否要给gateway这个额外的责任

2：将授权保持在服务级别，让每个微服务调用“连接服务”，这将创建重复，并使系统变得更加健谈。听起来不太好

3：当连接发生变化时，让“连接服务”发布一条关于所有其他服务订阅的主题的消息，让服务保留它们自己的现有连接记录。这里的复制听起来很糟糕，但好处是授权保持在服务级别，而且还有一个性能优势——没有延迟

---

请告诉我是否有一种标准方法可以解决我可以模拟的大型体系结构的问题，或者是否有更好的方法。

这是一种有趣的方法。对我来说，这些需求首先听起来像是一个业务需求，而不是一个安全需求。另一方面，这听起来像是一种许可，所以这绝对是一种授权。据我所知，没有解决这个问题的标准方法。为了判断您的解决方案，我们需要更多的信息，例如：在您的系统中，您是否有像服务a->服务B->服务C这样的链通信。连接的大小是多少？您是否可以在之前为某人获取这些连接，并将其作为令牌等的属性发送到服务？谢谢您的评论。我尽量减少服务到服务的通信，网关用于使用GraphQL将响应“缝合”在一起，所以想法是让服务仅通过服务总线进行通信，Auth service是例外。我认为你关于获取连接的建议与我的第一点是一致的，这也是我倾向于的。我更愿意将其排除在令牌之外，但可能会在可能的情况下充实请求/头本身，否则会退回到第2点。仍然不是100%确定事实上我不知道请求和数据的数量等，但我建议使用第二个。因为在我看来，这似乎是对一个操作的验证，您需要从连接服务获得答案。这种情况可以简化为一般任务—如何在基于微服务的应用程序中组织对经常调用的资源的访问，而不考虑它是用于授权的。也许这样说对理解来说会更好。组织对频繁调用的服务的访问非常容易，可能的解决方案有：1）服务总线（异步通信），2）缓存，3）按键进行数据分区的扩展实例。没有“单一”正确的解决方案。就我个人而言，选择一种，我会选择最简单、最可维护的方法。@RVid我也有同样的疑问。你最后做了什么？