2.推测:Eureka server定时去清理无效节点,首先判断自我保护机制有没有设置为false,如果是直接去判断哪些是无效节点,然后剔除。判断的依据是距离上一次收到心跳的时间间隔是否大于某个值(在客户端配置),是就剔除。如果自我保护机制没有设置,则系统在定时任务触发时会判断每分钟续约数量是否大于最大续约数的85%,如果大于就不开启,如果小于就开启(相当于短时间内丢失了大量续约,自我保护机制开启)
4.获取服务 消费者服务启动时,会发送一个Rest请求给服务注册中心,来获取上面注册的服务清单。同时该缓存清单默认会每隔30秒更新一次。
6.ribbon.ReadTimeout, ribbon.SocketTimeout这两个就是ribbon超时时间设置,还有zuul.host.connect-timeout-millis, zuul.host.socket-timeout-millis这两个配置,这两个和上面的ribbon都是配超时的。区别在于,如果路由方式是serviceId的方式,那么ribbon的生效,如果是url的方式,则zuul.host开头的生效。(此处重要!使用serviceId路由和url路由是不一样的超时策略)
8.ribbon.connectTimeot是请求连接的时间,基本上都是很短的,所以这个请求的时间可以忽略不记,ribbon.readTimeout=5000,所耗费的时间基本上都是在请求的处理时间上。所以计算的公式是(1+maxAutoRetries+maxAutoRetriesNestServer)*5000,该计算公式会得出一个值,hystrix的超时时间最好要大于这个值,如果小于这个值的话,那么配置重试就没有意义了,因为当系统还在进行重试的时候,就把这一次的请求熔断了
10.注册中心需要集群,1台主,其余副,只有主注册中心有服务注册,主挂掉后有同步机制同步到其它注册中心,中心只是拿地址,本地调用zuul网关服务既可作为提供者也可作为消费者
11.服务隔离就是对不同方法使用不同的线程池,这样对A方法的高并发不会影响到B方法 nginx:c语言开发 zuul: java语言
12.Eureka还提供了客户端缓存的机制,即使所有的Eureka Server都挂掉,客户端仍可以利用缓存中的信息调用服务节点的服务
13.get和post的表单请求是可以获取到参数的,但是post 的原生字符串请求,也就是application/json类型的请求是获取不到的,你需要从流中读取,就是request中getInputStream获取,但是流只能获取一次,如果你在过滤器中读取了流,spring控制器里就接受不到参数了,当然你可以重新包装下request,把参数重新写回包装后的request中
14.zuul中的path不能和serviceId中的requestmapping路径一致