SpringCloud 简单理解

时间 2019-11-18

标签 springcloud 简单理解繁體版

原文原文链接

0.SpringCloud，微服务架构。包括服务发现（Eureka），断路器（Hystrix），服务网关（Zuul），客户端负载均衡（Ribbon）、服务跟踪(Sleuth)、消息总线(Bus)、消息驱动(Stream)、批量任务(Task)等。html

微服务

1.微服务的核心思想即是服务拆分与解耦,下降复杂性。微服务强调将功能合理拆解,尽量保证每一个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。将各个服务作轻，从而作到灵活、可复用，亦可根据各个服务自身资源需求，单独布署，单独做横向扩展。

服务注册与发现 Eureka

1.@EnableEurekaServer 注解启动一个服务注册中心提供给其余应用进行对话。这个注解放在启动类上方。前端

2. Eureka分为服务注册中心，服务提供者，服务消费者。服务提供者、服务消费者都必须指定注册中心。服务提供者提供服务，而服务消费者能够调用提供者的服务。android

3.服务发现的接口DiscoveryClient类是Spring Cloud对服务治理作的一层抽象。ios

@EanbleDiscoveryClient 注解，加在启动类main的上方，能够将应用注册为Eureka 客户端应用，以获取服务发现的能力。git

4.Spring Cloud Consul项目：能够将基于Spring Boot的微服务应用注册到Consul上，并经过此实现微服务架构中的服务治理。Consul的做用相似于Eureka。
github

5.下面是Eureka的治理机制：spring

服务提供者bootstrap

服务注册：启动的时候会经过发送REST请求的方式将本身注册到Eureka Server上，同时带上了自身服务的一些元数据信息。
服务续约：在注册完服务以后，服务提供者会维护一个心跳机制用来持续告诉Eureka Server: "我还活着 ” 、
服务下线：当服务实例进行正常的关闭操做时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了 ”。

服务消费者小程序

获取服务：当咱们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单
服务调用：服务消费者在获取服务清单后，经过服务名能够得到具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。

Eureka Server(服务注册中心)：后端

失效剔除：默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
自我保护：EurekaServer 在运行期间，会统计心跳失败的比例在15分钟以内是否低于85%(一般因为网络不稳定致使)。 Eureka Server会将当前的实例注册信息保护起来，让这些实例不会过时，尽量保护这些注册信息。

PS:总感受这个“失效剔除”和“自我保护”，有些矛盾。。

6.一样做为注册中心，Eureka和Zookeeper的区别是什么？

分布式事务的CAP理论。C是一致性，A是可用性，P是分区容错性(必备)。

Eureka是AP，注重可用性。

而Zookeeper是CP，注重一致性。

服务消费者

服务消费者 Ribbon

1.LoadBalancerClient接口，是一个负载均衡客户端的接口。

Ribbon注解：@LoadBalanced。

2.RestTemplate对象，经过getForObject()等方法实现对服务提供者接口的调用。

注入方式以下：

    @Autowired
    private RestTemplate restTemplate;

可用方法以下：

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.Ribbon底层原理：负载均衡。轮询。

7.Ribbon：重试机制。

Eureka因为在可用性和一致性的取舍上，选择了可用性。因此服务调用遇到实例故障时，可使用重试机制。Ribbon的重试机制能够经过简单的配置实现。

spring.cloud.loadbalancer.retry.enabled=true

服务消费者 Feign

1. Feign是一套基于Netflix Feign实现的声明式服务调用客户端。Feign能够作为服务消费者。须要经过建立接口并用注解来配置它既可完成对Web服务接口的绑定。

2.@EnableFeignClients注解在Application类上方，能够开启扫描Spring Cloud Feign客户端的功能

3.@FeignClient注解用在Feign接口上方，用来指定这个接口所要调用的服务名称。

2.Feign底层原理：动态代理。

3.Feign接口支持SpringMvc的注解。包括@RequestBody，@RequestParam等

4.重试机制：Feign自带Ribbon，默认实现了请求重试机制。当请求时间超过设置的超时时间时，Feign会发起重试。

5.使用Feign的時候，同時也會自动建立负载均衡的Ribbon，还会自动引入服务保护与容错的Hystrix。

6.Feign最终发送request请求以及接收response响应，都是由Client组件完成的，其中Client的实现类，只要有Client.Default，该类由HttpURLConnnection实现网络请求，另外还支持HttpClient、Okhttp。

断路器 Hystrix

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框架就会自动的为这个函数实现调用的隔离。因此，依赖隔离、服务降级在使用时候都是一体化实现的.

@HystrixCommond，顾名思义，使用了“命令模式”。

Hystrix通常都是和Feign一块儿使用，使用@HystrixCommond的较少。

7.服务隔离： Hystrix使用"舱壁模式"实现线程池的隔离，它会为每个Hystrix命令建立一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟太高的状况，也只是对该依赖服务的调用产生影响，而不会拖慢其余的服务。
经过对依赖服务实现线程池隔离，应用更加健壮，不会由于个别依赖服务出现问题而引发非相关服务的异常。

8.服务降级：当服务器压力剧增的状况下，根据实际业务状况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运做或高效运做。

为了保证重要或基本的服务能正常运行，咱们能够将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。

9.思考：服务降级和服务熔断有什么区别？

熔断是直接返回一个错误响应，降级是延迟使用或暂停使用。

10.Hystix隔离机制：线程池隔离、信号量隔离。

11.能够在熔断的FallBack方法中，将Throwable异常做为参数，并显示熔断的异常信息。

15.Hystrix-dashboard，能够对服务进行监控，展现数据。

服务网关Zuul

1.服务网关：经过服务网关统一贯外系统提供REST API的过程当中，具有服务路由、均衡负载、权限控制等功能。Spring Cloud Netflix中的服务网关为Zuul。

通常微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，全部请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。并且有了网关以后，还有不少好处，好比能够作统一的降级、限流、认证受权、安全，等等。

2.服务路由：经过服务路由的功能，在对外提供服务的时候，只须要经过暴露Zuul中配置的调用地址就可让调用方统一的来访问咱们的服务，而不须要了解具体提供服务的主机信息了。

3.服务过滤：在服务网关中定义过滤器只须要继承ZuulFilter抽象类实现其定义的四个抽象函数就可对请求进行拦截与过滤。

4.网关Zuul自带Ribbon和Hystrix。

示例图：