首页 > 解决方案 > 微服务集群中的授权架构

问题描述

我有一个带有微服务架构的项目(在 Docker 和 Kubernetes 上),两个主要的应用程序是使用 AIOHTTP 和 Django 用 Python 编写的(还有 Ingress 代理、静态文件服务器,还有几个是用 NginX 制作的)。我想将这些 Python 应用程序拆分为单独的更小的微服务,但为了实现这一点,我可能还应该将身份验证移到单独的应用程序中。但是我该怎么做呢?

可能我还应该补充一点,我不是在询问特定的身份验证方法,如 OAuth、JWT 等,而是关于集群架构内的依赖关系和责任划分。

在我看来,一个不错的解决方案是 Ingress NginX 代理服务器的一些插件,或者它之前的微服务,这样我的 Python 身份验证代理就不会关心方法目标,比如一些中间件,只需读取 headers/cookies,检查访问令牌或 sessionId,如果访问有效,则设置 userId,并进一步传递请求。

一个简短的简化架构如下所示:

当前架构

这就是我的想象,提及更少的复杂连接:

所需架构

但我不确定这是否合理。此外,这种方法会降低 K8s Ingress 的优势,它为从 bash 更新路径表提供了惊人的接口,但是据我所知,它不允许在它之前运行任何请求处理程序,所以我必须在没有很好的 K8s 集成的情况下运行自定义 NginX 代理。

因此,还有哪些其他可能的架构解决方案?

我只能想象创建一个请求处理程序,它执行所有授权并将请求传递给其他不关心身份验证的微服务(或通过 RPC),但我认为这不是一个普遍完美的解决方案。

标签: pythonauthenticationkubernetesproxyarchitecture

解决方案


理论

嗯,在网上挖掘和咨询了一年半之后,找到了很多资料。有一个名为API Gateway的架构模式,它描述了集群中的入口点,这正是Kubernetes Ingress所做的,也是我在问题中所想象的。在一般情况下,它是代理服务器,它是集群微服务的唯一入口点,它可以执行缓存、DDoS 保护,它可以支持不同的 API 协议、操作 URI、管理 API 节流、货币化和执行身份验证我需要。因此,在集群内部的微服务通信过程中没有身份验证,因为所有需要的参数、标识符都会在请求中呈现。

执行

在 Kubernetes 中,NginX Ingress相当流行,它还支持 Basic Auth 和 OAuth2,这不是一个完美的解决方案,但至少是一些东西。Kubernetes 有其他 Ingress 解决方案:Kong、Ambassador、Traefik,它们提供了更多功能(尽管 Kong 也基于 NginX)。

在 Java 和 Spring 的世界中,存在Spring Cloud Gateway来解决此类问题,就像 K8s Ingress 一样,它允许使用 YAML 描述路径表,但它是可扩展的,允许轻松嵌入您的自定义代码以用于任何身份验证方法。

此外,大多数云平台都提供了自己的 API 网关服务或多或少的功能,包括Google CloudRed HatAWSYandex Cloud。但是,它们似乎缺乏身份验证方法,就像扩展的机会一样,尽管它们在这个问题上并没有太大的相关性。

读书

您可以在此处找到有关 API 网关模式及其实现的更多信息:


推荐阅读