springcloud及其五大件（常用）理解

首先回顾下springcloud的理解及其的五大组件

首先官网定义springcloud：

什么是SpringCloud

springcloud基于springboot，大大简化开发；springcloud并不是一个框架，而是一个微服务整体架构，或者说springcloud是一个生态圈，
里面包含了很多的服务，每一个服务独立存在，相互之间互不干扰，可以直接运行。
　　其实springcloud就是一个完整的微服务架构，提供了所有功能，整个开发项目中
所需要的架构功能微服务都有，也就是说整个springcloud就是一个完整的项目，这个
架构已经搭建完毕了，用到了直接获取即可，只需要往架构中注入自己的业务代码就可以。

五大件：

1: eureka——注册中心

• springcloud之间的通信采用的是是http协议，服务之间的调用是传统的restful风格。
• 而eureka在springcloud中担任的是服务中心，云端服务发现，基于Rest用于定位服务，实现中间层服务发现和故障转移，服务中心保证了稳定性；
• eureka分为注册中心 server和分布式系统中的服务client，eureka server的内部会维护一个注册表，注册表其实是一个map结构，且client与server之间的通信也是基于http协议

{
“服务名称”: {
“节点编号1”: Lease<InstanceInfo>（ip地址和端口号等信息对象）,
“节点编号2”: Lease<InstanceInfo>,
“节点编号13”: Lease<InstanceInfo>
}
}

• client启动的时候会发送http请求到server，同时拉取（定时拉取合并）注册表来提供服务的调用
• client会定时发送心跳到server，代表还存活，实际发送星条就是改变Lease实例的一个时间戳
• 服务下线分为主动和被动，主动下线即client下线的时候会发送下线的http请求给server；被动下线就是server会定时对每个实例做心跳时间戳做统计，根据心跳时间戳进行判断这个实例是否存活。

整个eurake使用了大量的定时任务做处理，所以在实时性方面，比如下线一个服务，在eureka中会有延迟，心跳统计，client拉去注册表…涉及到定时任务几乎都有延迟
因为eurake采用的是http协议，http协议的数据传输并不是全双工。

2:ribbon----负载均衡模块

• ribbon提供一些常用的负载均衡的算法来实现正向代理，同时也是支持用户自己自定义算法，默认的是轮询

3:Feign----声明式的接口编程

• 相对与RestTemplate方式Feign简化了操作，通过对外暴露接口和springmv注解，spring会主动动态代理根据注解与eureka中的注册表，发送http请求到目标服务拿到相应的结果。
• 与上面结合，ribbon提供负载均衡，将请求均衡，分散压力；
• 再出现服务雪崩时候，Hystrix提供软缎服务

4: hystrix——资源隔离、限流、熔断、降级

• 出现服务雪崩问题，hystrix中的服务熔断和服务降级是解决其的主要手段
• 服务降级就是当某些给你出现响应过慢或者过载的情况下，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。
• 服务熔断：当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。Hystrix默认的超时时间为1s，请求时间超过1s，熔断次数加1。熔断机制有关闭，打开，半开状态

5:zuul——网关，请求路由和统一处理

• 在Spring Cloud体系中， Spring Cloud Zuul就是提供负载均衡、反向代理、权限认证的一个API gateway。
• Zuul服务最终还是会注册进Eureka 提供=代理+路由+过滤三大功能

springcloud的优势：

基于springboot，简化开发的同时，提供一个相对于完整的分布式系统的方案；对比double减少了学习成本

不足：

1:上面在eurake中提到的注册延迟问题

• Srping Cloud官方文档详细描述了该问题的原因并提供了解决方案。
  服务注册涉及到周期性心跳，默认30秒一次（通过客户端配置的serviceUrl）。只有当实例、服务器端和客户端的本地缓存中的元数据都相同时，服务才能被其他客户端发现（所以可能需要3次心跳）。可以使用参数eureka.instance.leaseRenwalIntervalInSeconds修改时间间隔，从而加快客户端连接到其他服务的过程。在生产环境中最好坚持使用默认值，因为在服务器内部有一些计算，他们会对续约做出假设。
  综上，要想解决服务注册慢的问题，只需将eureka.instance.leaseRenwalIntervalInSeconds设成一个更小的值，该配置用于EurekaClient向Eureka Server发送心跳的时间间隔，默认是30，单位是秒。在生产环境中，建议坚持使用默认值。

2:下线延迟问题

• 在开发环境下，常常希望Eureka Server能迅速有效地注销已停止的微服务实例。然而，
  由于Eureka Server清理无效节点周期长（默认90秒），以及自我保护模式等原因，可能
  会遇到微服务注销慢甚至不注销的问题。解决方案如下：

Eureka Server端：
配置关闭自我保护，并按需设置Eureka Server清理无效节点的时间间隔。
eureka.server.enable-self-preservation
#设置为false，关闭自我保护，从而保证会注销微服务
eureka.server.eviction-interval-timer-in-ms
#清理间隔（单位毫秒，默认是60*1000）

Eureka Client端：
配置开启健康检查，并按需配置持续更新的时间和到期时间。
eureka.client.healthcheck.enabled
#设为true，开启健康检查（需要spring-boot-starter-actuatoryi依赖）
eureka.instance.lease-xepiration-duration-in-seconds
#续约到期时间（默认90秒）

3:Hystrix/Feign整合Hystrix后首次请求失败/或者过慢

• Hystrix默认的超时时间是一秒，如果在1秒内得不到响应，就会进入fallback逻辑。
  主要原因是：由于Spring的懒加载机制，首次请求往往会比较慢，因此在某些机器（特别是配置低的机器）上，首次请求需要的时间可能就会大于1秒，触碰到了Hystrix的默认超市时间
  以下列举集中比较简单的方案：
  方法一：延长Hystrix的超时时间
  hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000
  该配置让Hystrix的超时时间改为5秒。
  方式二：禁用Hystrix的超时
  hystrix.command.default.execution.timeout.enabled: false
  方式三：对于Feign，还可为Feign禁用Hystrix（过于极端）
  feign.hystrix.enable: false

Spring Cloud定位问题思路

1:排查配置问题

• Spring Cloud应用程序无法正常启动。或配置无法正常加载，很多原因是配置无法正常驾照
• 比如在yml配置文件中缩进不规范

2:排查环境问题

• Java环境变量、Maven环境变量以及Docker容器环境变量等。当应用无法
  正常工作时，应该确保环境变量配置正确。
• 微服务之间通过网络保持通信，因此，网络常常是排查的关键。
• 依赖下载是否完整
  3:排查代码问题
• 很多时候常常是少了某个注解，或是依赖缺失，而导致了各种异常。
  4:排查Spring Cloud自身问题
• 如果确定不是代码问题，就可Debug一下Spring Cloud的代码了。