SpringCloud精要-优快云博客

Part0：组件总览

拜托！面试请不要再问我Spring Cloud底层原理！

Part1：知识系列

纯洁的微笑 Spring Cloud 系列文章

Part2：常用组件总结

(一)：服务治理：Eureka(实际用阿里的Nacos比较多)

注册中心Eureka如何承载大型系统的千万级访问？
尴尬了！Spring Cloud微服务注册中心Eureka 2.x停止维护了咋办？
如何优化Spring Cloud微服务注册中心架构–Consul:CP
微服务：注册中心ZooKeeper、Eureka、Consul 、Nacos对比
常用配置参数
eureka.client.serviceUrl:指定注册中心；
eureka.client.registerWithEureka：是否要将自身的实例信息注册到Eureka服务端,
eureka.client.fetchRegistry：是否从Eureka服务端获取注册信息，默认true；
eureka.client.registryFetchlntervalSeconds：从Eureka服务端获取注册信
息的间隔时间,默认值30秒；
eureka.instance.leaseRenewallntervallnSeconds：Eureka客户端向服务端发送心跳的时间间隔,默认为秒30；
还有其他很多参数…

(二):客户端负载均衡：Ribbon(带@LoadBalanced注解的RestTamplate)

spring cloud ribbon使用总结及源码分析
【性能优化之道】每秒上万并发下的Spring Cloud参数优化实战
常用参数配置
设置连接超时时间,单位ms:ribbon.ConnectTimeout=5000
设置读取超时时间,单位ms:ribbon.ReadTimeout=5000
对所有操作请求都进行重试:ribbon.OkToRetryOnAllOperations=true
切换实例的重试次数:ribbon.MaxAutoRetriesNextServer=2
对当前实例的重试次数:ribbon.MaxAutoRetries=1

局部配置(指定服务配置)：
hello-service.ribbon.ConnectTimeout等

(三):服务容错保护：Hystrix(阿里的Sentinel)

spring clound hystrix使用总结
微服务架构如何保障双11狂欢下的99.99%高可用
Sentinel+Nacos实现资源流控、降级、热点、授权
功能介绍
服务熔断：当某服务出现不可用或响应超时的情况时，为了防止整个系统出现
雪崩，暂时停止对该服务的调用；
服务降级：它一般是和服务熔断一起使用的.当发生服务熔断后,可以调用熔断方法，把服务降级处理.比如可以记录失败log,发邮件等后面进入人工手动处理.
线程或信号隔离：为每一个依赖服务创建一个独立的线程池,这样就算某个依赖服务出现延迟过高的情况,也只是对该依赖服务的调用产生影响,而不会拖慢其他的依赖服务；
请求援存：Hystrix中提供了请求缓存的功能Request Context请求上下文,同一个请求接口相同，参数相同可以走缓存,我们可以方便地开启和使用请求缓存来优化系统,达到减轻高并发时的请求线程消耗、降低请求响应时间的效果；
请求合并：HystrixCollapser实现了在HystrixCommand之前放置一个合并处理器, 将处于一个很短的时间窗(默认10毫秒)内对同一依赖服务的多个请求进行整合井以批量方式发起请求的功能
服务监控：Hystrix 仪表盘、Turbine 集群监控等.
参数配置:

hystrix.command.default.execution.isolation.strategy 隔离策略，默认是Thread, 可选Thread｜Semaphore；
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时间，默认1000ms；
hystrix.command.default.execution.timeout.enabled 执行是否启用超时，默认启用true；
hystrix.command.default.execution.isolation.thread.interruptOnTimeout 发生超时是是否中断，默认true；
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests最大并发请求数,默认10,该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效.如果达到最大并发请求数,请求会被拒绝.理论上选择semaphore size的原则和选择thread size一致,但选用semaphore时每次执行的单元要比较小且执行速度快(ms级别),否则的话应该用thread；
更多参数点这里

注意：这里需要注意一点. Ribbon的超时与Hystrix的超时是两个概念.为了让上述实现有效,我们需要让Hystrix的超时时间大于Ribbon的超时时间,否则Hystrix命令超时后,该命令直接熔断, 重试机制就没有任何意义了。
两种熔断方式：线程池和信号量
Zuul 对 Hystrix 的线程隔离模式选择
Hystrix的线程池隔离和信号量隔离

(四):声明式服务调用Feign(实际当中还是直接使用Ribbion,即带Loadbalance注解的Resttemplate):

