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

标签: 盘点 微服务 架构 | 发表时间:2023-01-10 16:59 | 作者:Apache_APISIX_中文社区
出处:https://juejin.cn/tag/%E6%9E%B6%E6%9E%84

联合作者:罗泽轩,API7.ai 技术专家、Apache APISIX PMC 成员

联合作者:赵士瑞,API7.ai 技术工程师,Apache APISIX Committer

身份认证是授予用户访问系统并授予使用系统的必要权限的过程。而提供了这一功能的服务,就是身份认证服务。

在传统的单体软件应用程序中,所有这些都发生在同一个应用程序中。但在微服务架构中,系统由多个服务组成,在这样的架构中,每个微服务都有自己的任务,因此为每个微服务分别实现授权和身份验证过程并不完全符合此原则。

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

传统服务架构中的身份认证服务

在企业开发服务的早期,所有功能都是做到同一个应用程序里面的。我们把这种模式称之为 “单体”,以跟当下更为主流的 “微服务” 架构区分开来。

单体应用由单个不可分割的单元组成。它通常由各个业务线各自开发,但是部署时放入到同一个环境中。所有这些都紧密集成以在一个单元中提供所有功能。这一单元里拥有所需的所有资源。单体应用的好处在于部署迭代简单,适合业务线较少且比较独立的公司采用。

随着企业开发出来的业务越来越复杂,我们会发现单体服务已经无法满足现实生活里面快速迭代的需要了。我们需要把这个单体的巨无霸拆分一下,同时保证现有的各个功能间的调用能正常进行。这时候,ESB(企业服务总线)便应运而生了。

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

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

接下来将按照这两种情况,分别描述对应的身份认证功能的实现。

单体架构

单体架构下,用户身份验证和会话管理相对简单。身份认证和授权发生在同一个应用程序中,通常使用基于 session 的认证方案。一旦通过身份验证,就会创建一个会话并将其存储在服务器上,任何需要它的组件都可以访问它并用于通知和授权后续要求。会话 ID 被发送到客户端并用于应用程序的所有后续请求,以将请求与当前会话相关联。

ESB 架构

在 ESB 架构下,所有用户与服务之间,服务与服务之间全部通过 ESB 总线进行处理。由于 ESB 的架构是从单体拆分下来的,身份认证方式相对于单体架构并没有变化。

微服务架构中的身份认证服务

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

目前,我们可以把微服务架构下的身份认证服务分为以下三类:

  1. 通过每个微服务实现身份认证;
  2. 通过身份认证服务实现身份认证;
  3. 通过网关实现身份认证。 当然,每种做法都有自己特定的优缺点。

通过每个微服务实现身份认证

既然微服务架构是从单体架构拆分出来的,因此比较自然的过渡方式就是由每个微服务自己实现身份认证。

每个微服务自己实现身份认证

每个微服务都需要实现自己独立的安全性保障,并在每个入口点上强制执行。此方法使微服务团队能够自主决定如何实现其安全解决方案。但是,这种方法有几个缺点:

  • 安全逻辑需要在每个微服务中重复实现,这会导致服务之间的代码重复。
  • 它分散了开发团队的注意力,使其无法专注于其主要服务。
  • 每个微服务都依赖于它不拥有的用户身份验证数据。
  • 很难维护和监控。 完善这个解决方案的选择之一就是使用一个加载在每个微服务上的共享认证库。这个操作可以防止代码重复,开发团队将只关注他们的业务领域,但仍然存在这种改进无法解决的缺点。

因为共享的认证库仍然需要有对应的用户身份数据,而且还需要保证各个微服务使用同样版本的认证库。老实说,共享认证库更像是服务拆分不透彻的结果。

因此这种方式总结来说,优势在于实施速度快,独立性强;而劣势也比较明显,服务之间的代码重复、违反单一职责原则,较难维护。

通过身份认证服务实现身份认证

