springcloud 技术栈总结

Eureka简介
Eureka包含两个组件：Eureka Server 和 Eureka Client，它们的作用如下：
Eureka Server提供服务发现的能力，各个微服务启动时，会向Eureka Server注册自己的信息（例如IP、端口、微服务名称等），Eureka Server会存储这些信息；
Eureka Client是一个Java客户端，用于简化与Eureka Server的交互；
微服务启动后，会周期性（默认30秒）地向Eureka Server发送心跳以续约自己的“租期”；
如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认90秒）；
默认情况下，Eureka Server同时也是Eureka Client。多个Eureka Server实例，互相之间通过增量复制的方式，来实现服务注册表中数据的同步。Eureka Server默认保证在90秒内，Eureka Server集群内的所有实例中的数据达到一致（从这个架构来看，Eureka Server所有实例所处的角色都是对等的，没有类似Zookeeper、Consul、Etcd等软件的选举过程，也不存在主从，所有的节点都是主节点。Eureka官方将Eureka Server集群中的所有实例称为“对等体（peer）”）
Eureka Client会缓存服务注册表中的信息。这种方式有一定的优势——首先，微服务无需每次请求都查询Eureka Server，从而降低了Eureka Server的压力；其次，即使Eureka Server所有节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者并完成调用。
综上，Eureka通过心跳检查、客户端缓存等机制，提高了系统的灵活性、可伸缩性和可用性。

Ribbon简介
Ribbon是Netflix发布的负载均衡器，它可以帮我们控制HTTP和TCP客户端的行为。只需为Ribbon配置服务提供者地址列表，Ribbon就可基于负载均衡算法计算出要请求的目标服务地址。
Ribbon默认为我们提供了很多的负载均衡算法，例如轮询、随机、响应时间加权等——当然，为Ribbon自定义负载均衡算法也非常容易，只需实现IRule 接口即可。

Feign简介
Feign是Netflix开发的声明式、模板化的HTTP客户端，其灵感来自Retrofit、JAXRS-2.0以及WebSocket。Feign可帮助我们更加便捷、优雅地调用HTTP API。
在Spring Cloud中，使用Feign非常简单——只需创建接口，并在接口上添加注解即可。
Feign支持多种注解，例如Feign自带的注解或者JAX-RS注解等。Spring Cloud对Feign进行了增强，使其支持Spring MVC注解，另外还整合了Ribbon和Eureka，从而使得Feign的使用更加方便。
Feign本身已经整合了Hystrix，可直接使用@FeignClient(value = “microservice-provider-user”, fallback = XXX.class) 来指定fallback类，fallback类继承@FeignClient所标注的接口即可。

应用容错三板斧
超时机制
超时机制你懂的，配置一下超时时间，例如1秒——每次请求在1秒内必须返回，否则到点就把线程掐死，释放资源！
思路：一旦超时，就释放资源。由于释放资源速度较快，应用就不会那么容易被拖死。
舱壁模式
有兴趣的可以先了解一下船舱构造——一般来说，现代的轮船都会分很多舱室，舱室之间用钢板焊死，彼此隔离。这样即使有某个/某些船舱进水，也不会影响其他舱室，浮力够，船不会沉。
软件世界里的仓壁模式可以这样理解：M类使用线程池1，N类使用线程池2，彼此的线程池不同，并且为每个类分配的线程池较小，例如coreSize=10。举个例子：M类调用B服务，N类调用C服务，如果M类和N类使用相同的线程池，那么如果B服务挂了，M类调用B服务的接口并发又很高，你又没有任何保护措施，你的服务就很可能被M类拖死。而如果M类有自己的线程池，N类也有自己的线程池，如果B服务挂了，M类顶多是将自己的线程池占满，不会影响N类的线程池——于是N类依然能正常工作，
思路：不把鸡蛋放在一个篮子里。你有你的线程池，我有我的线程池，你的线程池满了和我没关系，你挂了也和我没关系。
断路器
现实世界的断路器大家肯定都很了解，每个人家里都会有断路器。断路器实时监控电路的情况，如果发现电路电流异常，就会跳闸，从而防止电路被烧毁。
软件世界的断路器可以这样理解：实时监测应用，如果发现在一定时间内失败次数/失败率达到一定阈值，就“跳闸”，断路器打开——此时，请求直接返回，而不去调用原本调用的逻辑。
跳闸一段时间后（例如15秒），断路器会进入半开状态，这是一个瞬间态，此时允许一次请求调用该调的逻辑，如果成功，则断路器关闭，应用正常调用；如果调用依然不成功，断路器继续回到打开状态，过段时间再进入半开状态尝试——通过”跳闸“，应用可以保护自己，而且避免浪费资源；而通过半开的设计，可实现应用的“自我修复“。

Hystrix简介
Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。
包裹请求
使用HystrixCommand（或HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用到了设计模式中的“命令模式”。
跳闸机制
当某服务的错误率超过一定阈值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。
资源隔离
Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判定。
监控
Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。
回退机制
当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员自行提供，例如返回一个缺省值。
自我修复
断路器打开一段时间后，会自动进入“半开”状态。断路器打开、关闭、半开的逻辑转换，前面我们已经详细探讨过了，不再赘述。

监控端点与数据
应用整合Hystrix，同时应用包含spring-boot-starter-actuator 依赖，就会存在一个/actuator/hystrix.stream 端点，用来监控Hystrix Command。当被@HystrixCommand 注解了的方法被调用时，就会产生监控信息，并暴露到该端点中。当然，该端点默认是不会暴露的，需使用如下配置将其暴露。

