我正在构建一个基于微服务的系统。这是一个连接到其他API的Web应用程序。现在，我要实现授权系统（而不是身份验证），因此基本上我希望能够定义系统上的哪些用户可以执行哪些操作。 因此，我正在考虑为此实施角色/权限系统。
但是，我对想到的两种不同体系结构选择感到困惑，我想知道您的想法，建议，优缺点，以继续前进。
将有一个特定的微服务来处理用户权限和角色，因此基本上该微服务将有权访问两个数据库表，从而在用户和角色以及角色和权限之间建立关联。这是我考虑过的两种解决方案的共同部分。
现在我认为这两种选择都各有利弊：
1）为每个微服务保留一个具有该微服务特定用户权限的缓存表。因此，每次用户想要对该微服务执行操作（例如，删除订购微服务上的订单）时，微服务都会检查该表，从而授予或不授予用户执行该操作的权限。
优点：每个微服务实际上都是微服务，这是一个独立的服务，可以在系统的其余部分完全自主地工作。如果处理用户权限的主要微服务崩溃并且不可用，则其余微服务将继续工作。缺点：如果我更新了处理此问题的微服务中的用户权限，则需要向所有微服务发送一条消息以更新其对应的权限表。
2）创建一个API网关微服务以充当前端和其余微服务之间的中间件，并在其中使用graphql。前端将不再了解其余的微服务，而只会知道这一点。 该微服务将拦截来自前端的所有请求，并向用户权限微服务检查用户是否有权执行该操作，如果允许，则调用相应的微服务。
优点：决定用户是否具有访问权限的所有业务逻辑都在单个微服务中，而不是在微服务中重复。另外，身份验证仅需要在中间件微服务中实现，而无需像我们到那里一样仔细检查用户是否在内部微服务上进行了身份验证，这是因为我们之前已成功进行了身份验证。 如果用户角色或权限已更新，则无需更新内部微服务中的缓存表。缺点：这违反了微服务架构的定义。即，如果中间件微服务崩溃，则整个系统将关闭。
我想知道你的想法！
谢谢！