统⼀服务⼊⼝-Gateway
- 1. ⽹关介绍
- 1.1 问题
- 1.2 什么是API⽹关
- 1.3 常⻅⽹关实现
- Zuul
- Spring Cloud Gateway
- 2. 上手
1. ⽹关介绍
1.1 问题
前⾯的课程中, 我们通过Eureka, Nacos解决了服务注册, 服务发现的问题, 使⽤Spring Cloud LoadBalance解决了负载均衡的问题, 使⽤OpenFeign解决了远程调⽤的问题.
但是当前所有微服务的接⼝都是直接对外暴露的, 可以直接通过外部访问. 为了保证对外服务的安全性服务端实现的微服务接⼝通常都带有⼀定的权限校验机制. 由于使⽤了微服务, 原本⼀个应⽤的的多个模块拆分成了多个应⽤, 我们不得不实现多次校验逻辑. 当这套逻辑需要修改时, 我们需要修改多个应⽤, 加重了开发⼈员的负担.
针对以上问题, ⼀个常⽤的解决⽅案是使⽤API⽹关.
⽐如企业管理
外部⼈员去公司办理业务, 公司需要先核实对⽅的⾝份再去进⾏办理.
最开始只有⼀个员⼯, 这个员⼯核实之后直接办理即可. (单体架构)
随着公司的发展, 划分了多个部⻔, 每个部⻔负责的事情不同, 每个部⻔都需要先核实对⽅的⾝份再进⾏办理. (微服务架构)
这个流程存在⼀些问题:
- 办事效率低
- 增加了员⼯的⼯作流程
我们对此进⾏改进, 设⽴前台, 统⼀由前台来进⾏⾝份的校验. 前台⾝份校验通过后, 其他部⻔就设置
信任, 直接办理.
1.2 什么是API⽹关
API⽹关(简称⽹关)也是⼀个服务, 通常是后端服务的唯⼀⼊⼝. 它的定义类似设计模式中的Facade模式(⻔⾯模式, 也称外观模式). 它就类似整个微服务架构的⻔⾯, 所有的外部客⼾端访问, 都需要经过它来进⾏调度和过滤
⽹关核⼼功能:
权限控制: 作为微服务的⼊⼝, 对⽤⼾进⾏权限校验, 如果校验失败则进⾏拦截
动态路由: ⼀切请求先经过⽹关, 但⽹关不处理业务, ⽽是根据某种规则, 把请求转发到某个微服务
负载均衡: 当路由的⽬标服务有多个时, 还需要做负载均衡
限流: 请求流量过⾼时, 按照⽹关中配置微服务能够接受的流量进⾏放⾏, 避免服务压⼒过⼤
类似前台的⼯作
- 权限控制: ⾝份验证
- 动态路由: 根据外来客⼾的需求, 把客⼾带到指定的部⻔去处理
- 负载均衡: ⼀个部⻔有很多⼈时, 前台会帮客⼾选择具体某个⼈处理
- 限流: 公司到访客⼾较多时, 进⾏流量限制, ⽐如告知明天再来
1.3 常⻅⽹关实现
业界常⽤的⽹关⽅式有很多, 技术⽅案也较成熟, 其中不乏很多开源产品, ⽐如Nginx, Kong, Zuul,Spring Cloud Gateway等. 下⾯介绍两种常⻅的⽹关⽅案.
Zuul
Zuul 是 Netflix 公司开源的⼀个API⽹关组件, 是Spring Cloud Netflix ⼦项⽬的核⼼组件之⼀，它可以和 Eureka、Ribbon、Hystrix 等组件配合使⽤.
在Spring Cloud Finchley正式版之前, Spring Cloud推荐的⽹关是Netflix提供的Zuul(此处指Zuul 1.X).然⽽Netflix在2018年宣布⼀部分组件进⼊维护状态, 不再进⾏新特性的开发. 这部分组件中就包含Zuul
Spring Cloud Gateway
Spring Cloud Gateway 是Spring Cloud的⼀个全新的API⽹关项⽬, 基于Spring + SpringBoot等技术开发, ⽬的是为了替换掉Zuul. 旨在为微服务架构提供⼀种简单⽽有效的途径来转发请求, 并为他们提供横切关注点, ⽐如: 安全性, 监控/指标和弹性.
在性能⽅⾯, 根据官⽅提供的测试报告, Spring Cloud Gateway的RPS(每秒请求数)是Zuul的1.6倍. 测试报告参考: https://github.com/spencergibb/spring-cloud-gateway-bench
2. 上手
gateway 代码示例