既然每个微服务自己实现身份认证难以维护,而使用共享认证库又违背了微服务拆分的本意,那么能不能把共享认证库升级成专门的身份认证服务呢?

身份认证服务

在这种情况下,所有访问都通过同一服务进行控制,类似于单体应用里面的身份认证功能。每个业务服务都必须在执行操作时,向访问控制模块发送单独的授权请求。

但是,这种方法在一定程度上减慢了服务的运行速度,并增加了服务之间的互连量。并且各个微服务会依赖这个“单点”的身份认证服务。万一统一的身份认证服务出问题,会造成链式反应,带来二次伤害。

所以总结来看,这种方式虽然确保了每个微服务职责单一,使得身份认证功能更加集中。但是仍会造成单点依赖,进而增加请求延迟。

通过网关实现身份认证

迁移到微服务体系结构时,需要回答的问题之一是微服务之间如何通信。前面提到的 ESB 是种方案,但是更常见的选择则是采用 API 网关。

网关实现身份认证

API 网关是所有请求的单个终端节点入口,它通过充当使用这些微服务的中央接口来提供灵活性。某个需要访问其他微服务的微服务(以下称之为“客户端”,以跟被它访问的微服务相区分)无权访问多个服务,而是需要向负责将其路由到上游服务的 API 网关发送请求。

由于 API 网关位于客户端访问的必经之路上,因此它是强制实施身份验证问题的绝佳选择。使用 API 网关可以减少延迟(调用身份验证服务),并确保身份验证过程在整个应用程序中保持一致。

举个例子,通过 APISIX 的 jwt-auth 插件,我们可以在网关上实现身份认证。

首先,我们需要规划若干个用户身份信息(名称、密钥等等),并将其配置到 APISIX 上。 其次,根据给定的用户密钥,向 APISIX 发起签名请求,得到这个用户的 JWT token。 接着,当客户端需要访问某个上游服务时,带上 JWT token,由 APISIX 作为 API 网关代理该访问。 最后,APISIX 会通过 JWT token,完成身份认证的操作。

当然,凡事有利就有弊,没有完全无劣势的技术选型。使用网关来完成身份认证,还是带来了少许单点问题。比起在每个微服务内完成身份认证,在网关上解决该问题,安全性相比会降低些。比如 API 网关被攻破之后,就可以访问该网关背后的任何微服务。但是风险是相对的,比起统一的身份认证服务,使用 API 网关的单点问题并没有那么严重。

因此这种方式操作起来,在优势上较为明显,比如可以有效保护后端微服务,微服务不用处理任何认证逻辑等。但同时还是会存有少许的单点依赖。

总结

在不同的场景下,我们会需要不同的身份认证方案。在单体应用中,身份认证发生在同一个应用程序中,服务端保存了所有的会话。进入微服务时代,单体应用演变为分布式服务,单体应用中的身份认证方式在微服务中并不适用。在微服务架构中,我们有上述提到的三种身份认证的方式可供选择。每种选择都有属于自己的利弊,需要根据具体的实际情况做具体分析。

相关 [盘点 微服务 架构] 推荐:

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

- - 掘金 架构
联合作者:罗泽轩,API7.ai 技术专家、Apache APISIX PMC 成员. 联合作者:赵士瑞,API7.ai 技术工程师,Apache APISIX Committer. 身份认证是授予用户访问系统并授予使用系统的必要权限的过程. 而提供了这一功能的服务,就是身份认证服务. 在传统的单体软件应用程序中,所有这些都发生在同一个应用程序中.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.

微服务架构之事件驱动架构 - 简书

- -
为了解决传统的单体应用(Monolithic Application)在可扩展性、可靠性、适应性、高部署成本等方面的问题,许多公司(比如Amazon、eBay和NetFlix等)开始使用微服务架构(Microservice Architecture)构建自己的应用. 微服务(Microservices) 是一种软件架构风格 (Software Architecture Style),它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯.