微服务保护
1 Sentinel入门
1.1 雪崩问题
1.1.1 什么是雪崩问题
首先，微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。
假如，下图的场景中，A服务要调用D服务，但是呢，D服务中执行较慢，需要60s，这时A服务的调用就会阻塞，但是这个业务也占用A服务的一个线程，与此同时，假如大量的请求再次涌入A服务，就会导致A服务线程耗尽，进而A服务也寄了。
再因为微服务这种千丝万缕的调用关系，导致项目都寄了：
总结：雪崩就是微服务调用过程中某个服务故障，导致链路中所有微服务都不可以用
1.1.2 如何解决雪崩
设置超时时间
设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待。
拿上面那个例子举例，A向D发送请求，D要60s处理，那我直接超时时间为5s，不会一直等D，1s没处理就之间请求失败了
但是呢，高并发场景下，1s可能有1000个请求，所以单单设置超时时间不行
仓壁模式
限定每个业务可以使用的线程数，避免耗尽整个Tomcat的资源，也叫线程隔离
具体的，如下图，尽管C慢，尽管来了1000个请求，但是对于调用C的请求我只给你10个线程的线程数，所以不会导致整个架构崩盘
但是但是，如果服务C一直有问题，虽然不会浪费过多的线程，但每次的10个线程调用c都是失败，也就是每隔一会就会浪费一些线程。
熔断降级
类似于家里的保险丝，用电量过大，会跳闸，断电
由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。也就是假如某个微服务老出问题，那么一段时间内不会再去访问这个微服务。
熔断后，对于A到D的请求，之间响应给用户失败，非常的快
限流（预防措施）
限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩
限制业务访问的QPS，避免服务因流量的突增而故障。
因为业务人员其实知道你这个微服务能承受多少访问量，那么来了大量请求时，设置每秒钟放行的请求数，防止雪崩出现
1.2 服务保护技术对比
早期比较流行的是Hystrix框架，但目前国内实用最广泛的还是阿里巴巴的Sentinel框架，这里我们做下对比：
1.3 Sentinel介绍与安装
Sentinel 特征
•丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
•完备的实时监控：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
•广泛的开源生态：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
•完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 安装
1）下载
sentinel官方提供了UI控制台，方便我们对系统做限流设置，可以在GitHub下载
2）运行
将jar包放到任意非中文目录，执行命令：
java -jar sentinel-dashboard-1.8.1.jar
如果要修改Sentinel的默认端口、账户、密码，可以通过下列配置：
当然也可以基于 docker运行
docker run --name sentinel -d -p 8858:8858 bladex/sentinel-dashboard:1.8.0
3）访问
访问http://localhost:8080页面，就可以看到sentinel的控制台了：
