spring|Spring Cloud 组件介绍客户端|机器

文章图片

文章图片

微服务：拆分、单一、独立、组件化。将一个复杂的庞大的项目拆分成一个一个的小项目独立的运行，通过接口的方式组装成一个大项目。
springcloud是基于springboot的一套实现微服务的框架。
提供了微服务开发所需要的配置管理，服务管理，断路器，智能路由，微代理，控制总线，全局锁，策略竞选，分布式会话和集群状态管理等组件。

SpringCloud的特点
（1）约定优于配置
（2）适用于各种环境
（3）隐藏了组件的复杂性，并提供声明式、无xml的配置方式
（4）开箱即用，快速启动
（5）轻量级的组件。 SpringCloud整合的组件大多比较轻量，例如Eureka、Zuul等等，都是各自领域轻量级的实现
（6）组件丰富，功能齐全。 SpringCloud为微服务架构提供了非常完整的支持。例如，配置管理、服务发现、断路器、微服务网关等
（7）选型中立、丰富。例如， SpringCloud支持使用Eureka、Zookeeper或Consul实现服务发现
（8）灵活。 SpringCloud的组成部分是解耦的，开发人员可按需灵活挑选技术选型
Spring Cloud核心组件
Eureka：服务发现，构成Eureka体系的包括：服务注册中心、服务提供者、服务消费者。

在应用启动时， Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。
Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。
【spring|Spring Cloud 组件介绍】Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号
Feign：服务调用请求。 Spring Cloud Feign 是一个声明web服务客户端，这使得编写Web服务客户端更容易，使用Feign 创建一个接口并对它进行注解，它具有可插拔的注解支持包括Feign注解与JAX-RS注解， Feign还支持可插拔的编码器与解码器， Spring Cloud 增加了对 Spring MVC的注解， Spring Web 默认使用了HttpMessageConverters Spring Cloud 集成 Ribbon 和 Eureka 提供的负载均衡的HTTP客户端 Feign 。
Feign的一个关键机制就是使用了动态代理。

首先，如果你对某个接口定义了@FeignClient注解， Feign就会针对这个接口创建一个动态代理
接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
最后针对这个地址，发起请求、解析响应

Ribbon
服务之间负载均衡。 Eureka只是维护了服务生产者、注册中心、服务消费者三者之间的关系，真正的服务消费者调用服务生产者提供的数据是通过Spring Cloud Ribbon来实现的。
Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。
Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法。提供了多种负载均衡策略，包括BestAvailableRule、AvailabilityFilteringRule、WeightedResponseTimeRule、RetryRule、RoundRobinRule、RandomRule、ZoneAvoidanceRule等。

首先Ribbon会从 Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。
然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器
Feign就会针对这台机器，构造并发起请求。

Hystrix熔断器。
防止对某一故障服务持续进行访问。 Hystrix的含义是：断路器，断路器本身是一种开关装置，用于我们家庭的电路保护，防止电流的过载，当线路中有电器发生短路的时候，断路器能够及时切换故障的电器，防止发生过载、发热甚至起火等严重后果。
为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入， Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
Zuul服务网关，服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。 Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
网关有很多好处，比如可以做统一的降级、限流、认证授权、安全等等。
Spring Cloud Config实现了应用多环境的外部化配置以及版本管理；Config Server用于配置属性的存储，存储的位置可以为Git仓库、SVN仓库、本地文件等， Config Client用于服务属性的读取。 Spring Cloud Bus可以实现动态的配置更新。

spring cloud config远程配置服务。远程配置是每个都必不可少的中间件，远程配置的特点一般需要：多节点主备、配置化、动态修改、配置本地化缓存、动态修改的实时推送等。 config允许配置文件放在git上或者svn上，和spring boot的集成非常容易，但是缺点就是修改了git上的配置以后，只能一个一个的请求每个service的接口，让他们去更新配置，没有修改配置的推送消息。而且，如果要根据配置文件的修改，做一些重新初始化操作的话(如线程池的容量变化等) ，会需要一些work around的方法，所以建议如果有其他方案，不建议选择spring cloud config 。
spring cloud bus事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化。经常与Spring Cloud Config联合使用。 spring cloud config本身不能向注册过来的服务提供实时更新的推送。比如我们配置放在了git上，那么当修改github上配置内容的时候，最多可以配置webhook到一台config-server上，但是config-server自己不会将配置更新实时推送到各个服务上。 bus的作用就是将大家链接在一条总线上，这条线上的所有server共享状态，当webhook到bus上的某一台server的时候，其他server也会收到相同的hook状态。但是bus的使用需要依赖于MQ ， bus直接继承了RabbitMq & kafka ，只需要在spring中直接配置地址即可，但是对于其他类型的MQ ，就需要一些手动配置。最大的问题还是，如果仅仅因为spring cloud bus而让自己的系统引入MQ ，显然会有些得不偿失。