SpringCloud，微服务架构。包括 服务发现（Eureka），断路器（Hystrix），服务网关（Zuul），客户端负载均衡（Ribbon）、服务跟踪(Sleuth)、消息总线(Bus)、消息驱动(Stream)、批量任务(Task)等。
微服务：
1.微服务的核心思想便是服务拆分与解耦,降低复杂性。微服务强调将功能合理拆解,尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。 将各个服务做轻，从而做到灵活、可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。
服务注册与发现：
1.@EnableEurekaServer 注解启动一个服务注册中心提供给其他应用进行对话。这个注解放在启动类上方。
2. Eureka分为服务注册中心，服务提供者 ，服务消费者。服务提供者 、服务消费者都必须指定注册中心。服务提供者提供服务，而服务消费者可以调用提供者的服务。
3.服务发现的接口DiscoveryClient类是Spring Cloud对服务治理做的一层抽象。
@EanbleDiscoveryClient 注解，加在启动类main的上方，可以将应用注册为Eureka 客户端应用，以获取服务发现的能力。
4.Spring Cloud Consul项目： 可以将基于Spring Boot的微服务应用注册到Consul上，并通过此实现微服务架构中的服务治理。Consul的作用类似于Eureka。
5.下面是Eureka的治理机制：
服务提供者：
- 服务注册：启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。
- 服务续约：在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” 、
- 服务下线：当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了 ”。
服务消费者
- 获取服务：当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单
- 服务调用：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。
Eureka Server(服务注册中心)：
- 失效剔除：默认每隔一段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
- 自我保护：EurekaServer 在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。 Eureka Server会将当前的实例注册信息保护起来， 让这些实例不会过期，尽可能保护这些注册信息。
服务消费者：
1.LoadBalancerClient接口 ，是一个负载均衡客户端的接口。
2.RestTemplate对象，通过getForObject()等方法实现对服务提供者接口的调用。
getForObject(URI url, Class<T> responseType)3.将eureka-server(服务注册中心)、eureka-client(服务提供者)、eureka-consumer(服务消费者)都启动起来，然后访问 eureka-consumer的Controller层方法对应的请求，可以观察eureka-consumer服务是如何消费eureka-client服务的Controller层方法接口的。
4.使用Spring Cloud Ribbon可以作为服务消费者，实现服务的调用以及客户端均衡负载。
5.在Ribbon中可以采用服务名的方式进行请求，因为Ribbon有一个拦截器，它能够在这里进行实际调用的时候，自动的去选取服务实例，并将实际要请求的IP地址和端口替换这里的服务名，从而完成服务接口的调用。
服务名是application文件中的spring.application.name 属性。
6. Feign是一套基于Netflix Feign实现的声明式服务调用客户端。Feign可以做为服务消费者。需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。
@EnableFeignClients注解开启扫描Spring Cloud Feign客户端的功能
@FeignClient注解用来指定这个接口所要调用的服务名称。
7.Feign底层原理 ：动态代理。
8.Ribbon底层原理：负载均衡。轮询。
分布式配置中心：
1.分布式配置中心，集中管理配置，"一次配置，随处可用"。
2.在SpringCloudConfig中，程序中bootstrap.yml中的配置优先级高于application.yml的配置。。
3.SpringCloudConfig主要由基于Git仓库的配置中心服务端 、 使用配置中心的客户端组成。
断路器：
1.熔断机制： 在分布式架构中，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
2.Spring Cloud中使用了Hystrix 来实现断路器的功能。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能。Hystrix具有融断机制。
Hystrix可以进行服务降级、服务隔离、服务熔断。
3.在Ribbon中需要引入Hystrix依赖。否则服务不可用时，会返回404。
而Feign中已经依赖了Hystrix，不需要再引入，会直接返回内部错误(500) 。
4.@SpringCloudApplication注解，它整合了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker。
5.当服务提供者不可用时，断路器Hystrix会返回错误响应。
6.使用了@HystrixCommand来将某个函数包装成了Hystrix命令，这里除了定义服务降级之外，Hystrix框架就会自动的为这个函数实现调用的隔离。所以，依赖隔离、服务降级在使用时候都是一体化实现的.
7.服务隔离： Hystrix使用"舱壁模式"实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。
通过对依赖服务实现线程池隔离，应用更加健壮，不会因为个别依赖服务出现问题而引起非相关服务的异常。
8.hystrix-dashboard，可以对服务进行监控，展示数据。
9.Hystix底层原理 ：线程池。
服务网关：
1.服务网关：通过服务网关统一向外系统提供REST API的过程中，具备服务路由、均衡负载、权限控制等功能。Spring Cloud Netflix中的服务网关为Zuul。
一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。而且有了网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。
2.服务路由：通过服务路由的功能，在对外提供服务的时候，只需要通过暴露Zuul中配置的调用地址就可以让调用方统一的来访问我们的服务，而不需要了解具体提供服务的主机信息了。
3.服务过滤：在服务网关中定义过滤器只需要继承ZuulFilter抽象类实现其定义的四个抽象函数就可对请求进行拦截与过滤。
高可用服务集群：
1.配置高可用的Eureka服务集群，多个服务注册中心互相注册，如果有某个服务注册节点失效，那么还有其他节点可用。
消息驱动：
1.SpringCloudStream。
SpringCloud，微服务架构。包括 服务发现（Eureka），断路器（Hystrix），服务网关（Zuul），客户端负载均衡（Ribbon）、服务跟踪(Sleuth)、消息总线(Bus)、消息驱动(Stream)、批量任务(Task)等。
微服务：
1.微服务的核心思想便是服务拆分与解耦,降低复杂性。微服务强调将功能合理拆解,尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。 将各个服务做轻，从而做到灵活、可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。
服务注册与发现：
1.@EnableEurekaServer 注解启动一个服务注册中心提供给其他应用进行对话。这个注解放在启动类上方。
2. Eureka分为服务注册中心，服务提供者 ，服务消费者。服务提供者 、服务消费者都必须指定注册中心。服务提供者提供服务，而服务消费者可以调用提供者的服务。
3.服务发现的接口DiscoveryClient类是Spring Cloud对服务治理做的一层抽象。
@EanbleDiscoveryClient 注解，加在启动类main的上方，可以将应用注册为Eureka 客户端应用，以获取服务发现的能力。
4.Spring Cloud Consul项目： 可以将基于Spring Boot的微服务应用注册到Consul上，并通过此实现微服务架构中的服务治理。Consul的作用类似于Eureka。
5.下面是Eureka的治理机制：
服务提供者：
- 服务注册：启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。
- 服务续约：在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” 、
- 服务下线：当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了 ”。
服务消费者
- 获取服务：当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单
- 服务调用：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。
Eureka Server(服务注册中心)：
- 失效剔除：默认每隔一段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
- 自我保护：EurekaServer 在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。 Eureka Server会将当前的实例注册信息保护起来， 让这些实例不会过期，尽可能保护这些注册信息。
服务消费者：
1.LoadBalancerClient接口 ，是一个负载均衡客户端的接口。
2.RestTemplate对象，通过getForObject()等方法实现对服务提供者接口的调用。
getForObject(URI url, Class<T> responseType)3.将eureka-server(服务注册中心)、eureka-client(服务提供者)、eureka-consumer(服务消费者)都启动起来，然后访问 eureka-consumer的Controller层方法对应的请求，可以观察eureka-consumer服务是如何消费eureka-client服务的Controller层方法接口的。
4.使用Spring Cloud Ribbon可以作为服务消费者，实现服务的调用以及客户端均衡负载。
5.在Ribbon中可以采用服务名的方式进行请求，因为Ribbon有一个拦截器，它能够在这里进行实际调用的时候，自动的去选取服务实例，并将实际要请求的IP地址和端口替换这里的服务名，从而完成服务接口的调用。
服务名是application文件中的spring.application.name 属性。
6. Feign是一套基于Netflix Feign实现的声明式服务调用客户端。Feign可以做为服务消费者。需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。
@EnableFeignClients注解开启扫描Spring Cloud Feign客户端的功能
@FeignClient注解用来指定这个接口所要调用的服务名称。
7.Feign底层原理 ：动态代理。
8.Ribbon底层原理：负载均衡。轮询。
分布式配置中心：
1.分布式配置中心，集中管理配置，"一次配置，随处可用"。
2.在SpringCloudConfig中，程序中bootstrap.yml中的配置优先级高于application.yml的配置。。
3.SpringCloudConfig主要由基于Git仓库的配置中心服务端 、 使用配置中心的客户端组成。
断路器：
1.熔断机制： 在分布式架构中，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
2.Spring Cloud中使用了Hystrix 来实现断路器的功能。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能。Hystrix具有融断机制。
Hystrix可以进行服务降级、服务隔离、服务熔断。
3.在Ribbon中需要引入Hystrix依赖。否则服务不可用时，会返回404。
而Feign中已经依赖了Hystrix，不需要再引入，会直接返回内部错误(500) 。
4.@SpringCloudApplication注解，它整合了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker。
5.当服务提供者不可用时，断路器Hystrix会返回错误响应。
6.使用了@HystrixCommand来将某个函数包装成了Hystrix命令，这里除了定义服务降级之外，Hystrix框架就会自动的为这个函数实现调用的隔离。所以，依赖隔离、服务降级在使用时候都是一体化实现的.
7.服务隔离： Hystrix使用"舱壁模式"实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。
通过对依赖服务实现线程池隔离，应用更加健壮，不会因为个别依赖服务出现问题而引起非相关服务的异常。
8.hystrix-dashboard，可以对服务进行监控，展示数据。
9.Hystix底层原理 ：线程池。
服务网关：
1.服务网关：通过服务网关统一向外系统提供REST API的过程中，具备服务路由、均衡负载、权限控制等功能。Spring Cloud Netflix中的服务网关为Zuul。
一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。而且有了网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。
2.服务路由：通过服务路由的功能，在对外提供服务的时候，只需要通过暴露Zuul中配置的调用地址就可以让调用方统一的来访问我们的服务，而不需要了解具体提供服务的主机信息了。
3.服务过滤：在服务网关中定义过滤器只需要继承ZuulFilter抽象类实现其定义的四个抽象函数就可对请求进行拦截与过滤。
高可用服务集群：
1.配置高可用的Eureka服务集群，多个服务注册中心互相注册，如果有某个服务注册节点失效，那么还有其他节点可用。
消息驱动：
1.SpringCloudStream。