关于Spring cloud的知识总结了一个思惟导图分享给你们java
Spring cloud 流应用程序启动器是 于 Spring Boot 的 Spring 集成应用程序,提供与外部系统的集成。Spring cloud Task,一个生命周期短暂的微服务框架,用于快速构建执行有限数据处理的应用程序。nginx
使用 Spring Boot 开发分布式微服务时,咱们面临如下问题git
(1)与分布式系统相关的复杂性-这种开销包括网络问题,延迟开销,带宽问题,安全问题。程序员
(2)服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录,在该目录中注册服务,而后可以查找并链接到该目录中的服务。面试
(3)冗余-分布式系统中的冗余问题。算法
(4)负载平衡 --负载平衡改善跨多个计算资源的工做负荷,诸如计算机,计算机集群,网络链路,中央处理单元,或磁盘驱动器的分布。spring
(5)性能-问题 于各类运营开销致使的性能问题。编程
(6)部署复杂性 evops 技能的要求。api
当咱们开始一个项目时,咱们一般在属性文件中进行全部的配置。随着愈来愈多的服务开发和部署,添加和修改这些属性变得更加复杂。有些服务可能会降低,而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka 服务注册和发现能够在这种状况下提供帮助。因为全部服务都在 Eureka 服务器上注册并经过调用 Eureka 服务器完成查找,所以无需处理服务地点的任何更改和处理。安全
在计算中,负载平衡能够改善跨计算机,计算机集群,网络连接,中央处理单元或磁盘驱动器等多种计算资源的工做负载分布。负载平衡旨在优化资源使用,最大化吞吐量,最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会经过冗余来提升可靠性和可用性。负载平衡一般涉及专用软件或硬件,例如多层交换机或域名系统服务器进程。
Hystrix 是一个延迟和容错库,旨在隔离远程系统,服务和第三方库的访问点,当出现故障是不可避免的故障时,中止级联故障并在复杂的分布式系统中实现弹性。一般对于使用微服 构开发的系统,涉及到许多微服务。这些微服务彼此协做。思考如下微服务
假设若是上图中的微服务 9 失败了,那么使用传统方法咱们将传播一个异常。但这仍然会致使整个系统崩溃。 随着微服务数量的增长,这个问题变得更加复杂。微服务的数量能够高达 1000.这是 hystrix 出现的地方 咱们将使 Hystrix 在这种状况下的 Fallback 方法功能。咱们有两个服务 employee-consumer 使用由 employee-consumer 公开的服务。简化图以下所示
如今假设因为 缘由,employee-producer 公开的服务会抛出异常。咱们在这种状况下使用 Hystrix定义了一个回退方法。这种后备方法应该具备与公开服务相同的返回类型。若是暴露服务中出现异常,则回退方法将返回一些值。
因为某些缘由,employee-consumer 公开服务会引起异常。在这种状况下使用Hystrix 咱们定义了一个回退方法。若是在公开服务中发生异常,则回退方法返回一些默认值。
若是 firstPage method() 中的异常继续发生,则 Hystrix 电 ,而且员工使用者将一块儿跳过firtsPage 方法,并直接调用回退方法。 断路器的目的是给第一 方法或第一页方法可能调用的其余方法留出时间,并致使异常恢复。可能发生的状况是,在负载较小的状况下,致使异常的问题有更好的恢复机会 。
Feign 是受到 Retrofit,JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。Feign 的第一个目标是将约束分母的复杂性统一到 http apis,而不考虑其稳定性。在 employee-consumer 的例子中,咱们使用了 emplo e-producer 使用 REST模板公开的 REST 服务。
可是咱们必须编写大量代码才能执行如下步骤
一、使用功能区进行负载平衡。
二、获取服务实例,而后获取基本 URL。
三、利用 REST 模板来使用服务。 前面的代码以下
@Controller
public class ConsumerControllerClient {
@Autowired
private LoadBalancerClient loadBalancer;
public void getEmployee() throws RestClientException, IOException {
ServiceInstance serviceInstance=loadBalancer.choose("employee-
producer");
System.out.println(serviceInstance.getUri());
String baseUrl=serviceInstance.getUri().toString();
baseUrl=baseUrl+"/employee";
RestTemplate restTemplate = new RestTemplate();
ResponseEntity<String> response=null;
try{
response=restTemplate.exchange(baseUrl,
HttpMethod.GET, getHeaders(),String.class);
}
catch (Exception ex)
{
System.out.println(ex);
}
System.out.println(response.getBody());
}
}
复制代码
以前的代码,有像 NullPointer 这样的例外的机会,并非最优 。咱们将看到如何使用 Netflix Fe n使呼叫变得更加轻松和清洁。若是 Netflix Ribbon 依赖关系 径中,那么 Feign 默认也会负载平衡。
考虑如下状况:咱们有多个应用程序使用 Spr ng Cloud Config 读取属性,而S ring Cloud Config 从GIT 读取这些属性。
下面的例子中多个员工生产者模块从 Employee Config Module 获取 Eureka 注册的财产
若是假设 GIT 中的 Eureka 注册属性更改成指向另外一台 Eureka 服务器,会发生什么状况。在这种状况下,咱们将不得不从新启动服务以获取更新的属性。还有另外一种使用执行器端点/刷新的方式。可是咱们将不得不为每一个模块单独调用这个 url。例如,若是 Employee Producer1 部署在端口 8080 上,则调用 http:// localhost:8080 / refresh。一样对于 Employee Producer2 http://localhost:8081 /refresh 等等。这又很麻烦。这就是 Spring Cloud Bus 发挥做用的地方。
Spring Cloud Bus 提供了跨多个实例刷新配置的功能。所以,在上面的 中,若是咱们刷新Employee Producer1,则会自动刷 全部其余必需的模块。若是咱们有 个微服务启动并运行,这特别有用。这是经过将全部微服务连 到单个消息代理来实现的。不管什么时候刷新实例,此事件都会订阅到侦听此代理的全部微服务,而且它们也会刷新。能够经过使用端点/总线/刷新来实现对任何单个实例的刷新
微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分为一组小的服务,每一个服务运行在其独立的本身的进程中,服务之间相互协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通讯机制互相沟通(一般是基于HTTP的RESTful API),每一个服务都围绕着具体的业务进行构建,而且可以被独立的构建在生产环境、类生产环境等。另外,应避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,能够有一个很是轻量级的集中式管理来协调这些服务,可使用不一样的语言来编写服务,也可使用不一样的数据存储。
熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制经过Hystrix实现,Hystrix会监控微服务间调用的情况,当失败的调用到必定阈值,缺省是5秒内调用20次,若是失败,就会启动熔断机制。
服务降级,通常是从总体负荷考虑。就是当某个服务熔断以后,服务器将再也不被调用,此时客户端能够本身准备一个本地的fallback回调,返回一个缺省值。这样作,虽然水平降低,但好歹可用,比直接挂掉强。
Zookeeper保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用)
(1)当向注册中心查询服务列表时,咱们能够容忍注册中心返回的是几分钟之前的信息,但不能容忍直接down掉不可用。也就是说,服务注册功能对高可用性要求比较高,但zk会出现这样一种状况,当master节点由于网络故障与其余节点失去联系时,剩余节点会从新选leader。问题在于,选取leader时间过长,30 ~120s,且选取期间zk集群都不可用,这样就会致使选取期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大几率会发生的事,虽然服务可以恢复,可是漫长的选取时间致使的注册长期不可用是不能容忍的。
(2)Eureka保证 用性,Eureka各个节点是平等的,几个节点挂掉不会影响正常节点的工做,剩余的节点仍然能够提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生链接失败,则会自动切换到其余节点,只要有一台Eureka还在,就能保证注册服务可用,只是查到的信息可能不是最新的。除此以外,Eureka还有自我保护机制,若是在15分钟内超过85%的节点没有正常的心跳,那么Eureka就认为客户端与注册中心发生了网络故障,此时会出现如下几种状况:
①、Eureka不在从注册列表中移除由于长时间没有收到心跳而应该过时的服务。
②、Eureka仍然可以接受新服务的注册和查询请求,可是不会被同步到其余节点上(即保证当前节点仍然可用)
③、当网络稳定时,当前实例新的注册信息会被同步到其余节点。所以,Eureka能够很好的应对因网络故障致使部分节点失去联系的状况,而不会像Zookeeper那样使整个微服务瘫痪
SpringBoot专一于快速方便的开发单个个体微服务。
SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供,配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务SpringBoot能够离开SpringCloud独立使用开发项目, 可是SpringCloud离不开SpringBoot ,属于依赖的关系.
SpringBoot专一于快速、方便的开发单个微服务个体,SpringCloud关注全局的 治理框架
因为某些缘由,employee-consumer公开服务会引起异常。 状况下使用Hystrix咱们定义了回退方法。若是在公开服务中发生异常,则回退方法返回一些默认值 。
若是firstPage method() 中的异常继续发生,则Hystrix电路将中断,而且员工使用者将一块儿跳过firtsPage方法,并直接调用回退方法。 断路器的目的是给第一页方法或第一页方法可能调用的其余方法留出时间,并致使异常恢复。可能发生的状况是,在负载较小的状况下,致使异常的问题有更好的恢复机会 。
首先须要有处理网络链接通信的模块,负责链接创建、管理和消息的传输。其次须要有编解码的模块,由于网络通信都是传输的字节码,须要将咱们使用的对象序列化和反序列化。剩下的就是客户端和服务器端的部分,服务器端暴露要开放的服务接口,客户调用服务接口的一个代理实现,这个代理实现负责收集数据、编码并传输给服务器而后等待结果返回。
优势:
(1)每一个服务直接足够内聚,代码容易理解
(2)开发效率高,一个服务只作一件事,适合小团队开发
(3)松耦合,有功能意义的服务。
(4)能够用不一样语言开发,面向接口编程。
(5)易于第三方集成
(6)微服务只是业务逻辑的代码,不会和HTML,CSS或其余界
(7)能够灵活搭配,链接公共库/链接独立库
缺点:
(1)分布式系统的责任性
(2)多服务运维难度加大。
(3)系统部署依赖,服务间通讯成本,数据一致 ,系统集成测试,性能监控。
(1)服务调用方式 dubbo是RPC spri cloud Rest Api
(2)注册中心,dubbo 是zookeep r springcloud是eureka,也能够是zookeeper
(3)服务网关,dubbo自己没有实现,只能经过其余第三方技术整合,springcloud有Zuul路由网关,做为路由服务器,进行消费者的请求分发,springcloud支持断路器,与git完美集成配置文件支持版本控制,事物总线实现配置文 的更新与服务自动装配等等一系列的微服务架构要素。
(1)RPC主要的缺陷是服务提供方和调用方式之间的依赖太强,须要对每个微服务进行接口的定义,并经过持续继承发布,严格版本控制才不会出现冲突。
(2)REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,只须要一个约定进行规范。
维度(springcloud)
服务开发:springboot spring springmvc
服务配置与管理:Netfix公司的Archaiusm ,阿里的Diamond
服务注册与发现:Eureka,Zookeeper
服务调用:Rest RPC gRpc
服务熔断器:Hystrix
服务负载均衡:Ribbon Nginx
服务接口调用:Fegin
消息队列:Kafka Rabbitmq activemq
服务配置中心管理:SpringCloudConfig
服务路由(API网关)Zuul
事件消息总线:SpringCloud Bus
(1)远程调用,好比feign调用,直接经过远程过程调用来访问别的service。
(2)消息中间件
(1)服务发布时,指定对应的服务名,将服务注册到 注册中心(eureka zookeeper)
(2)注册中心加@EnableEurekaServer,服务用@EnableDiscoveryClient,而后用ribbon或feign进行服务直接的调用发现。
(1)Eureka取CAP的AP,注重可用性,Zookeeper取CAP的CP注重一致性。
(2)Zookeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但选举期间不可用。
(3)eureka的自我保护机制,会致使一个结果就是不会再从注册列表移除因长时间没收到心跳而过时的服务。依然能接受新服务的注册和查询请求,但不会被同步到其余节点。不会服务瘫痪。
(4)Zookeeper有Leader和Follower角色,Eureka各个节点平等。
(5)Zookeeper采用过半数存活原则, reka采用自我保护机制解决分区 。
(6)eureka本质是一个工程,Zookeeper只是一个进程。
当Eureka Server 点在短期内丢失了过多实例的链接时(好比网络故障或频繁启动关闭客户端)节点会进入自我保护模式,保护注册信息,再也不删除注册数据,故障恢复时,自动退出自我保护模式。
ribbon是一个负载均衡客户端,能够很好的控制htt和tcp的一些行为。feign默认集成了ribbon。
(1)feign采用的是基于接口的注解
(2)feign整合了ribbon,具备负载均衡的能力
(3)整合了Hystrix,具备熔断的能力
使用:
(1)添加pom依赖。
(2)启动类添加@EnableFeignClients
(3)定义一个接口@FeignClient(name=“xxx”)指定调用哪一个服务
(1)Ribbon都是调用其余服务的,但方式不一样。
(2)启动类注解不一样,Ribbon是@RibbonClient feign的是@EnableFeignClients
(3)服务指定的位置不一样,Ribbon是在@RibbonClient注解上声明,Feign则是在定义抽象方法的接口中使用@FeignClient声明。
(4)调用方式不一样,Ribbon须要本身构建http请求,模拟http请求而后使用RestTemplate发送给其余服务,步骤至关繁琐。Feign须要将调用的方法定义成抽象方法便可。
spring cloud bus 将分布式的节点用轻量的消息代理链接起来,它能够用于广播配置文件的更改或者服务直接的通信,也可用于监控。
若是修改了配置文件,发送一次请求,全部的客户端便会从新读取配置文件。
使用:
(1)添加依赖
(2)配置rabbimq
当一个服务调用另外一个服务因为网络缘由或自 缘由出现问题,调用者就会等 调用者的响应 当更多的服务请求到这些资源致使更多的请求等待,发生连锁效应(雪崩效应)
断路器有彻底打开状态:一段时间内 到必定的次数没法调用 而且屡次监 没有恢复的迹象 断路器彻底打开 那么下次请求就不会请求到该服务
半开:短期内 有恢复迹象 断路器会将部分请求发给该服务,正常调用时 断路器关闭
关闭:当服务一直处于正常状 能正常调用
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架,取代Zuul网关。网关做为流量的,在微服务系统中有着很是做用,网关常见的功能有路由转发、权限校验、限流控制等做用。
使用了一个RouteLocatorBuilder的bean去建立路由,除了建立路由RouteLocatorBuilder可让你添加各类predicates和filters,predicates断言的意思,顾名思义就是根据具体的请求的规则,由具体的route去处理,filters是各类过滤器,用来对请求作各类判断和修改。
(1)Eureka保证的是可用性和分区容错性,Zookeeper 保证的是一致性和分区容错性 。
(2)Eureka还有一种自我保护机制,若是在15分钟内超过85%的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障。而不会像zookeeper那样使整个注册服务瘫痪。
(1)Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。
(2)Ribbon客户端组件提供一系列完善的配置项如链接超时,重试等。简单的说,就是在配置文件中列出Load Balancer(简称LB)后面全部的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机链接等)去链接这些机器。咱们也很容易使用Ribbon实现自定义的负载均衡算法。
(1)将用户的请求平摊的分配到多个服务上
(2)集中式LB即在服务的消费方和提供方之间使用独立的LB设施(能够是硬件,如F5, 也能够是软件,如nginx), 由该设施负责把访问请求经过某种策略转发至服务的提供方;
(3)进程内LB将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,而后本身再从这些地址中选择出一个合适的服务器。
注意: Ribbon就属于进程内LB,它只是一个类库,集成于消费方进程,消费方 它来获取到服务提供方的地址。
(1)Zuul 包含了对请求的路由和过滤两个最主要的功能:其中 责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础而过滤器功能则负 请求的处理过程进行干预,是实现请求校验、服务聚合等功能的基础、
(2)Zuul和Eureka进行整合,将Zuul自身注册为Eureka服务治理下的应用,同时从Eureka中得到其余微服务的消息,也即之后的访问微服务都是经过Zuul跳转后得到。
注意: Zuul服务最终仍是会注册进Eureka 提供=代理+路由+过滤 三大功能
(1)集中管理配置文件不一样环境不一样配置,动态化的配置更新,分环境部署好比
dev/test/prod/beta/release
(2)运行期间动态调整 置,再也不须要在每一个服务部署的机器上编写配置文件,服务会向配置中心统一拉取配置本身的信息
(3)当配置发生变更时,服务不须要重启便可感知到配置的变化并应用新的配置将配置信息以REST接口的形式暴露
@EnableHystrix:开启熔断
@HystrixCommand(fallbackMethod=”XXX”):声明一个失败回滚处理函数XXX,当被注解的方法执行超时(默认是 0毫秒),就会执行fallback函数,返回错误提示。
Zookeeper保证了CP(C:一致性,P:分区容错性),Eureka保证了AP(A:高可用)
(1)当向注册中心查询服务列表时,咱们能够容忍注册中心返回的是几分钟之前的信息,但不能容忍直接down掉不可用。 就是说,服务注册功能对高可用性要求比较高,但zk会出现这样一种状况,当master节点由于网络故障与其余节点失去联系时,剩余节点会从新选leader。问题在于,选取leader时间过长,30 ~ 120s,且选取期间zk集群都不可用,这样就会致使选取期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大几率会发生的事,虽然服务可以恢复,可是漫长的选取时间致使的注册长期不可用是不能容忍的。
(2)Eureka保证了可用性,Eureka各个节点是平等的,几个节点挂掉不会影响正常节点的工做,剩余的节点仍然能够提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生链接失败,则会自动切换到其余节点,只要有一台Eureka还在,就能保证注册服务可用,只是查到的信息可能不是最新的。除此以外,Eureka还有自我保护机制,若是在15分钟内超过85%的节点没有正常的心跳,那么Eureka就认为 户端与注册中心发生了网络故障,此时会出现如下几种状况:
①、Eureka不 从注册列表中移除由于长时间没有收到心跳而应该过时的服务。
②、Eureka仍然可以接受新服务的注册和查询请求,可是不会被同步到其余节点上(即保证当前节点仍然可用)
③、当网络稳定时,当前实例新的注册信息会被同步到其余节点。
所以,Eureka能够很好的应对因网络故障致使部分节点失去联系的状况,而不会像Zookeeper那样使整个微服务瘫痪。
欢迎关注公众号:程序员追风,领取一线大厂Java面试题总结+各知识点学习思惟导+一份300页pdf文档的Java核心知识点总结!