关于apisix:盘点微服务架构下的诸多身份验证方式

4次阅读

共计 2927 个字符，预计需要花费 8 分钟才能阅读完成。

联结作者：罗泽轩，API7.ai 技术专家、Apache APISIX PMC 成员
联结作者：赵士瑞，API7.ai 技术工程师，Apache APISIX Committer

身份认证是授予用户拜访零碎并授予应用零碎的必要权限的过程。而提供了这一性能的服务，就是身份认证服务。

在传统的单体软件应用程序中，所有这些都产生在同一个应用程序中。但在微服务架构中，零碎由多个服务组成，在这样的架构中，每个微服务都有本人的工作，因而为每个微服务别离实现受权和身份验证过程并不完全符合此准则。

本文将从传统服务架构和微服务架构下的身份认证形式区别进行探讨，并最终掂量微服务架构中身份认证服务的各种实现形式的优劣。

在企业开发服务的晚期，所有性能都是做到同一个应用程序外面的。咱们把这种模式称之为“单体”，以跟当下更为支流的“微服务”架构辨别开来。

单体利用由单个不可分割的单元组成。它通常由各个业务线各自开发，然而部署时放入到同一个环境中。所有这些都严密集成以在一个单元中提供所有性能。这一单元里领有所需的所有资源。单体利用的益处在于部署迭代简略，适宜业务线较少且比拟独立的公司采纳。

随着企业开发进去的业务越来越简单，咱们会发现单体服务曾经无奈满足现实生活外面疾速迭代的须要了。咱们须要把这个单体的巨无霸拆分一下，同时保障现有的各个性能间的调用能失常进行。这时候，ESB（企业服务总线）便应运而生了。

所谓的“企业服务总线”，就是一根连贯各个企业服务的管道。ESB 的存在是为了集成基于不同协定的不同服务，ESB 做了音讯的转化、解释以及路由的工作，以此来让不同的服务互联互通。从名称就能晓得，它的概念借鉴了计算机组成原理中的通信模型 —— 总线，所有须要和内部零碎通信的零碎，通通接入 ESB，就能够利用现有的零碎构建一个全新的松耦合的异构的分布式系统。

ESB 做了音讯的转换解释与路由等工作，让不同的服务互联互通。传统的 ESB 的服务调用形式是，每一次服务的调用者要向服务提供者进行服务交互申请时都必须通过核心的 ESB 来进行路由。

接下来将依照这两种状况，别离形容对应的身份认证性能的实现。

单体架构下，用户身份验证和会话治理绝对简略。身份认证和受权产生在同一个应用程序中，通常应用基于 session 的认证计划。一旦通过身份验证，就会创立一个会话并将其存储在服务器上，任何须要它的组件都能够拜访它并用于告诉和受权后续要求。会话 ID 被发送到客户端并用于应用程序的所有后续申请，以将申请与以后会话相关联。

在 ESB 架构下，所有用户与服务之间，服务与服务之间全副通过 ESB 总线进行解决。因为 ESB 的架构是从单体拆分下来的，身份认证形式绝对于单体架构并没有变动。

从单体架构迁徙到微服务架构有很多劣势，但微服务架构作为一种分布式架构，会存在更大的攻击面，共享用户上下文更加艰难。因而微服务架构下须要有跟传统架构不一样的身份认证服务，能力响应更大的安全性挑战。

目前，咱们能够把微服务架构下的身份认证服务分为以下三类：

通过每个微服务实现身份认证；
通过身份认证服务实现身份认证；
通过网关实现身份认证。
当然，每种做法都有本人特定的优缺点。

既然微服务架构是从单体架构拆分进去的，因而比拟天然的过渡形式就是由每个微服务本人实现身份认证。

每个微服务都须要实现本人独立的安全性保障，并在每个入口点上强制执行。此办法使微服务团队可能自主决定如何实现其平安解决方案。然而，这种办法有几个毛病：

平安逻辑须要在每个微服务中反复实现，这会导致服务之间的代码反复。
它扩散了开发团队的注意力，使其无奈专一于其次要服务。
每个微服务都依赖于它不领有的用户身份验证数据。
很难保护和监控。
欠缺这个解决方案的抉择之一就是应用一个加载在每个微服务上的共享认证库。这个操作能够避免代码反复，开发团队将只关注他们的业务畛域，但依然存在这种改良无奈解决的毛病。

因为共享的认证库依然须要有对应的用户身份数据，而且还须要保障各个微服务应用同样版本的认证库。诚实说，共享认证库更像是服务拆分不透彻的后果。

因而这种形式总结来说，劣势在于施行速度快，独立性强；而劣势也比拟显著，服务之间的代码反复、违反繁多职责准则，较难保护。

既然每个微服务本人实现身份认证难以保护，而应用共享认证库又违反了微服务拆分的本意，那么能不能把共享认证库升级成专门的身份认证服务呢？

在这种状况下，所有拜访都通过同一服务进行管制，相似于单体利用外面的身份认证性能。每个业务服务都必须在执行操作时，向访问控制模块发送独自的受权申请。

然而，这种办法在肯定水平上减慢了服务的运行速度，并减少了服务之间的互连量。并且各个微服务会依赖这个“单点”的身份认证服务。万一对立的身份认证服务出问题，会造成链式反应，带来二次挫伤。

所以总结来看，这种形式尽管确保了每个微服务职责繁多，使得身份认证性能更加集中。然而仍会造成单点依赖，进而减少申请提早。

迁徙到微服务体系结构时，须要答复的问题之一是微服务之间如何通信。后面提到的 ESB 是种计划，然而更常见的抉择则是采纳 API 网关。

API 网关是所有申请的单个终端节点入口，它通过充当应用这些微服务的地方接口来提供灵活性。某个须要拜访其余微服务的微服务（以下称之为“客户端”，以跟被它拜访的微服务相辨别）无权拜访多个服务，而是须要向负责将其路由到上游服务的 API 网关发送申请。

因为 API 网关位于客户端拜访的必经之路上，因而它是强制施行身份验证问题的绝佳抉择。应用 API 网关能够缩小提早（调用身份验证服务），并确保身份验证过程在整个应用程序中保持一致。

举个例子，通过 APISIX 的 jwt-auth 插件，咱们能够在网关上实现身份认证。

首先，咱们须要布局若干个用户身份信息（名称、密钥等等），并将其配置到 APISIX 上。其次，依据给定的用户密钥，向 APISIX 发动签名申请，失去这个用户的 JWT token。接着，当客户端须要拜访某个上游服务时，带上 JWT token，由 APISIX 作为 API 网关代理该拜访。最初，APISIX 会通过 JWT token，实现身份认证的操作。

当然，凡事无利就有弊，没有齐全无劣势的技术选型。应用网关来实现身份认证，还是带来了少许单点问题。比起在每个微服务内实现身份认证，在网关上解决该问题，安全性相比会升高些。比方 API 网关被攻破之后，就能够拜访该网关背地的任何微服务。然而危险是绝对的，比起对立的身份认证服务，应用 API 网关的单点问题并没有那么重大。

因而这种形式操作起来，在劣势上较为显著，比方能够无效爱护后端微服务，微服务不必解决任何认证逻辑等。但同时还是会存有少许的单点依赖。

在不同的场景下，咱们会须要不同的身份认证计划。在单体利用中，身份认证产生在同一个应用程序中，服务端保留了所有的会话。进入微服务时代，单体利用演变为分布式服务，单体利用中的身份认证形式在微服务中并不实用。在微服务架构中，咱们有上述提到的三种身份认证的形式可供选择。每种抉择都有属于本人的利弊，须要依据具体的理论状况做具体分析。

正文完