SpringCloud常见问题

1.关于自我保护机制                                                                                                                     什么是自我保护机制：  这篇介绍的很好，简单说就是每个服务实例启动后都会注册到注册中心Eureka中，并且以心跳的方式告诉注册中心实例还活着，如果注册中心在较短时间内丢失了大量心跳，Eureka会认为可能是由于通信故障造成的，这种情况Eureka认为不应该删除实例，于是就开启自我保护机制                                                                                                       判断是否开启自我保护机制，主要在于计算每分钟续约数的，getNumOfRenewInLastMin()这个获取的是每分钟的续约数量（每个客户端来续约的时候，都是会更新这个值的，每分钟重置一次，有线程去跑的）， 如果每分钟的续约数量>最小续约数（常量），则不需要开启自我保护机制， 如果是小于，那么就是需要开启， 所以当返回false的时候，就需要开启自我保护机制了。

    PS： 其实说白了，自我保护机制，就是在定时任务执行之前，判断每分钟的续约数量，然后决定是否继续执行下去。因此Eureka Server的过期时间（默认60s） ,客户端的续约时间（默认30s） , 这个配置最好不要更改，如果更改的话就会打破自我保护机制的规则。

解除

    当服务的网络分区解除之后，客户端能够和服务进行交互时，在续约的时候，更新每分钟的续约数，当每分钟的续约数大于最大续约数85%时，则自动解除自我保护机制

2.推测：Eureka server定时去清理无效节点，首先判断自我保护机制有没有设置为false,如果是直接去判断哪些是无效节点，然后剔除。判断的依据是距离上一次收到心跳的时间间隔是否大于某个值（在客户端配置），是就剔除。如果自我保护机制没有设置，则系统在定时任务触发时会判断每分钟续约数量是否大于最大续约数的85%,如果大于就不开启，如果小于就开启（相当于短时间内丢失了大量续约，自我保护机制开启）

3.客户端配置的心跳频率要比过期时间高

4.获取服务                                                                                                                                消费者服务启动时，会发送一个Rest请求给服务注册中心，来获取上面注册的服务清单。同时该缓存清单默认会每隔30秒更新一次。

5.用Http Status Code传递Server的状态信息。比如最常用的 200 表示成功，500 表示Server内部错误，403表示Bad Request等。（反例：传统web开发返回的状态码一律都是200，其实不可取。

6.ribbon.ReadTimeout， ribbon.SocketTimeout这两个就是ribbon超时时间设置，还有zuul.host.connect-timeout-millis， zuul.host.socket-timeout-millis这两个配置，这两个和上面的ribbon都是配超时的。区别在于，如果路由方式是serviceId的方式，那么ribbon的生效，如果是url的方式，则zuul.host开头的生效。（此处重要！使用serviceId路由和url路由是不一样的超时策略）

7.熔断超时是这样的：

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 60000

default代表默认，如果你想为某个特定的service配熔断超时策略，可将default换为服务名

8.ribbon.connectTimeot是请求连接的时间，基本上都是很短的，所以这个请求的时间可以忽略不记，ribbon.readTimeout=5000，所耗费的时间基本上都是在请求的处理时间上。所以计算的公式是（1+maxAutoRetries+maxAutoRetriesNestServer)*5000,该计算公式会得出一个值，hystrix的超时时间最好要大于这个值，如果小于这个值的话，那么配置重试就没有意义了，因为当系统还在进行重试的时候，就把这一次的请求熔断了

9.假设服务提供者响应非常缓慢，那么消费者对提供者的请求线程就会被等待，直到服务返回，在高并发高负载的场景下，如果不做任何处理，这种问题很有可能造成所有处理用户请求的线程的资源耗竭，而不能响应用户进一步请求。

    如果服务消费者又是另外服务的提供者，那么有可能产生级联反应，导致其它的下一级服务消费者不可用，最终产生雪崩效应。

    当依赖的服务不可用的时候，或者因为网络问题，响应时间会变得很长（几十秒）。而通常情况下，一次远程调用对应了一个线程或者进程，如果响应太慢，那这个线程、进程就会得不到释放。而线程和进程是系统资源，如果大量线程、进程都不被释放，越积越多，服务资源就会被耗尽。所以我们必须设置超时请求

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路径一致

15.类似SpringCloud微服务适合敏捷开发，restful风格，适合大公司，人多的情况