springcloud

spring cloud 总结

eureka

实现思路

在com.netflix.discovery.DiscoveryClient启动的时候，会初始化一个定时任务，定时的把本地的服务配置信息，即需要注册到远端的服务信息自动刷新到注册服务器上。

通过http方式与服务交互,每个服务会以心跳的方式通知eureka,eureka会统计最后一分钟内的心跳次数(Renews (last min)),如果心跳次数小于eureka的Renews threshold值则开启保护模式.

eureka内部有定时任务清除已经过期的服务(既规定周期内(可以配置)没有心跳的服务)
心跳周期也可以配置

相应的每个服务都会缓存eureka的注册信息提高效率

https://github.com/Netflix/eureka/wiki/Eureka-REST-operations

http://tietang.wang/

http://fanlychie.github.io/post/spring-cloud-netflix-eureka.html

eureka优势zk

优点：

Eureka提供了一个客户端库，该库提供了服务心跳、服务健康检查、自动发布及缓存刷新等功能。

如果使用ZooKeeper，这些功能都需要自己实现，并且zookeeper通过心跳发现服务不可用时，会立即删除注册到zookeeper的服务；而eureka不会立即删除服务，因为注册的服务有可能只是因为网络轻微波动导致无法发送心跳，并不是服务不可用。

Eureka在客户端会有缓存。即使所有Eureka服务器不可用，服务注册信息也不会丢失。缓存在这里是恰当的，因为它只在所有的Eureka服务器都没响应的情况下才会用到。

Eureka使用Ribbon组件实现客户端负载均衡策略

缺点：

当所有服务端都同时停止之后，然后重启，客户端需要等待一定时间（最长30s，因为客户端会30s请求一次eureka注册中心）才能连接服务端，因为虽然在注册中心显示服务端已经注册，但是服务有可能还没有全启动，所以需要等待（其实也不像缺点–！）

ribbon

默认负载均衡方式（轮询）

主要组件

组件	描述
IRule	负载均衡策略,可以插件化的为LB提供各种适用的负载均衡算法
Iping	判断目标服务是否存活对应不同的协议不同的方式去探测，得到后端服务是否存活。如有http的，还有对于微服务框架内的服务存活的NIWSDiscoveryPing是通过eureka client来获取的instanceinfo中的信息来获取。
LoadBalancerStats	LB运行信息记录LB的实时运行信息，这些运行信息可以被用来作为LB策略的输入。

策略名	策略描述	实现说明
BestAvailableRule	选择一个最小的并发请求的server	逐个考察Server，如果Server被tripped了，则忽略，在选择其中ActiveRequestsCount最小的server
AvailabilityFilteringRule	过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值）	使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个server的运行状态
WeightedResponseTimeRule	根据相应时间分配一个weight，相应时间越长，weight越小，被选中的可能性越低。	一个后台线程定期的从status里面读取评价响应时间，为每个server计算一个weight。Weight的计算也比较简单responsetime 减去每个server自己平均的responsetime是server的权重。当刚开始运行，没有形成statas时，使用roubine策略选择server。
RetryRule	对选定的负载均衡策略机上重试机制。	在一个配置时间段内当选择server不成功，则一直尝试使用subRule的方式选择一个可用的server
RoundRobinRule	roundRobin方式轮询选择server	轮询index，选择index对应位置的server
RandomRule	随机选择一个server	在index上随机，选择index对应位置的server
ZoneAvoidanceRule	复合判断server所在区域的性能和server的可用性选择server	使用ZoneAvoidancePredicate和AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。

https://blog.csdn.net/dyc87112/article/details/73739485

zuul

适合做路由和方向代理，通常接入外网的服务可以借助该服务，或者除springcloud项目其他语言写的服务也可以用该服务作为反向代理。

1.支持动态从eureka读取service_id，通过小写service_id为路径转发到相应服务

2.支持手动文件配置方式，配置转发

zuul:
  routes:
    get:
      path: /get/**
      url: http://127.0.0.1:9099
    my-service:
      path: /BESTBUY-WX/**
      serviceId: BESTBUY-WX
    images:
      path: /image/**
      url: http://httpbin.org/image

3.zuul参数设置

zuul.host.maxTotalConnections

适用于ApacheHttpClient，如果是okhttp无效。每个服务的http客户端连接池最大连接，默认是200.

zuul.host.maxPerRouteConnections

适用于ApacheHttpClient，如果是okhttp无效。每个route可用的最大连接数，默认值是20。

zuul.semaphore.max-semaphores

Hystrix最大的并发请求 execution.isolation.semaphore.maxConcurrentRequests ，这个值并非 TPS 、 QPS 、 RPS 等都是相对值，指的是1秒时间窗口内的事务/查询/请求， semaphore.maxConcurrentRequests 是一个绝对值，无时间窗口，相当于亚毫秒级的。当请求达到或超过该设置值后，其其余就会被拒绝。默认值是100。

zuul.host.maxTotalConnections: 200
zuul.host.maxPerRouteConnections: 10
#zuul.semaphore.max-semaphores: 128
# 建议使用这种方式来设置，可以给每个不同的后端微服务设置不同的信号量
zuul.eureka.[service id].semaphore.maxSemaphores: 128

Hystrix

断路器

当一段时间内有部分请求超时或者超出当前服务的并发量(可以设置)时,这些请求会调用降级方法,如果失败的请求数量大于一定的阈值(可以设置)时则断路器开启,断路器开启时则所有请求全部降级(为了保护后台服务),当一段时间后(可配置),断路器则变为尝试关闭状态,此时会放开部分请求,例如:100个请求40个可以正常处理,剩下60个则继续走降级方法,如果正常处理的40个请求中大部分处理成功则关闭断路器,此后所有请求都可以正常处理.

线程隔离概念:保证一个服务出现了问题不会影响到其他服务

https://www.tuicool.com/articles/VVbuaeZ

https://www.tuicool.com/articles/ZzyyI32

配置timeout

1
2
3

@HystrixCommand(fallbackMethod = "timeout", commandProperties = {
           @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")
   })

sleuth zipkin

在spring cloud项目中sleth实现了一个分布式探针跟踪解决方案，借用了Dapper、zipkin和Htrace的思想；

对于大多数用户来说探针是无感知的，并且能看到与其他系统的调用关系；

我们可以把数据记录到日志文件，或将数据发送到远程收集服务；

术语：

Span: sleuth工作的基本单位，span是由一个独特的唯一的id和Trace的id组成一部分；这其中也包含一些描述、时间戳事件、key-value注解和进程ID的（通常为IP地址）；

span有开始就有结束

Trace：一组span形成的树状结构的表示，trace ID是全局唯一的；例如：调用service1的服务接口，该接口又调用service2的接口，两个接口之间通过trace来唯一表示这次完整的树状请求结构；

Annotation：用于记录一个事件的存在时间。用于定义一个请求的开始和停止的核心注释

cs：Client Sent 客户机发送-客户端已经提出了要求。此注释描述了跨度的开始。
sr：Server Received 服务器端收到的请求，并将开始处理它。如果减去CS时间戳从这个时间戳人会收到网络延迟。
ss：Server Sent 完成请求处理后发送的服务（当响应返回到客户端时）。如果减去SR时间戳从这个时间戳将接收由服务器端处理请求所需的时间。
cr：Client Received 客户端接收到的-表示span的结束。客户端已成功接收来自服务器端的响应。如果减去CS时间戳从这个时间戳人会收到由客户端需要从服务器接收响应的整个时间