亚马逊产品开发seo搜索优化服务
目录：
（1）初识Sentinel-雪崩问题的解决方案
（2）服务保护Sentinel和Hystrix对比
（3）Sentinel初始-安转控制台
（4）整合微服务和Sentinel
微服务高级篇
（1）初识Sentinel-雪崩问题的解决方案
雪崩问题：假设说服务D出现了故障，在服务A的内部依赖服务D的这个业务请求就不能正常访问了，因为它访问服务D，需要等待服务D的结果，服务D出现故障，不会返回结果，会阻塞在这里，导致服务A内部的业务也会阻塞在这里，它就不会释放tomcat的连接，服务B和C的业务不受影响，在服务A中会有第一个第二个...依赖服务D的请求，加以时日依赖服务D的业务会越来越多，他们不会释放连接，一定会把服务A内部所有的连接都给占用了，tomcat的资源就耗尽了，服务A也会出现故障了
这就因为一个服务故障导致依赖它的服务也出现故障，在微服务里的服务关系是非常复杂的
第一种：它只是缓解雪崩问题，因为如果新进入新的请求的速度快于释放请求的速度，释放的速度没有，进入请求的速度快，终有一天资源也有可能会耗尽，设置请求时间只是一种缓解作用，不能从根本上解决这个问题
第二种：把tomcat里面的资源，也就是线程划分为一个一个独立的线程池，给每个业务分配为一个线程池，访问业务2做多使用10个线程，此时，比如说服务C故障了，这个业务会阻塞，它会占用我们的线程最多占用10个他能够使用的tomcat资源有限，把故障隔离到10个线程内，也叫线程隔离，避免了整个tomcat资源耗尽的情况，这种模式确实解决了线程耗尽的问题，但是它明知道服务C出现问题，还让他占够10个线程，有一定的资源浪费，所以有了第三种模式
第三种：有一个断路器来统计出现故障的请求和正常的请求比例，如果超出阈值，会熔断该请求
第四种：QPS每秒中处理请求的数量，限制QPS会避免因为流量突增而出现的故障
避免因为过多请求访问（高并发）出现故障，用到了Sentinel，假如说有无数的请求访问过来，而Sentinel会按照这个服务所能承受的频率，释放请求，这时候这个微服务就可以从容的应对这个请求了，避免了它出现故障，他不出现故障，就不会故障传递，出现雪崩问题，流量控制是预防雪崩
前面的三种 已经有服务故障了，是去怎么避免这个故障传递到其他服务，流量控制而是限制QPS避免出现故障，是一种预防的解决方案，高并发引起的故障只是故障的原因之一，服务还会因为其它问题出现故障，比如说：网络问题、FDC引起的假死问题等等，这个时候会用到其他的的方案
（2）服务保护Sentinel和Hystrix对比
Hystrix现在停止了维护，现在没落了，现在广泛使用的是Sentinel
Hystrix默认支持的是线程池隔离
线程池隔离：当一个业务请求进入tomcat以后，它会给每个业务创建一个独立的线程池，自然也会有独立的线程，因此它会比tomcat直接的这种处理方式多出很多很多线程，可以认为线程会成倍增长，虽然说隔离性比较好，但是随着线程的数量增长CPU会带来上下文切换的消耗，会有性能的损失
信号量隔离：当业务请求进入tomcat以后不会创建线程池，而是做一个统计，当前业务已经使用了几个线程，然后给你限制一下，你只能使用10个，当你已经使用了10个以后，当有新的业务，需要去获取线程时 就会阻止你了，会限制每个业务能够使用的线程数量 池子也就是那一个池子，tomcat默认的线程池，不会创建新的线程，也不会创建新的线程池，这样就减少了线程的创建，在隔离的基础上并没有影响性能，它的隔离性相比线程池差一点，因为毕竟在一个池子里面
Sentinel有开箱即用的控制台，可以监控微服务，查看微服务的运行状态，配置降级规则，限流规则，配置完立即生效
Hystris：控制台只用户查看服务的状态的功能，不具备动态修改规则的，相对来讲Sentinel的的功能相对强大
（3）Sentinel初始-安转控制台
复制到一个非中文的目录：
执行命令启动：
访问UI控制台页面:
只看到一个欢迎 语句，目前还没有跟微服务做整合，它没有监控任何东西
（4）整合微服务和Sentinel
加入依赖： 
配置sentinel地址：
重启order-service服务
先访问一个接口：端点
刷新Sentinel控制台：出现
