网关作用
1、客户端与微服务之间的隔离作用
2、非业务功能需求可以在网关进行集中处理。
3、在服务者和消费者中间提供了一层反向代理,充当前置负载均衡器的作用
API网关常见功能
- 请求监控
- 安全管理
- 路由规则
- 日志记录
- 访问控制
- 服务适配
Spring Cloud网关方案
1、集成 Netflix 中的 Zuul 网关 – 实现简单
2、自研 Spring Cloud Gateway – 性能较好
Zuul 网关依赖包
- 依赖包 :spring-cloud-starter-netflix-zuul
- 网关注解 :启动类 @EnableZuulProxy
- 自动成为 zuul 网关的入口
- 通过 @EnableZuulProxy 可以 使用Zuul各种内置过滤器 实现复杂的路由
server:
port: 5555
eureka:
instance:
preferIpAddress: true
client:
registerWithEureka: true
fetchRegistry: true
serviceUrl:
defaultZone: http://localhost:8761/eureka/
API 网关在其服务的消费者和提供者之间提供了一层反向代理,充当着前置负载均衡器的角色
所以,API 网关的定位决定了 Zuul 需要依赖 Ribbon
Zuul实现服务路由
- 服务地址 :http://zuulservice:5555/service (zuulservice 代表Zuul服务地址)
- 基于服务发现映射服务路由 :实现自动化服务路由,最常见也是最推荐的方式
- 映射规则 :匹配的规则就是直接将目标服务映射到服务名称上
- http://localhost:5555/actuator/routes” 是 Zuul 提供的服务路由端点,展示了目前在 Zuul 中配置的服务路由信息
基于动态配置映射服务路由
- 对一些定制化需求
- 不使用默认的服务名称来命名目标服务
- 在各个请求路径之前加一个统一的前缀(Prefix)
zuul:
prefix: /springhealth
routes:
ignored-services: 'userservice'
userservice: /user/**
基于静态配置映射服务路由
- zuul 不依赖于 Eureka注册中心 的服务路由
- 可以使用自定义的路由规则完成与其他各种第三方系统的集成
Zuul 会将该请求转发到外部的第三方服务http://thirdparty.com/thirdpartyservice中
zuul:
routes:
thirdpartyservice:
path: /thirdpartyservice/** url: http://thirdparty.com/thirdpartyservice
Zuul 能够与 Ribbon 进行整合
zuul:
routes:
thirdpartyservice:
path: /thirdpartyservice/** serviceId: thirdpartyservice // 关闭Ribbon于服务端的关联 ribbon: eureka: enabled: false // 手动指定Ribbon服务列表 thirdpartyservice: ribbon: listOfServers: http://thirdpartyservice1:8080,http://thirdpartyservice2:8080
- Zuul 响应HTTP过程是典型的过滤器解构,内置的 ZuulFilter 实现过滤器组件实现此机制
- filterType() 代表过滤器的类型 :内置过滤器分为 PRE、ROUTING、POST 和 ERROR 四种
- filterOrder() 方法用于设置过滤器的执行顺序
Spring Cloud Gateway
- 性能好,但是实现复杂,Spring Cloud Gateway 的源码非常复杂,出现问题不容易排查和解决
- 还支持请求限流等面向服务容错方面的功能
Spring Cloud Gateway 基本架构
- Spring Cloud Gateway 中的核心概念有两个,一个是过滤器(Filter),一个是谓词(Predicate)
- 而所谓谓词,本质上是一种判断条件,用于将 HTTP 请求与路由进行匹配
- 内置了大量的谓词组件,可以分别对 HTTP 请求的消息头、请求路径等常见的路由媒介进行自动匹配以便决定路由结果
- Spring Cloud Gateway 最主要的开发工作就是配置谓词和过滤器规则
在上述配置中,我们设置了 Eureka 服务的地址并启用了服务发现机制,然后根据 Eureka 保存的服务名称和地址定义了三条路由规则:userroute、deviceroute 和 interventionroute 分别对应 user-service、device-service 和 intervention-service 这三个微服务。这里,我们也通过在各个服务名称前面加上“lb://”来实现客户端负载均衡
服务容错
- 服务雪崩 :服务之间存在依赖调用,因为某一服务的不可用,而导致前面的调用方也不可用,所引发的连锁 反应,称之为服务雪崩。
- 服务雪崩的本质 :服务依赖失败
- 服务消费者容错 : 将服务消费者 所受的影响降低到最低。
服务容错模式
- 集群容错策略
- 服务隔离机制
- 服务限流机制
- 服务熔断机制
集群容错
- 服务冗余,即一个服务应该构建多个实例
- 常见集群容错策略 :Failover(失效转移)、Failback(失效通知)、Failsafe(失败安全)、Failfast(快速失败)
- Failover(失效转移) 最常见的容错粗略 :当发生服务调用异常时,请求会重新 在集群中查找下一个可用的服务 提供者实例
- Failover(失效转移) 会有最大重试次数限制
服务隔离
- 对资源进行有效 的管理,避免因资源不可用,发生失败等 情况 导致 服务系统中其它资源变得 不可用。
- 在发生故障时,将故障的传播和影响范围有效的控制
- 主要处理对象还是应用线程隔离 _ 线程池。每个服务有自己的线程最大值设置
- Spring Cloud Circuit Breaker 同样对服务隔离提供了不同维度和粒度的支持。
服务熔断
- 当系统出现异常情况时,能够直接熔断整个 服务的请求处理过程,避免一直等到请求处理完毕或 超时,避免资源浪费
- 当服务消费者向服务提供者发起远程调用时,服务熔断器会监控该次调用,如果调用的响应时间过长,服务熔断器就会中断本次调用并直接返回
- 服务熔断器会将所有的调用结果记录下来,如果发生异常调用次数达到一定的阈值则触发熔断
- 服务熔断开启后,服务调用将直接返回预定的 错误,而不执行真正的网络调用,同时熔断器内置时间间隔,当处理请求达到时间间隔进入半熔断状态
- Spring Cloud Circuit Breaker 中同样实现了服务熔断器组件
服务回退
- 临时、被动的处理机制、远程调用发生异常时,产生另外的 处理机制来应对异常,相当于返回一个默认的处理结果
- Spring Cloud Circuit Breaker 支持服务回退,开发人员只需要提供一个自定义回退方法(Fallback Method),就可以非常简单地使用这一机制来支持服务回退
Spring Cloud Circuit Breaker 框架
- Spring Cloud 中专门用于提供服务容错功能的
- Spring Cloud Circuit Breaker 是对熔断器的一种抽象
- Spring Cloud Circuit Breaker内置了四种熔断器
- Netflix Hystrix 来自 Netflix OSS
- Resilience4j 是受 Hystrix 项目启发所诞生的一款新型的容错库
- Sentinel 从定位上讲是一款包含了熔断降级功能的高可用流量防护组件
- Spring Retry 是 Spring 自研的重试和熔断框架
分布式配置中心
- Spring Cloud Config 框架来实现分布式配置中心
- 开发、测试、生产环境的配置文件统一保存在配置中心中
- 保证每个集群中所有服务内部保存的同一份配置信息能够得到同步的更新
- 配置中心,存在两个组成部分,即配置服务器和配置仓库
- 配置服务器的核心作用就是对接来自各个微服务的配置信息请求,这些微服务会通过配置服务器提供的统一接口获取存储在配置中心中的所需配置信息
- 确保对配置中心中所存储的各种配置信息进行统一维护;
- 提供一种通知机制,确保配置信息变化之后能够告知各个微服务,以便各个微服务及时更新本地服务中的配置数据
配置中心实现工具
- 一款是Etcd,它是一个轻量级分布式 Key-Value 对数据库,实现了数据更新、目录监听、分布式锁等功能特性
- Consul是一款由 Google 提供的开源框架,内置了服务注册与发现框架以及分布一致性协议实现机制,既可以用作配置中心,也可以用于构建注册中心
- Disconf是由百度开源的一个分布式配置管理工具,与 Spring 框架有很好的集成,在使用上也提供了友好的 Web 管理界面
- iamond 则由阿里巴巴提供,同样把配置数据存储在 MySQL 上,但在获取配置数据时不是使用的推送模式,而是每隔一段时间进行全量数据的拉取,实现过程比较简单
Zookeeper
- 一种分布式协调工具,它对每个节点都可以设置监听器 Watcher
- 节点监听机制可以用来实现实时感知,即当某一个节点的信息有任何变动时,所有监听该节点的其他节点都可以实时获取通知,从而做出响应
- 对于配置中心而言,所有服务就是 Zookeeper 的客户端,这些服务通过对包含配置信息的 Zookeeper 节点进行监听就能获取配置信息更新内容
Spring Cloud Config
- Zookeeper 是把配置信息保存在其内部的节点上,这些节点本质上就是操作系统的文件系统
- Spring Cloud Config 同样可以将配置信息保存在文件系统中,但更多的场景是推荐使用 Git 等配置仓库来存储配置信息
- 在关键的配置变化通知机制上,Zookeeper 依赖其变更事件的发送和 Watcher 机制来通知客户端
- Spring Cloud Config 则会发送事件到 Spring Cloud Bus 消息总线,然后由消息总线通知相关的服务
Spring Cloud Config 客户端更新策略
- 重启客户端 : 重启客户端时,会重新获取服务器端的配置信息,从而实现配置更新
- 使用Spring Boot Actuator : 专门用来监测和管理系统运行状态的组件,可以获取应用系统运行时数据和配置信息,并进行统一分析
- 使用 Spring Cloud Bus : 实现消息总线的专用组件,集成了 RabbitMQ、Kafka 等主流消息中间件
Spring Cloud Bus
- 如何自动调用服务器端所暴露的 /actuator/bus-refresh 端点
- 客户端如何得知服务器端的配置信息已经更新
- 客户端如何实时获取服务器端所更新的配置信息