微服务集群中的授权架构

Question

微服务集群中的授权架构

Aiv*_*nF. 6 python architecture authentication proxy kubernetes

我有一个具有微服务架构的项目（在 Docker 和 Kubernetes 上），2 个主要应用程序是使用 AIOHTTP 和 Django 用 Python 编写的（还有 Ingress 代理、静态文件服务器，还有一些是用 NginX 制作的）。我想将这些 Python 应用程序拆分为单独的较小的微服务，但为了实现这一目标，我可能还应该将身份验证移至单独的应用程序中。但我该怎么做呢？

也许我还应该补充一点，我问的不是特定的身份验证方法，如 OAuth、JWT 等，而是关于集群架构内部的依赖关系和职责划分。

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

下面介绍了一个简短且简化的架构：

这是我的想象，少提一些复杂的联系：

但我不确定这是否合理。此外，这种方法会减少 K8s Ingress 的优势，K8s Ingress 提供了用于从 bash 更新路径表的惊人接口，但据我所知，不允许在它之前运行任何请求处理程序，所以我必须运行自定义 NginX 代理，无需良好的 K8s 集成。

那么，还有哪些其他可能的架构解决方案呢？

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

Answer 1

Aiv*_*nF. 6

理论

嗯，在网上查了很多资料，咨询了一年半，找到了。有一种名为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 Cloud、Red Hat、AWS、Yandex Cloud。然而，它们似乎缺乏身份验证方法，就像扩展的机会一样，尽管它们与这个问题没有太大关系。

读书

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

归档时间：	5 年，7 月前
查看次数：	4036 次
最近记录：	4 年，6 月前