Consul
Consul是一套开源的分布式服务发现和配置管理系统,有HashiCorp公司用Go语言开发。
提供了微服务系统中的服务治理、配置中心、控制总线等功能。这些功能可以根据需要单独使用,也可以一起使用以构建全方位的服务网格,总之Consul提供了一种完整的服务网格解决方案。
-----------------------------------------------------------------------------------------------
Ribbon
Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡工具。主要功能是提供客户端的负载均衡算法和服务调用(负载均衡 + RestTemplate),此外还提供了连接超时、重试等功能。使用Ribbon可以很容易的实现全局或者局部的自定义负载均衡算法。
Ribbon也称进程内负载均衡。相对应的是集中式负载均衡,比如负载均衡软件:Nginx、LVS,负载均衡硬件: F5这些都是集中式负载均衡,集中式负载均衡在有些文案中也称服务端负载均衡。
-----------------------------------------------------------------------------------------------
Feign
Feign是一个声明式的WEB服务客户端(服务调用/消费方),它简化了WEB服务客户端的实现,只需要创建一个接口并添加相应的注解即可。
Feign集成了Ribbon。相对于RestTemplate + Ribbon的调用方式,使用Feign对服务的调用优雅而简单,而且Feign结合Hystrix进行熔断和降级都很方便。使用Feign注解定义的接口,调用接口中的方法就可以实现对服务注册中心的服务的调用。从编码角度来说,使用Feign对其他服务进行调用和调用本地的功能接口是一样的(XXController中注入XXService调用本地服务接口)。
OpenFeign
OpenFeign在Feign的基础上支持了Spring MVC的注解,如@RequestMapping等。OpenFeign的@FeignClient可以解析Spring MVC的@RequestMapping注解下的接口,并通过动态代理的方式生成实现类,实现类中做负载均衡并调用相应的服务
-----------------------------------------------------------------------------------------------
Hystrix
- 作用: 通过熔断、降级保持分布式系统的可用性,防止雪崩效应的发生
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,服务间的远程调用不可避免的会调用失败(比如超时、异常),Hystrix能够保证在某个调用出问题的情况下,不会导致整体服务失败,避免级联故障(也称服务雪崩),提高分布式系统弹性。
“断路器” 本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选(兜底)响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常。这样就保证了调用方处理请求的线程不会被长时间、不必要的占用,从而避免故障在分布式系统里蔓延,乃至雪崩。
-
服务降级
-
服务不可用时,不让调用者等待并且立刻返回一个兜底的响应(FallBack)
-
常见发生降级的情况:异常,超时,服务熔断,线程池、信号量打满
-
服务熔断
-
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点的微服务调用,当检测到该节点的微服务调用响应正常后,恢复调用链
-
在SpringCloud框架中,熔断机制由Hystrix实现。Hystrix会监控微服务间调用的状况,当失败的调用达到设定的阀值(默认5秒内20次调用50%失败),就会启动熔断机制,熔断一定的时间(默认5秒)后,检查熔断的服务是否恢复正常,如果是则恢复调用链,否则继续熔断,所有请求进行降级响应。
-
熔断状态迁移: Closed -> Open -> Half Open -> Closed/Open
1.某个接口正常运行,断路器处于关闭状态【Closed】
2.在一个时间窗口期(默认10秒)内,接口被调用超过20次(默认值),且调用失败率达到50%(默认值), 此时断路器开启(接口故障)【Open】,后续所有对接口的调用直接降级返回
3.一段时间后(默认5秒),断路器尝试进入半开状态【Half Open】,让其中一个调用进行正常处理(不降级 返回),如果成功则说明故障解除,断路器进入关闭状态【Closed】。否则断路器进入开启状态【Open】
-
服务限流
-
秒杀、高并发等操作,不允许一窝蜂的过来访问,一个个排队,1秒钟N个,有序进行
-
资源隔离: 信号量模式、线程池模式
-
所谓**资源隔离,就是将多个依赖服务的调用隔离到自己的资源池内。避免因为某一个依赖服务的调用故障,导致调用方所在服务所有的线程资源全部耗费在这个故障的调用上。**线程资源一旦耗尽,对于单个服务造成服务崩溃,对于整个分布式系统可能会不断蔓延造成级联故障(也称服务雪崩)。
-
信号量模式: 不支持超时,当下游服务发生问题,有少部分用户会长时间无法得到响应
-
**线程池模式: 无法传递Header,需要用ThreadLocal + 拦截器等方案解决
**
-----------------------------------------------------------------------------------------------
Spring Cloud Gateway
Spring Cloud Gateway是基于WebFlux框架实现的新一代网关,WebFlux框架的底层则使用了高性能的Reactor模式通信框架Netty,异步非阻塞模型(相对与Zuul1.0的阻塞模型)。
Gateway核心:
-
Route(路由)
-
路由是构建网关的基本模块,由ID、目标URl、断言,过滤器组成,如果断言为True则匹配该路由
-
Predicate(断言)
-
路由是否匹配的条件,匹配则将请求转发给服务处理并响应
-
实际上是一个结果为布尔值(true/false)的表达式,参考java.utli.function.Predicate
-
Filter(过滤器)
-
Spring框架中GatewayFilter的实例,通过过滤器可以在路由前后对请求进行修改
-
过滤器常用场景:参数校验、权限校验、流量监控、日志搜集、限流、流量监控等
-
过滤器类型: pre、post
Gateway工作流程: 路由转发 + 执行过滤器链
1.客户端 (Gateway Client)向网关(Spring Cloud Gateway)发出请求。
2.网关通在Gateway Handler Mapping中找到与请求相匹配的路由,将其发送到Gateway Web Handler
3.Gateway Web Handler再通过指定的过滤器链将请求发送到我们实际的微服务执行业务处理(发送代理请求),然后返回
注意: 图中过滤器之间的虚线表示“pre”和“post”类型的过滤器(如果有) 在【3】发送代理请求前后 执行过滤器的逻辑
路由配置示例
-----------------------------------------------------------------------------------------------
Spring Cloud Config & Bus
Spring Cloud Config ,基础设施,分布式配置中心。分为服务端(Config Server)和客户端(Config Client)。
为微服务架构中的微服务提供集中化的外部配置支持.以实现集中管理配置文件、不同环境不同配置等功能。
Spring Cloud Bus ,基础设施,消息总线。配合Spring Cloud Config配置中心使用以实现配置的动态刷新。
Spring Cloud Bus支持2中消息代理:RabbitMQ、Kafka.
**Spring Cloud Bus 基本原理
**
下图中通过调用Config Server的 /bus/refresh接口,通知所有消息总线的其他服务获取新的配置
下图中通过调用某个Config client的 /bus/refresh接口,通过消息总线逐渐传播给其他服务,通知它们获取新的配置。(不建议这种方式,打破了微服务的职责单一性,服务费本身是业务模块,刷新配置有基础设施完成更加合理)
ConfigClient实例都监听MQ中的同一个Topic(默认是SpringCloudBus),当一个服务刷新数据的时候,新的信息放入到Topec中,监听Topic的其他服务会收到通知,然后更新自身配置
-----------------------------------------------------------------------------------------------
Spring Cloud Stream
常用消息中间件: RabbitMQ、RocketMQ、ActiveMQ、Kafka
Spring Cloud Stream, 消息驱动,屏蔽了消息中间件的差异,降低切换成本,统一消息的编程模型。
-----------------------------------------------------------------------------------------------
Spring Cloud Sleuth
在微服务框架中,客户端发起的请求在后端系统中会经过多个不同微服务节点的调用来协同产生最后的请求结果,从而形成一条复杂的分布式服务调用链路,链路中的任何一环出现超时或者错误都会引起客户端请求的失败。
Spring Cloud Sleuth提供了一套完整的服务跟踪解决方案。