微服务网关授权（微服务网关如何调用服务）-eolink官网

微服务网关授权（微服务网关如何调用服务）

本篇文章给大家谈谈微服务网关授权，以及微服务网关如何调用服务对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。今天给各位分享微服务网关授权的知识，其中也会对微服务网关如何调用服务进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

1、微服务方式实现双重网关
2、微服务六：服务网关
3、微服务权限终极解决方案（spring-cloud-gateway-oauth2）
4、为什么微服务需要API网关
5、微服务的四种认证鉴权方式
6、微服务网关

微服务方式实现双重网关

最近在做一个多项目整合的工作，因为每个项目都有自己的一套网关，每个网关都有自己的加解密算法，整合到一起要求对外提供统一的用户鉴权，而且不对原有系统做大规模的重构，基于这些现实考虑使用两重API网关架构来构建新系统的统一网关体系。

备注：其中的统一网关、业务网关、业务微服务都是微服务的模式注册到微服务中心。

这个网关采用zuul来进行网关过滤及路由，其中过滤规则由各个业务网关以微服务方式提供，通过Feign来调用，这个方式也是区别于传统网关的，也是实现双重网关的关键所在。
这里要遵循的基本原则是：授权/鉴权一体化，即授权策略和鉴权方法都是由各个业务网关自己维护，这样就确保了功能的封闭性和一致性，在开发和后期维护中都非常的方便高效。

备注：这个类是zuul的主类实现了过滤/路由，其中的鉴权部分调用了相关的微服务，这些微服务以@Autowired的方式注入进来。
接口定义如下：

路由策略通过配置实现，因为是微服务所以直接指定路由到的微服务id即可，配置文件可以存储到微服务治理中心的配置中心。

备注：其中的user-base、user-org分别是两个业务微服务。

这个网关集群按照业务划分，每个网关实现了授权和鉴权的策略算法，并以微服务的方式提供，其中授权是对相关敏感信息做加密并以token的方式存储到cookie中，鉴权是将存储在客户端的token通过相应的解密算法进行核验和鉴权，确保该token的合法性、有效性，只有有效的token才能够通过鉴权并解析出敏感信息传递到指定的路由服务中。

备注：该网关使用JWT进行敏感数据加密

备注：该网关使用RSA进行敏感数据加密
H5业务网关以微服务方式提供了授权/鉴权服务，其中授权服务直接暴露给客户端，客户端调用后将业务类型app_type和授权token写入cookie，鉴权服务暴露给统一网关，对传递的token进行鉴权，鉴权成功后将token中的加密信息解析出来后返回给统一网关，由统一网关路由到业务微服务并将该参数传递下去。

备注：其中register、login是生成授权token流程，readUserinfo是通过token鉴权后访问业务微服务的流程。

微服务六：服务网关

服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关(Service Gateway)，见图（15），网关是连接企业内部和外部系统的一道门，有如下关键作用：

服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。

限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。

监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。

日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。

图（15）gateway服务图

除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

网关通常工作在7层，有一定的计算逻辑，一般以集群方式部署，前置LB进行负载均衡。

开源的网关组件有Netflix的Zuul，其工作原理如下图。

图（16）zuul工作原理图

在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图(17)来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内LB服务发现和负载均衡机制。在图（17）的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务Middle Tier Service）和前端服务（也称边缘服务Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如PC，Pad或者Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似Proxy代理或者Façade门面模式，而服务注册表和服务自注册自发现类似IoC依赖注入模式，微服务可以理解为基于网关代理和注册表IoC构建的分布式系统。

图（17）简化的微服务架构图

微服务权限终极解决方案（spring-cloud-gateway-oauth2）

我们理想的微服务权限解决方案应该是这样的，认证服务负责认证，网关负责校验认证和鉴权，其他API服务负责处理自己的业务逻辑。安全相关的逻辑只存在于认证服务和网关服务中，其他服务只是单纯地提供服务而没有任何安全相关逻辑。

通过认证服务( oauth2-auth )进行统一认证，然后通过网关（ oauth2-gateway ）来统一校验认证和鉴权。采用Nacos作为注册中心，Gateway作为网关，使用nimbus-jose-jwtJWT库操作JWT令牌。

接下来搭建网关服务，它将作为Oauth2的资源服务、客户端服务使用，对访问微服务的请求进行统一的校验认证和鉴权操作

最后我们搭建一个API服务，它不会集成和实现任何安全相关逻辑，全靠网关来保护它

在此之前先启动我们的 Nacos 和 Redis 服务，然后依次启动 oauth2-auth 、 oauth2-gateway 及 oauth2-api 服务

我这里测试使用的 Docker 跑的单机版的 Nacos

github.com/it-wwh/spring-cloud-gateway-oauth2

微服务网关授权（微服务网关如何调用服务）

为什么微服务需要API网关

1.防止内部关注暴露给外部客户端
API网关将外部公共API与内部微服务API分开，允许添加微服务和更改边界。其结果是能够在不对外部绑定客户端产生负面影响的情况下重构和适当大小的微服务。它还通过为您的所有微服务提供单一入口点，对客户端隐藏了服务发现和版本控制详细信息。
2.为您的微服务添加额外的安全层
API网关通过提供一个额外的保护层来防止恶意攻击，例如SQL注入，XML解析器漏洞和拒绝服务（DoS）攻击。
3.支持混合通信协议
虽然面向外部的API通常提供基于HTTP或REST的API，但是内部微服务可以从使用不同的通信协议中受益。协议可能包括的Protobuf或AMQP ，或者用SOAP，JSON-RPC或XML-RPC系统集成。 API网关可以在这些不同的协议之上提供外部的，统一的基于REST的API，允许团队选择最适合内部架构的API。
4.降低微服务复杂性
如果微服务具有共同的关注点，例如使用API令牌的授权，访问控制实施和速率限制。每个这些关注可以通过要求每个服务都实现它们，但这为微服务的开发增加更多的时间成本。 API网关将从您的代码中删除这些问题，允许您的微服务关注手头的任务。
5.微服务模拟和虚拟化
通过将微服务API与外部API分离，您可以模拟或虚拟化服务，以验证设计要求或协助集成测试。

微服务的四种认证鉴权方式

1. 单点登录（SSO）

这种方案意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，当动辄数十个微应用时，这种方案的弊端会更加明显。
2. 分布式 Session 方案

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。在某些场景下，这种方案很不错，用户登录状态是不透明的。同时也是一个高可用且可扩展的解决方案。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全链接来访问，这时解决方案的实现就通常具有相当高的复杂性了。
3. 客户端 Token 方案

令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，Borsos（David Borsos）更喜欢使用 JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。
4. 客户端 Token 与 API 网关结合

这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。在请求时，网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌。