Architecture 带api网关的微服务授权模式

比如说，我正在开发一个博客平台，用户可以在这个平台上注册账号、付费订阅并创建自己的博客。平台由以下微服务组成：

• 帐户服务
• 身份验证服务
• 订阅服务
• 博客服务
• api网关

我正在考虑实施APIGW模式，其中除APIGW之外的所有微服务都将部署到专用网络（在专用网络中，它们将能够通过MessageBroker直接进行同步或异步通信），并且它们将仅通过APIGW公开

API将有两个客户/消费者：

• 前端（适用于客户）
• cms（针对管理员）

因此，我希望每个客户端模式使用单独的api gw，因此实际上将有两个api网关，一个用于常规前端（frontent api gw），一个用于cms（cms api gw），但两者都将使用相同的微服务

我的问题是关于授权以及授权应该在哪里进行（或者更确切地说，不同方法的优缺点是什么）。让我们关注两个“端点”：

前端api gw:：createBlog（）=>blog服务：：createBlog（）

前端api gw公开端点以创建新博客，此api调用被“转发”到博客服务：：createBlog（）端点。假设用户已经过身份验证（即，将带有用户id的正确JWT与请求一起传递给api gw）

必须进行的授权是确定具有此id的用户是否可以创建新博客。这可以通过调用订阅服务来完成，以检查用户是否已支付订阅费。主要问题是，该授权是否仍应在api gw端（A）或博客服务端（B）进行：

cms api gw/前端api gw:：listBlogs（）=>博客服务：：listBlogs（）

类似的情况-是否应该将任何格式的userContext/JWT传递给每个单独的微服务，并且该微服务应该决定返回什么？或者单个微服务不应该知道userContext（可能仅用于日志记录），依赖API GW授权，只接收一些参数/参数

我的想法：

在案例A中，由于授权层的原因，每个单独的微服务中的逻辑更加复杂。在API gws、用户角色等更多的地方，可能会变得更复杂。 然而，在这种情况下，API GW更简单，它只将请求转发给微服务

在案例B中，每个单独的微服务中的逻辑不那么复杂、简单和直接。然而，API GW中有更多的逻辑，因为它必须对所有平台（至少是该API GW负责的部分）实施授权。也许将所有授权集中在一个地方而不是分散在微服务中也是一种优势

同样在案例B中，我认为单个微服务之间的耦合更少

---

你们觉得这两种方法怎么样/也许你们还有其他“想法”

根据我的经验，案例A最容易扩展/维护。授权逻辑可能会与业务逻辑混淆

例如，假设您想要授权/updateBlog？id=52143方法。在网关中这样做不仅需要知道该用户已获得授权，还需要知道他们拥有该特定博客，或者他们已获得授权更新该博客

将所有这些逻辑导出到您的网关是可能的，但很棘手，最终会感觉高度重复。当逻辑改变时，这会变得更加痛苦，并且会在系统中产生级联效应。例如，假设您的/updateBlog授权现在有“来宾更新程序”。必须同时对/updateBlog服务和网关执行同步更新更为棘手，而且成本更高

---

这个故事的寓意是，在边境认证，在服务中授权。

好的观点！案例B很诱人（服务逻辑更简单/更清晰），但正如您所指出的，它可能会带来更多的问题而不是好处。谢谢