有一个具有微服务架构的服务器项目（在 Docker 和 Kuber 上），大部分代码是使用 AIOHTTP 和 Django 用两个 Python 服务编写的（也有使用 NginX 的服务：Ingress，一个静态文件服务器和其他几个） . 我想将这两个服务拆分为更小的服务，以简化代码库并使其更易于管理。那我想把认证检查的授权放到一个单独的微服务中，但是如何实现呢？
我还要澄清一下，问题的本质不在于授权方法，如 OAuth、JWT 等，而具体在于集群架构中的职责和依赖关系的分配。
在我看来，一个好的解决方案是为 Ingress NginX 或它前面的代理服务器添加某种插件，这样这个微服务本身就不知道具体的方法，比如一个授权中间件，它检查 headers/cookies 的访问权限令牌或会话，如果成功则设置用户 ID。
当前架构的简化版本如下所示：
我如何提出一个可能的解决方案，以便减少混淆的联系：
但我不确定这是否是一个适当的解决方案。至少，这种方法会剥夺项目 Kuber 的 Ingress 的优势，它提供了一个很酷的界面，用于使用控制台中的配置更新路径方案，但据我所知，它不允许提前处理请求，这就是为什么你必须在不方便与 K8s 集成的情况下提出自定义 NginX。
在行业中解决这个问题的替代方案是什么？
我只能想象创建一个请求处理程序来检查授权，然后通过 HTTP/RPC 将请求委托给其他微服务，无需授权；但我怀疑这是一个好的解决方案，因为这样的代理必须解析整个请求，然后再创建一个新的；此外，在其他微服务中，加载了 NginX 的实例作为外部 API 的代理，似乎在它们面前这样的授权代理将成为瓶颈。
理论
所以，我在网络中挖掘和咨询了一年半后发现了什么。有一个架构模式API Gateway，它描述了集群的入口点，事实上，这与Kubernetes Ingress所做的和我在问题中得到的一样。一般来说，这是一个代理服务器，它是集群的唯一入口点，它可以处理缓存、保护集群免受 DDoS 攻击、支持不同的 API 协议、操作 URI 路径、管理节流、货币化以及我需要的授权. 因此，在集群内，当微服务相互通信时，不再存在授权问题，所有必要的参数都会在请求中呈现。
执行
NginX Ingress在 Kubernetes 中很流行，并且支持 Basic Auth 和 OAuth2；不是很好，但至少是一些东西。Ingress for Kubernetes 也有替代版本：Kong、Ambassador、Traefik，它们的功能范围更广（同时，Kong 是基于 NginX 的）。
在 Java 和 Spring 的世界里，有一个Spring Cloud Gateway就是为了这个目的，它和 K8s Ingress 一样，提供了一种以 YAML 格式描述路径表的便捷方式，同时也是一个可扩展的服务，让您可以轻松嵌入任何身份验证方法在进入集群之前。
此外，许多云平台都或多或少地提供了自己的服务，包括Google Cloud、Red Hat、AWS、Yandex Cloud。但是，这些服务似乎不支持授权方法，或者至少不支持扩展，因此它们与这件事无关。
读
有关 API 网关和实现的更多详细信息，请参见此处：