SpringCloud-Hystrix:服务熔断与降级

什么是Hystrix?

Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix能够保证在一个依赖出现问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关设置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方法返回一个服务预期的，可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

那么Hystrix能够做一些什么呢？

服务降级
服务熔断
服务限流
实时监控

以及一些分流，依赖分离之类等等。这里我们将用简单的介绍服务熔断和降级，并用代码简单演示一下。

什么是服务熔断？

熔断的目的是当A服务模块中的某块程序出现故障后为了不影响其他客户端的请求而做出的及时回应。

熔断是应对雪崩效应（如上，如果不停掉小明家的电，万一故障波及到了其他家）的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应实践太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。

什么是服务降级？

降级的目的是为了解决整体项目的压力，而牺牲掉某一服务模块而采取的措施。

熔断与降级的异同

相同之处：

目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；

区别之处：

触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）

nacos服务注册和发现

https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html

Nacos与eureka注册中心对比

对比项目\注册中心	Spring Cloud Nacos	Spring Cloud Eureka
CAP模型	支持AP和CP模型	AP模型
客户端更新服务信息	使用注册+DNS-f+健康检查模式。 DNS-F客户端使用监听模式push/pull拉取更新信息	客户端定时轮询服务端获取其他服务ip信息并对比，相比之下服务端压力较大、延迟较大
伸缩性	使用Raft选举算法性能、可用性、容错性均比较好，新加入节点无需与所有节点互相广播同步信息	由于使用广播同步信息，集群超过1000台机器后对eureka集群压力很大
健康检查模式/方式	支持服务端/客户端/关闭检查模式，检查方式有tcp、http、sql。支持自己构建健康检查器	客户端向服务端发送http心跳
负载均衡	支持	支持
手动上下线服务方式	通过控制台页面和API	通过调用API
跨中心同步	支持	不支持
k8s集成	支持	不支持
分组	Nacos可用根据业务和环境进行分组管理	不支持
权重	Nacos默认提供权重设置功能，调整承载流量压力	不支持
厂商	阿里巴巴	Netflix

服务配置中心对比

对比项目/配置中心	apollo	nacos
开源时间	2016.5	2018.6
配置实时推送	支持（HTTP长轮询1s内）	支持（HTTP长轮询1s内）
版本管理	自动管理	自动管理
配置回滚	支持	支持
权限管理	支持	待支持
多集群多环境	支持	支持
监听查询	支持	支持
多语言	Go,C++,Python,Java,.net,OpenAPI	Python,Java,Nodejs,OpenAPI
分布式高可用最小集群数量	Config2+Admin3+Portal*2+Mysql=8	Nacos*3+MySql=4
配置格式校验	支持	支持
通信协议	HTTP	HTTP
数据一致性	数据库模拟消息队列，Apollo定时读消息	HTTP异步通知
单机读（tps）	9000	15000
单机写（tps）	1100	1800

nacos具有Apollo大部分功能，最重要的是配置中心与注册中心打通，可以省去我们在微服务治理方面的一些投入（比如通过动态配置来启停线程池等操作）。

初步选型结论

初步结论为：使用Nacos代替Eureka和apollo，主要理由为：
相比与Eureka：
(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。
(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护
(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势
(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。
(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

相比于apollo
(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。
(2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则
(3)性能方面，Nacos读写tps比apollo稍强一些

sentinel服务熔断和限流

https://github.com/alibaba/Sentinel/wiki/介绍

Springcloud-Alibaba整合路由网关(Gateway)

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul 网关。网关作为流量的，在微服务系统中有着非常作用。据说性能是第一代网关 zuul的1.5倍。(基于Netty,WebFlux)。

添加依赖

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-gateway</artifactId>
 </dependency>
 <!--nacos依赖 -->
 <dependency>
     <groupId>com.alibaba.cloud</groupId>
     <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
 </dependency>

yml文件

#规划GateWay的服务端口
server:
  port: 8888
##规划gateWay注册到到nacos上的服务应用名称
spring:
  application:
    name: api-gateway
  cloud:
    nacos:
      discovery:
        #gateway工程注册到nacos上的地址
        server-addr: localhost:8848
    gateway:
      discovery:
        locator:
          #开启gateway从nacos上获取服务列表
          enabled: false
  profiles:
    active: xxxxx  # 具体的gateway配置
#开启acutor端点
management:
  endpoints:
    web:
      exposure:
        include: '*'
  endpoint:
    health:
      #打开端点详情
      show-details: always

写注解

@SpringBootApplication
@EnableDiscoveryClient
public class GatewayDemo{
	public static void main(String[] args) {
		SpringApplication.run(GatewayDemo.class, args);
	}
}

Springcloud Alibaba Sentinel 整合网关Spring Cloud Gateway

Sentinel 支持对 Spring Cloud Gateway 等主流的 API Gateway 进行限流。

https://blog.csdn.net/u010046908/article/details/100015060