spring cloud feign使用总结
参数配置：
由于Feign整合了Ribbon与Hystrix，所以可以像配置Ribbon和Hystrix命令那样配置自己的参数.
一：Ribbon的配置
参考Ribbon部分。
二：Hystrix的配置
参考Hystrix部分。
三：禁用/启用Hystrix
全局配置：feign.hystrix.enabled=true/false或者hystrix.command.
default.execution.timeout.enabled=false；
局部配置：如果不想全局地关闭Hystrix支持,而只想针对某个服务客户端关闭Hystrix支持时,需要通过使用自Scope(“prototype”)注解为指定的客户端配置Feign.Builder实例即可.
四：其他配置
请求和响应压缩：支持对请求与响应进行GZIP 压缩，以减少通信过程中的性能损耗：
feign.compression.request.enabled=true;
feign.compression.response.enabled=true;
压缩请求数据类型
feign.compression.request.mime-types=text/xml ,
application/xml , application/json;
压缩最小下限，只有超过这个阀值才会压缩
feign.compression.request.min-request-size=2048.
日志配置：Spring Cloud Feign在构建被@FeignClient注解修饰的服务客户端时,会为每一个客户端都创建一个feign.Logger实例,我们可以利用该日志对象的DEBUG模式来帮助分析Feign的请求细节.

(五):Netflex网关服务Zuul(实际用spring cloud 2.x版本的gateway):

spring cloud zuul使用总结
请求路由:
方式一：定义path和url映射关系，基本上不用；
方式二：Zuul借助Eureka的服务发现机制，可以通过简单的path与serviceld的映射组合方式:zuul.routes.serviceId=path,其中serviceId用来指定路由的具体服务名, path用来配置匹配的请求表达式.比如
zuul.routes.user-service=/user-service/；
方式三：自定义路由映射规则，增加如下Bean的创建即可
@Bean
public PatternServiceRouteMapper serviceRouteMapper() {
return new PatternServiceRouteMapper("",""）；
};
校验过滤器：做一下权限验证.
filterType：返回一个字符串代表过滤器的类型，在zuul中定义了四种不同生命周期的过滤器类型，具体如下：
pre：路由之前，如内置的ServletDetectionFilter；
routing：路由之时，如内置的RibbonRoutingFilter；
post：路由之后，如内置的SendResponseFilter；
error：发送错误调用。
filterOrder：过滤的顺序
shouldFilter：这里可以写逻辑判断，是否要过滤，若为true,永远过滤。
run：过滤器的具体逻辑，比如去判断该请求到底有没有权限访问.
禁用过滤器：
方法一：shouldFilter返回false,可以禁止自定义过滤器；
方法二：zuul.SimpleClassName.filterType.disable=true；其中.
代表过滤器的类名，代表过滤器类,该参数配置除了可以对自定义的过滤器进行禁用配置之外,也可以禁用默认定义的核心过滤器
熔断机制:当我们的后端服务出现异常的时候，我们不希望将异常抛出给最外层，期望服务可以自动进行一降级实现FallbackProvider接口 .
Zuul限流：

字节跳动工作总结：高并发系统中的限流算法
SpringCloud-Zuul高并发请求下的限流处理
Spring Cloud限流详解
参数配置：
Zuul模板对ribbon和hystrix有依赖关系，所以Zuul天生就拥有线程隔离和断路器的自我保护功能.但是需要注意,当使用path与url的映射关系来配置路由规则的时候不会用到ribbon和hystrix功能,所以应该使用path和serviceld的组合来进行配置。

(六):分布式配置中心Config(实际用的是阿里的Nacos):

spring cloud config使用总结
注
(1): client端获取值：使用@Value注解来获取server端参数的值.
如果git配置改变了,为了使各个微服务能实时的获得更新的值，有以下四种解决方案：
1：重启应用；
2：需要给加载变量的类上面加载@RefreshScope；
3：github的webhook；
4：Spring Cloud Bus.

(2): Config Server巧妙地通过git clone将配置信息存于本地,起到了缓存的作用,即使当Git服务端无法访问的时候,依然可以取Config Server中的缓存内容进行使用.可以配置固定的缓存位置:spring.cloud.config.server.git.basedir=xxx;

(七):分布式服务跟踪：Sleuth(阿里的Tracing Analysis，收费的)

服务链路追踪Spring Cloud Sleuth
作用：跟踪微服务调用链情况.
在复杂的微服务架构系统中,几乎每一个前端请求都会形成一条复杂的分布式服务调用链路,在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败.这时候,对于每个请求,全链路调用的跟踪就变得越来越重要,通过实现对请求调用的跟踪可以帮助我们快速发现错误根源以及监控分析每条请求链路上的性能瓶颈等.