标签：服务 请求 Hystrix spring Eureka 线程 zuul cloud 底层
一、eureka
1)eureka原理
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，
下次再调用时，则直接从本地缓存中取，完成一次调用。
当服务注册中心Eureka Server检测到服务提供者因为宕机、网络原因不可用时，则在服务注册中心将服务置为DOWN状态，并把当前服务提供者状态向订阅者发布，订阅过的服务消费者更新本地缓存。
服务提供者在启动后，周期性（默认30秒）向Eureka Server发送心跳，以证明当前服务是可用状态。Eureka Server在一定的时间（默认90秒）未收到客户端的心跳，则认为服务宕机，注销该实例。
2)eureka自我保护机制
默认配置中，Eureka Server在90s没有得到客户端的心跳，则注销该实例。但是往往因为微服务跨进程调用，比如微服务状态正常，但是因为网络故障时，Eureka Server注销服务实例则会让大部分微服务不可用。
eureka.server.enable-self-preservation=true
原理:当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障），那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式。
二、ribbon
ribbion需自己构建并模拟http请求,然后使用RestTemplate发送给其他服务。
负载均衡:默认轮询(@LoadBalanced)
三、feign
feign基于ribbion,采用接口的方式调用
四、Hystrix(资源隔离,熔断器,命令模式)
1)Hystrix 如何解决级联故障/防止服务雪崩？
Hystrix将请求的逻辑进行封装，相关逻辑会在独立的线程中执行
Hystrix有自动超时策略，如果外部请求超过阈值，Hystrix会以超时来处理
Hystrix会为每个依赖维护一个线程池，当线程满载，不会进行线程排队，会直接终止操作
Hystrix有熔断机制： 在依赖服务失效比例超过阈值时，手动或者自动地切断服务一段时间
2)依赖隔离
Hystrix采用舱壁隔离模式隔离相互之间的依赖关系。
线程池:为每一个需要被调用的服务维护了一个独立的线程池，这样每个服务都有自己的使用资源，当某个服务出现问题时，大家互不影响。
当线程满载，不会进行线程排队，会Return fallback或者抛出异常。
信号量:同步的,当请求大于最大请求数(信号量计数器),调用失败方法。(资源消耗小)
3)Hystrix工作原理
构建Hystrix的Command对象, 调用执行方法.
Hystrix检查当前服务的熔断器开关是否开启, 若开启, 则执行降级服务getFallback方法.
若熔断器开关关闭, 则Hystrix检查当前服务的线程池是否能接收新的请求, 若超过线程池已满, 则执行降级服务getFallback方法.
若线程池接受请求, 则Hystrix开始执行服务调用具体逻辑run方法.
若服务执行失败, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.
若服务执行超时, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.
若服务执行成功, 返回正常结果.
若服务降级方法getFallback执行成功, 则返回降级结果.
若服务降级方法getFallback执行失败, 则抛出异常.
5)恢复原理
默认10秒内，超过50%请求失败，断路器断开。然后启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，熔断器将进入半开状态，释放一次请求到原来的主逻辑上，
如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复。
五、网关全局变量配置
1)URL路径匹配
# ? 单个字符
# * 任意多个字符，不包含多级路径
# ** 任意多个字符，包含多级路径
zuul.routes.eureka-application-service.path=/api/**
2)服务名称匹配
# serviceId用于配置符合path的请求路径路由到的服务名称。
zuul.routes.eureka-application-service.serviceId=eureka-application-service
3)路由排除配置
# 通配方式配置排除网关代理路径。所有符合ignored-patterns的请求路径都不被zuul网关代理。
zuul.ignored-patterns=/**/test/**
4)路由前缀配置
# 配置请求路径前缀，所有基于此前缀的请求都由zuul网关提供代理。
zuul.prefix=/api
六、Zuul网关过滤器
1)过滤器
Zuul中可以用来过滤代理请求，提供额外功能逻辑。如：权限验证，日志记录等。
Zuul过滤器:继承ZuulFilter,重写shouldFilter、run、filterType、filterOrder方法
过滤器类型:前置过滤、路由后过滤、后置过滤、异常过滤(filterType指定)。
2)内置的特殊过滤器
zuul还提供了一类特殊的过滤器，分别为：StaticResponseFilter和SurgicalDebugFilter
StaticResponseFilter：StaticResponseFilter允许从Zuul本身生成响应，而不是将请求转发到源。
SurgicalDebugFilter：SurgicalDebugFilter允许将特定请求路由到分隔的调试集群或主机。
3)自定义的过滤器
除了默认的过滤器类型，Zuul还允许我们创建自定义的过滤器类型。
例如，我们可以定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。
七、Zuul网关的限流保护
# 开启限流保护
zuul.ratelimit.enabled=true
当请求并发达到阀值，自动触发限流保护(全局/局部)，返回错误结果。//可以针对ip限流
八、zuul超时
zuul的底层使用的是Hystrix+ribbon来实现请求路由(配置文件配置:Hystrix+ribbon的超时时间)
zuul网关重试机制是使用spring-retry
标签：服务,请求,Hystrix,spring,Eureka,线程,zuul,cloud,底层 来源： https://blog.csdn.net/qq_37922915/article/details/117920834
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。