典型回答 Hystrix和Sentinel都是SpringCloud中可以用来做限流、降级的组件。 Hystrix 的关注点在于以 隔离 和 熔断 为主的容错机制，超时或被熔断的调用将会快速失败，并可以提供 fallback 机制。而 Sentinel 的侧重点在于多样化的流量控制、熔断降级、系统负载保护以及实时监控和控制台。 关于Hystrix和Sentinel的对比，在Sentinel的官网上有一篇文章写的挺详细的： https://sentinelguard.io/zh-cn/blog/sentinel-vs-hystrix.html 二者的主要差异如下表：
典型回答 Hystrix熔断器是用来防止级联失败的，并允许系统快速失败和快速恢复。他的原理是通过模拟电路中的断路器（熔断器）来实现的，当某个部分发生故障时，断路器会切断电流，防止故障扩散。 在Hystrix中，这种机制用于管理对依赖服务的调用，特别是在这些服务表现不稳定或响应延迟时。 Hystrix断路器主要有三种状态： **关闭 ** 熔断器在默认情况下下是呈现关闭的状态，而熔断器本身带有计数功能，每当错误发生一次，计数器也就会进行“累加”的动作，到了一定的错误发生次数断路器就会被“开启”，这个时候亦会在内部启用一个计时器，一旦时间到了就会切换成半开启的状态。 **开启 ** 在开启的状态下任何请求都会“直接”被拒绝并且抛出异常讯息。 **半开启 ** 在此状态下断路器会允许部分的请求，如果这些请求都能成功通过，那么就意味着错误已经不存在，则会被切换回关闭状态并重置计数。倘若请求中有“任一”的错误发生，则会恢复到“开启”状态，并且重新计时，给予系统一段休息时间。 Hystrix通过一系列指标来确定是否需要开启断路器，主要指标包括： 请求的数量：在一定时间窗口内，只有请求数量超过了一定阈值，断路器的状态才会评估是否需要开启。这防止了在请求量很低时因一两个请求失败就触发断路器。 错误百分比：计算在过去的一段时间内，失败请求占总请求的百分比。如果这一比例超过设定的阈值，断路器将开启。 在代码中，开发者可以使用Hystrix命令来包装对下游服务的调用。这些命令封装了服务调用的细节，包括超时、失败、回退机制等。当断路器开启时，这些命令会自动执行配置的回退逻辑，而不是执行实际的服务调用。 如果在微服务系统的调用过程中，引入熔断器，那么整个系统将天然具备以下能力： 快速失败：当因为调用远程服务失败次数过多，熔断器开启时，上游服务对于下游服务的调用就会快速失败，这样可以避免上游服务被拖垮。 无缝恢复：因为熔断器可以定期检查下游系统是否恢复，一旦恢复就可以重新回到关闭状态，所有请求便可以正常请求到下游服务。使得系统不需要人为干预。 扩展知识 以下是一个使用Hystrix的Java代码示例，演示如何创建一个Hystrix命令来包装对某个依赖服务的调用，并提供回退逻辑以应对服务调用失败的情况。 假设我们有一个服务方法 getUserById，用于从远程用户服务获取用户详情。我们将使用Hystrix来包装这个服务调用，以便在远程服务失败时提供回退逻辑。 1: 添加依赖 首先，确保在你的项目中添加了Hystrix依赖。如果你使用Maven，可以在pom.xml文件中添加以下依赖： 1 2 3 4 5 6 7 <dependencies> <dependency> <groupId>com.netflix.hystrix</groupId> <artifactId>hystrix-core</artifactId> <version>1.5.18</version> <!-- 使用适当的版本 --> </dependency> </dependencies> 2: 创建Hystrix命令 我们将创建一个继承自 HystrixCommand 的类，用于封装对远程服务的调用。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 import com.netflix.hystrix.HystrixCommand; import com.netflix.hystrix.HystrixCommandGroupKey; import com.netflix.hystrix.HystrixCommandProperties; public class GetUserCommand extends HystrixCommand<String> { private final int userId; public GetUserCommand(int userId) { super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("UserServiceGroup")) .andCommandPropertiesDefaults( HystrixCommandProperties.Setter() .withExecutionTimeoutInMilliseconds(1000) .withCircuitBreakerErrorThresholdPercentage(50) .withCircuitBreakerRequestVolumeThreshold(20) .withCircuitBreakerSleepWindowInMilliseconds(5000) )); this.userId = userId; } @Override protected String run() throws Exception { // 模拟远程服务调用 return remoteCallToGetUser(userId); } @Override protected String getFallback() { return "Hollis 的八股文用户"; } private String remoteCallToGetUser(int userId) { // 这里应该是实际调用远程服务的代码，例如使用HTTP客户端等 } } ****在GetUserCommand构造函数中，我们设置了Hystrix命令的几个关键属性，如执行超时时间、断路器的错误百分比阈值、请求量阈值和“sleep window”。 ****run()方法包含实际调用远程服务的逻辑。 当调用失败或由于断路器开启而阻断调用时，getFallback()方法会被调用，返回一个默认值或其他回退逻辑。 3: 使用Hystrix命令 你可以在应用中如下使用GetUserCommand来获取用户信息： ...
典型回答 当我们在在对比Ribbon（包括loadbalancer）和Nginx的时候，主要对比的是他们的负载均衡方面的区别。 这两者最主要的区别是Nginx是一种服务端负载均衡的解决方案，而Ribbon是一种客户端负载均衡的解决方案。 服务端负载均衡指的是将负载均衡的逻辑集成到服务提供端，通过在服务端对请求进行转发，实现负载均衡。 所以Nginx还是一个反向代理服务器，因为他做的是服务端负载均衡。 客户端负载均衡指的是将负载均衡的逻辑集成到服务消费端的代码中，在客户端直接选择需要调用的服务提供端，并发起请求。这样的好处是可以在客户端直接实现负载均衡、容错等功能，不需要依赖其他组件，使得客户端具有更高的灵活性和可控性。 Nginx是需要单独部署一个Nginx服务的，这样他才能做好服务端负载均衡，而Ribbon是需要在服务消费端的机器代码中引入，和应用部署在一起，这样他才能实现客户端的负载均衡。
典型回答 **Ribbon是一种客户端负载均衡的解决方案，**它通常与Spring Cloud一起使用，以在微服务架构中实现负载均衡。 客户端负载均衡器的实现原理是通过注册中心，如 Nacos，将可用的服务列表拉取到本地（客户端），再通过客户端负载均衡器（设置的负载均衡策略）获取到某个服务器的具体 ip 和端口，然后再通过 Http 框架请求服务并得到结果。 Ribbon通过在客户端中添加拦截器来实现负载均衡。当客户端发出请求时，拦截器会根据一组预定义的规则选择一个服务实例来处理请求。这些规则可以基于多个因素进行选择，包括服务实例的可用性、响应时间、负载等级等。 Ribbon的核心是负载均衡算法，它决定了如何选择服务实例。Ribbon提供了多种负载均衡算法，包括轮询、随机、加权随机、加权轮询、最少连接数等，他们的具体实现是实现了IRule接口，继承自AbstractLoadBalanceRule实现的： 轮询策略：RoundRobinRule 按照一定的顺序依次调用服务实例。比如一共有 3 个服务，依次调用服务 1、服务 2、服务3 权重策略：WeightedResponseTimeRule 每个服务提供者的响应时间分配一个权重，响应时间越长，权重越小。 它的实现原理是，刚开始使用轮询策略并开启一个计时器，每一段时间收集一次所有服务提供者的平均响应时间，然后再给每个服务提供者附上一个权重，权重越高被选中的概率也越大。 随机策略：RandomRule 这种实现很简单，从服务提供者的列表中随机选择一个服务实例。 最小连接数策略：BestAvailableRule 遍历服务提供者列表，选取连接数最小的⼀个服务实例。如果有相同的最小连接数，那么会调用轮询策略进行选取。 重试策略：RetryRule 按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null。 可用敏感性策略：AvailabilityFilteringRule 先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例。 区域敏感策略：ZoneAvoidanceRule 根据服务所在区域（zone）的性能和服务的可用性来选择服务实例，在没有区域的环境下，该策略和轮询策略类似。 Ribbon还提供了一些高级功能，如服务列表的动态刷新、失败重试、请求重试、请求超时控制等。这些功能可以帮助客户端更好地适应动态的服务拓扑，并提高系统的可用性和容错性。 扩展知识 Ribbon结合Nacos使用 但是需要注意的是，Nacos 2021 移除了Ribbon的支持，取而代之的是spring-cloud-loadbalancer 1、POM依赖增加对Nacos和Ribbon的依赖： 1 2 3 4 5 6 7 8 9 10 <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> <version>2.2.5.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-ribbon</artifactId> <version>2.2.10.RELEASE</version> </dependency> 在Spring Boot应用程序中配置Nacos注册中心： ...
典型回答 Spring Cloud和Dubbo都是为了简化分布式系统开发而设计的开源框架，Dubbo 和 Spring Cloud 都侧重在对分布式系统中常见问题模式的抽象（如服务发现、负载均衡、动态配置等） 它们之间有以下几个区别： 底层技术不同：Spring Cloud是基于Spring Boot和Spring Framework构建的，编程模型与通信协议绑定 HTTP，而Dubbo则是基于Java的RPC框架实现的（Dubbo也支持HTTP协议，但是主要还是以Dubbo协议为主）。 主要的用途不同：Spring Cloud是一个完整的微服务框架，它提供了服务注册与发现、负载均衡、熔断器、配置管理等功能。而Dubbo是一个RPC框架，它主要解决分布式服务之间的调用问题，如服务注册与发现、负载均衡、协议转换、服务治理等。 在SpringCloud中，服务注册与发现主要通过Eureka、负载均衡主要通过Ribbon、限流降级这些操作主要通过Hystrix，网关服务主要依赖于Zuul。 社区生态不同：Spring Cloud是由Spring社区维护的，拥有庞大的社区和丰富的生态系统，能够支持多种云平台。而Dubbo则是由阿里巴巴开发和维护的（后来捐给了Apache），虽然拥有较为活跃的社区和强大的阿里巴巴技术支持，但生态系统相对较小。 语言支持不同：Spring Cloud是基于Java语言实现的，同时也支持其他语言的开发，如Kotlin、Groovy、Scala等。而Dubbo则是一个纯Java实现的RPC框架，只支持Java语言开发（Dubbo-go框架支持go语言）。 扩展知识 如何选择 如果你需要将应用部署到云平台上，Spring Cloud提供了更多的云原生支持，包括对Kubernetes和Istio的支持。 如果你的项目需要强大的服务治理能力，例如多协议支持、多注册中心支持等，那么选择Dubbo可能更适合。Dubbo提供了强大的服务治理能力，可以满足各种不同的需求。
典型回答 Zuul、Spring Cloud Gateway和Nginx都是常用的网关技术，但它们在实现和功能方面有一些区别。Zuul和Gateway是同一类，而Nginx是另外一类。 下面是他们的区别的对照（原创，如有雷同，绝对抄袭 差异点 Nginx Spring Cloud Gateway/Zuul等 定位 高性能的 Web 服务器、反向代理、负载均衡器。 微服务架构中的 API 网关。 主要用途 负载均衡，反向代理 负载均衡、统一鉴权、统一限流 微服务集成 并非专门为微服务设计，但可以作为反向代理和负载均衡器在微服务架构中使用。 专为微服务架构设计，能与 Spring Cloud 生态系统紧密集成。 安全性 支持 SSL/TLS 终端、基本的限流和访问控制。 支持 OAuth2、JWT、身份验证、授权控制、API 限流等高级安全功能。 主要使用场景 负载均衡、静态资源托管、反向代理 动态路由、请求转换、身份认证和授权等。 负载均衡实现方式 服务端负载均衡。支持多种负载均衡算法（轮询、加权轮询、IP Hash 等）。 需要与 Spring Cloud LoadBalancer 集成，实现的是客户端负载均衡。 生态要求 无要求 Java微服务生态 主要定位 不管是Zuul还是Gateway，都是Spring Cloud生态的一部分，他的主要功能是API 网关。支持请求路由、负载均衡、权限认证、限流、请求过滤等功能。 ✅什么是Zuul网关，有什么用？ ✅为什么需要SpringCloud Gateway，他起到了什么作用？ Nginx 是一个高性能的 Web 服务器和反向代理服务器，广泛用于负载均衡、静态文件托管、请求转发等任务。其实Nginx也能实现鉴权、限流以及流量过滤的功能的。 但是这里面比较关键的就是Nginx支持反向代理和静态资源托管。 ✅什么是正向代理和反向代理？ 所谓反向代理，其实是”代理服务器”代理了”目标服务器”，去和”客户端”进行交互。就是说在调用者不知道自己调用的具体是哪台服务器。这个功能是Nginx独有的。而Gateway等是不具备这个功能的，他们是明确的知道自己要调用的服务器的具体的ip的。 静态资源托管，其实就是将网站或应用中不需要经过动态计算或生成的文件存储并提供给用户访问。比如网站上面的CSS、JS、图片、音视频等资源，都是静态资源，这些可以托管给Nginx，这样就不需要和后端交互了，nginx直接就能返回了，可以大大减少后端压力，也能提升性能。 负载均衡 其实，直接拿Gateway和Nginx对比并不一定不合适，因为Gateway中的负载均衡的功能是靠LoadBalancer实现的。而loadbalancer和nginx的主要区别是，虽然都是负载均衡，但是loadbalancer是客户端负载均衡，而nginx是服务端负载均衡。 服务端负载均衡指的是将负载均衡的逻辑集成到服务提供端，通过在服务端对请求进行转发，实现负载均衡。 因为Nginx是服务端负载均衡，所以他能实现反向代理的能力，调用者只知道自己调用的时候Nginx（反向代理服务器），而不知道具体调用的是哪个服务器。 客户端负载均衡指的是将负载均衡的逻辑集成到服务消费端的代码中，在客户端直接选择需要调用的服务提供端，并发起请求。这样的好处是可以在客户端直接实现负载均衡、容错等功能，不需要依赖其他组件，使得客户端具有更高的灵活性和可控性。 ...
典型回答 在如今的SpringCloud生态中，SpringCloud Gateway是一个至关重要的组件。Spring Cloud Gateway 是一个在 Spring 生态系统中建立的 API 网关，它为微服务架构中的服务提供了一个简单有效的方式来路由请求、转发和过滤等功能。 网关的作用就是提供统一接入，意味着所有的流量都需要先经过网关，然后再由网关转发出去。所以，一般来说我们用Gateway构建的网关应用中不太有业务逻辑，主要的功能就是做流量的转发。 有了网关之后，我们就可以基于网关做很多事情，如： 路由转发：Spring Cloud Gateway 允许我们定义路由规则，将进入的请求根据不同的路径或条件转发到不同的下游服务。这对于微服务架构中服务的管理和维护非常重要。 基于这个原理，我们就可以根据用户的不同请求，把用户路由到对应的服务中，比如用户要访问订单服务，则把他的请求直接路由给订单服务的集群，用户要访问商品服务，则把他的请求直接路由给商品服务的集群。 1 2 3 4 5 6 7 8 9 10 11 12 spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/order/** - id: item-service uri: lb://item-service predicates: - Path=/item/** 负载均衡：因为网关可以做路由转发，所以借助他也能实现非常方便的负载均衡。一般都是集成LoadBalancer实现。 ...
典型回答 Spring Cloud是基于Spring Boot的分布式系统开发工具，它提供了一系列开箱即用的、针对分布式系统开发的特性和组件，用于帮助开发人员快速构建和管理云原生应用程序。 Spring Cloud的主要目标是解决分布式系统中的常见问题，例如服务发现、负载均衡、配置管理、断路器、消息总线等。 所以，单体应用使用Spring，需要快速构建，简化开发使用SpringBoot，构建分布式、微服务应用，使用SpringCloud。 下图是我画的一张SpringCloud中核心组件起到的作用以及所处的位置： （图片可放大查看） 下面是Spring Cloud常用的一些组件： Eureka：服务发现和注册中心，可以帮助服务消费者自动发现和调用服务提供者。 Ribbon：负载均衡组件，可以帮助客户端在多个服务提供者之间进行负载均衡。 ✅Ribbon是怎么做负载均衡的？ OpenFeign：声明式HTTP客户端，可以帮助开发人员更容易地编写HTTP调用代码。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 [✅OpenFeign 不支持了怎么办？](https://www.yuque.com/hollis666/ec96i7/itmcpq5517975ttq) 4. Hystrix：断路器组件，可以帮助应用程序处理服务故障和延迟问题。 [✅Hystrix和Sentinel的区别是什么？](https://www.yuque.com/hollis666/ec96i7/gvgtod53vvivtk0t) 5. ~~Zuul：API网关，可以帮助应用程序处理API请求的路由、负载均衡、安全和监控等问题。~~ [✅Zuul、Gateway和Nginx有什么区别？](https://www.yuque.com/hollis666/ec96i7/uliggwanbo7t3hxg) 6. Config：分布式配置管理组件，可以帮助应用程序从远程配置源获取配置信息。 7. Bus：消息总线组件，可以帮助应用程序实现分布式事件传递和消息广播。 8. Sleuth：Sleuth是Spring Cloud生态系统中的一个分布式追踪解决方案，可以帮助开发人员实现对分布式系统中请求链路的追踪和监控。 9. Gateway：spring Cloud Gateway是Spring Cloud推出的第二代网关框架，取代Zuul网关。提供了路由转发、权限校验、限流控制等作用。 [✅为什么需要SpringCloud Gateway，他起到了什么作用？](https://www.yuque.com/hollis666/ec96i7/ow7cnpaa2du8zvv5) 10. Security：用于简化 OAuth2 认证和资源保护。 但是，有的时候我们并不一定非要全部都用SpringCloud的这些组件，有的时候我们也可以选择其他的开源组件替代。比如经常用Dubbo/gRPC来代替Feign进行服务间调用。经常使用Nacos代替Config+Eureka来实现服务发现/注册及配置中心的功能。 如下图是我[项目课中的技术栈](https://www.yuque.com/hollis666/ec96i7/dgolk0cckpb94sia)，目前比较主流的SpringCloud的架构：  # 扩展知识 ## <font style="color:rgb(52, 53, 65);">Spring Cloud Alibaba</font> Spring Cloud Alibaba则是由Alibaba推出的分布式开发框架，它主要针对于微服务和云原生应用的开发和部署。Spring Cloud Alibaba提供了一系列的组件和解决方案，例如服务注册、配置管理、消息驱动等。Spring Cloud Alibaba的组件通常基于阿里巴巴自研的组件，例如Nacos、Sentinel、RocketMQ等。 依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。 目前 Spring Cloud Alibaba 提供了如下功能: 1. 服务限流降级：支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Dubbo 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。 2. 服务注册与发现：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持。 3. 分布式配置管理：支持分布式系统中的外部化配置，配置更改时自动刷新。 4. Rpc服务：扩展 Spring Cloud 客户端 RestTemplate 和 OpenFeign，支持调用 Dubbo RPC 服务 5. 消息驱动能力：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。 6. 分布式事务：使用 @GlobalTransactional 注解， 高效并且对业务零侵入地解决分布式事务问题。 7. 阿里云对象存储：阿里云提供的海量、安全、低成本、高可靠的云存储服务。支持在任何应用、任何时间、任何地点存储和访问任意类型的数据。 8. 分布式任务调度：提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。同时提供分布式的任务执行模型，如网格任务。网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。 9. 阿里云短信服务：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。 ## <font style="color:rgb(52, 53, 65);">Spring Cloud Tencent</font> Spring Cloud Tencent 是腾讯开源的一站式微服务解决方案。 Spring Cloud Tencent 实现了Spring Cloud 标准微服务 SPI，开发者可以基于 Spring Cloud Tencent 快速开发 Spring Cloud 云原生分布式应用。 Spring Cloud Tencent提供的能力包括但不限于： 
典型回答 Zuul是一个开源的网关服务，主要用于将客户端请求路由到相应的微服务实例。它是Netflix公司开发的，现在成为了Spring Cloud生态系统中的一部分。 网关就相当于是一个前置的入口，所有的请求都要经过他，然后通过它进行服务转发和路由。 网关能带来几个好处，首先比较容易想到的就是他承担了统一的入口和出口的角色，所有的请求都需要经过他，那么他就可以很方便的管理这些服务。 其次，因为所有请求都要经过他， 所以他可以做负载均衡以及动态路由。根据不同的负载均衡算法，或者根据请求的参数内容，进行决策选择一个合适的后端服务进行调用。 其他他还有把很多公共的服务集成进来，比如做统一的鉴权、统一的异常处理等，还可以做各种粒度的限流、降级和熔断的操作。 扩展知识 示例 以一个简单的示例为例，假设我们有两个服务，一个是 User Service，一个是 Order Service，它们的访问地址分别是： http://localhost:8081/user http://localhost:8082/order 我们可以在注册中心注册一个 Zuul 服务，然后在 Zuul 服务中配置路由规则，将不同的请求路由给不同的服务： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # application.yml spring: application: name: api-gateway zuul: routes: user-service: path: /user/** url: http://localhost:8081/user order-service: path: /order/** url: http://localhost:8082/order 这样，我们就可以通过访问 http://localhost:8080/user/xxx 来访问 User Service，通过访问 http://localhost:8080/order/xxx 来访问 Order Service 。 ...
典型回答 Eureka 的缓存机制设计主要目的是提高服务发现的效率和减少服务注册中心的压力，尤其是在面对大规模的服务注册和发现请求时。这种多层缓存设计帮助 Eureka 提供快速的响应能力。 也正是因为有了比较复杂的缓存机制，所以Eureka提供的是AP能力，即可用性有保证，但是一致性是没办法保证的。 Eureka共提供了三层缓存，分别是registry、readWriteCacheMap、readOnlyCacheMap； （此图来源于网络，出处找不到了，但是画的很好，应用过来了） registry：服务注册表是 Eureka 中最基础的数据结构，存储了所有服务实例的注册信息。这些信息包括服务的名称、IP 地址、端口、健康状态等。服务注册表是所有读写操作的基础数据源。 readWriteCacheMap ：readWriteCacheMap 是一个缓存层，主要用于缓存服务实例信息的最新状态，允许快速读取和写入。这个缓存相当于 Registry 的一个近实时的反映，提供了更快的访问速度，并减少了对主 Registry 的直接访问压力。 readOnlyCacheMap：readOnlyCacheMap 是对服务注册信息的一个只读视图，主要用于处理对服务实例信息的外部请求。这个缓存层定期从 readWriteCacheMap 更新数据，保证了信息的一定程度的新鲜度和准确性，同时因为是只读操作，可以提供非常高效的访问速度。 目的 实现方式 更新机制 Registry 提供一个准确的、权威的数据源 ConcurrentHashMap 当服务实例注册、续约或者注销时，Registry 会立即更新以反映最新的服务状态。 readWriteCacheMap 提供了一个快速的读写能力，减少了对 Registry 的直接压力 Guava Cache（LoadingCache） 当 Registry 中的数据发生变化时，readWriteCacheMap 会同步更新。缓存时间180秒； readOnlyCacheMap 提供了快速且频繁的读取操作，特别适用于大量的客户端查询 ConcurrentHashMap 默认30秒定时从 readWriteCacheMap 同步快照数据 当服务实例注册、续约或者注销时，Registry 会立即更新以反映最新的服务状态。并且默认每隔90秒把没有续约服务从注册表中剔除。当注册表发生变化时，会立刻同步到readWriteCacheMap中。同时会有一个定时任务，每隔30秒钟从readWriteCacheMap获取最新的快照到readOnlyCacheMap中。