vvhaleCH的博客

2.对应的bean对象不会立即刷新，需要刷新则需要加上@RefreshScope，原理是从IOC容器中销毁以前的对象，重新注入一个新的bean对象，也可以更改bean对象的生命周期，改成多例的，即加上@Scope("prototype)1.客户端服务启动之后，先去根据服务名称判断本地是否有配置文件的缓存，如果有就使用，如果没有就去发送Http请求拉取配置文件。1.相对于传统的配置文件，使用配置中心可以可以实现不重启服务，更新配置的功能。1.更新nacos上的配置文件之后，本地缓存立马实现了刷新。

这三个特性在任何系统中不可能同时满足，最多同时满足两个，其中P是必须满足的。P：Partition Tolerance-服务对网络分区故障的容错性。C：Consistency-数据一致性；A：Availability-服务可用性。

技术方面对比 springcloud功能远超过dubbo，dubbo只实现了服务治理（注册与发现）。springcloud实现了很多功能，有21个子项目。 dubbo可以使用zookeeper作为注册中心，实现服务的注册与发现；springcloud不仅可以使用eureka作为注册中心，也可以使用zookeeper作为注册中心。 dubbo没有集成其他功能，只能通过第三方去整合；而springcloud集成了很多功能，比如网关、负载均衡、熔断器，而且可以和git完美集成。 性能方面 dub

springboot是为了解决spring配置文件混乱、冗余、难以管理的问题，简化开发流程。 springcloud主要是解决，微服务之间的协调和配置问题，以及注册与发现、负载均衡、服务保护（熔断、网关）、通信等问题。 springcloud依赖springboot来搭建微服务，springboot使用的是约定优于配置的设计理念，也就是能不配置就不配置，springcloud很大一部分是基于springboot来实现的。 springboot不需要依赖springcloud就可以进行开发，spring

Config的出现就是为了解决这两个问题，它支持配置文件放在内存中（本地），也支持将配置文件放在远程GIT仓库中。1.能不能集中管理微服务的配置？2.能不能实时更新微服务的配置？

在微服务框架中，我们各个微服务都不是直接暴露给其他服务来调用的。但假如有一个用户知道了一个服务的ip：端口号：url：访问参数，就能直接访问你，再进一步，如果这个用户开始恶意访问、恶意攻击，就会摧毁咱们的微服务系统。所以需要一个网关对我们的微服务进行保护。网关完成对微服务保护的核心：过滤器。

后台系统中，微服务和微服务之间的调用可以用feign组件完成。 集成了ribbon负载均衡策略（默认是开启，使用轮询机制），hystrix熔断器（默认关闭，需要通过配置文件设置开启）。 被调用的微服务需要提供一个接口，加上@FeignClient("url") 服务调用方需要在引导类上加上服务发现注解@EnableFeignClients。

有的时候，可能是网络问题，可能是一些其他问题，导致代码无法运行，服务挂掉了。熔断器就是为了解决无法正常访问服务时该进行怎样的处理而设计的。核心思想就是，如果一个服务器挂掉，那么把相关的问题局限在这个服务中，不影响其他的服务。

Netflix发布的开源项目。给客户端提供负载均衡，也就是说它是作用在消费端的。默认的均衡策略是轮询策略。

eureka是一个注册中心，提供服务注册与发现。有两个组件：eureka服务端和eureka客户端。

是一些列框架的集合，集成springboot，提供了很多优秀的服务：服务的发现与注册、负载均衡、网关、熔断器（服务保护机制），统一配置中心等。是一个微服务治理框架。