Zuul简介
Zuul是Netflix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用。Zuul的核心是一系列的过滤器，这些过滤器帮助我们完成以下功能：
身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求；
审查与监控：在边缘位置追踪有意义的数据和统计结果，从而为我们带来精确的生产视图；
动态路由：动态地将请求路由到不同的后端集群；
压力测试：逐渐增加指向集群的流量，以了解性能；
负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求；
静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群；
多区域弹性：跨越AWS Region进行请求路由，旨在实现ELB（Elastic Load Balancing）使用的多样化；以及让系统的边缘更贴近系统的使用者。

2.1 问题描述

问题：Eureka-client服务已经下线了，但是Eureka-Server接口返回的信息还是会存在。

2.2 原因与解决

Eureka-Server中的 注册列表（registry）会存留过期的实例。具体原因来自以下几个方面：
1、Eureka_Client应用实例异常挂掉了，但是没有能在挂掉前告知Eureka-Server服务，所以Eureka-Server服务没有下线挂掉的Eureka-Client服务实例信息。解决该问题可以依赖Eureka-Server 的 EvictionTask 去剔除已下线的Eureka-client服务实例信息。

解决方案：

   可以在Eureka-Server服务中调整EvictionTask的调度频率，比如将调度间隔从默认的60秒，调整为5秒，即添加以下配置：

eureka:
server:
eviction-interval-timer-in-ms: 5000

2.Eureka-Client应用实例下线时告知Eureka-Server了，但是 Eureka-Server 的 REST API 有 response cache 缓存，所以需要等待缓存过期后才能更新。

解决方案：

可以根据情况考虑在Eureka-Server服务中关闭readOnlyCacheMap，即修改或添加以下配置：
eureka:
server:
use-read-only-response-cache: false

   或者调整 readWriteCacheMap 的过期时间，即修改或添加以下配置：

eureka:
server:
response-cache-auto-expiration-in-seconds: 60

3.Eureka-Server 服务由于开启了Self Preservation 模式（自我保护模式），导致注册列表（registry）的信息不会因为过期而被剔除，直到退出自我保护模式（Self Preservation）。
解决方案：

   在测试环境中可在Eureka-Server服务中关闭自我保护模式，即修改或添加以下配置：

eureka:
server:
enable-self-preservation: false

或
eureka:
server:
enableSelfPreservation: false

   在生产环境下可以在Eureka-Server服务中把leaseRenewalIntervalInSeconds 和 renewal-percent-threshold 参数调小，从而提高触发自我保护机制的门槛，即修改或添加以下配置：

eureka:
server:
renewal-percent-threshold: 0.49 ## 指定每分钟需要收到的续约次数的阀值，默认值为0.85

   以及

eureka:
instance:
leaseRenewalIntervalInSeconds: 10 # 默认值为30

3、案例二

3.1 问题描述

问题：新服务上线了，Eureka-Client服务不能及时获取到。

3.2 原因与解决

原因1：Eureka Client注册延迟
Eureka Client启动后，不是立即向Eureka Server注册的，而是有一个延迟向服务端注册的时间。通过跟踪源码，可以发现默认的延迟时间为40秒，源码在eureka-client-1.6.2jar的DefaultEurekaClientConfig类中。
解决方案：

    将实例信息变更同步到 Eureka Server的初始延迟时间，从默认的40秒修改到10秒，即修改或添加以下配置：

eureka:
client:
## InstanceInfoReplicator 将实例信息变更同步到 Eureka Server的初始延迟时间 ，默认为40秒
initial-instance-info-replication-interval-seconds: 10

原因2： Eureka Client缓存
Eureka Client保留注册表信息的缓存。该缓存每30秒更新一次。故Eureka Client刷新本地缓存并发现其他新注册的实例可能需要30秒。

解决方案：

   在测试环境下，可以在Eureka-Client服务中适当提高 Eureka-Client端拉取 Server注册信息的频率，比如将默认频率由30秒改为5秒，即修改或添加以下配置：

eureka:
client:
registry-fetch-interval-seconds: 5

4、补充说明

   除以上问题外，本人还遇到了另一个问题。即前端请求后端接口，通过gateway网关调用具体业务服务器时，比如登录时调用 users 服务，经常会在网关层面走熔断机制。于是对配置文件做了如下调整：

具体的业务服务（如 users 服务），添加或修改以下配置 ：
eureka:
client:
## http 连接超时时间，默认为5秒，这里设置为30秒
eureka-server-connect-timeout-seconds: 30

网关服务（ gateway），添加或修改以下配置 ：

eureka 服务注册中心配置

eureka:
client:
## InstanceInfoReplicator 将实例信息变更同步到 Eureka Server的初始延迟时间 ，默认为40秒
initial-instance-info-replication-interval-seconds: 10
server:
## 连接超时时间,节点之间连接超时时长（ms） 默认 200
peer-node-connect-timeout-ms: 5000

设置hystrix超时时间（毫秒） ，默认只有2秒，设置为30秒

hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 30000

dubbo和springCloud整体比较
1、dubbo由于是二进制的传输，占用带宽会更少
2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大
3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决
4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级
5、dubbo的注册中心可以选择zk,redis等，springcloud的注册中心用eureka或者Consul