什么是Spring Cloud？

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包

整体架构图

1103179-20201026101237734-1748584990.png

Springcloud的五大组件

1、服务发现Netflix Eureka

简介：Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。

由两个组件组成：Eureka服务端和Eureka客户端。

Eureka服务端用作服务注册中心。支持集群部署。

Eureka客户端是一个java客户端，用来处理服务注册与发现。

在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

服务注册和发现是什么意思？Spring Cloud 如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。
Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

2、客服端负载均衡——Netflix Ribbon：

作用：Ribbon，主要提供客户侧的软件负载均衡算法。

简介：Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用

负载平衡的意义什么？

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程

、Feign介绍

Feign是一个http请求调用的轻量级框架，可以以Java接口注解的方式调用Http请求。Spring Cloud引入 Feign并且集成了Ribbon实现客户端负载均衡调用。

Feign解决了什么问题？

封装了Http调用流程，更适合面向接口化的变成习惯

3、 断路器——Netflix Hystrix：

作用：断路器，保护系统，控制故障范围。

简介：为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

什么是 Hystrix？它如何实现容错？

Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。
通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

4、服务网关——Netflix Zuul

简介：类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。

在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

5、分布式配置——Spring Cloud Config：

SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。

这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。

什么是Spring Cloud Config?

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中

微服务项目间的调用原理：

Spring Cloud核心组件：Eureka

就拿订单服务来说：
订单服务想要调用库存服务、仓储服务，或者是积分服务，怎么调用？

  • 订单服务压根儿就不知道人家库存服务在哪台机器上啊！他就算想要发起一个请求，都不知道发送给谁，有心无力！
  • 这时候，就轮到Spring Cloud Eureka出场了。Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。
  • 库存服务、仓储服务、积分服务中都有一个Eureka Client组件，这个组件专门负责将这个服务的信息注册到Eureka Server中。说白了，就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口。而Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。

订单服务里也有一个Eureka Client组件，这个Eureka Client组件会找Eureka Server问一下：库存服务在哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢？然后就可以把这些相关信息从Eureka Server的注册表中拉取到自己本地缓存起来。
这时如果订单服务想要调用库存服务，不就可以找自己本地的Eureka Client问一下库存服务在哪台机器？监听哪个端口吗？收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。
总结一下：

  • Eureka Client：负责将这个服务的信息注册到Eureka Server中

  • Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号。

    Spring Cloud核心组件：Feign

    现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，同时也监听着哪些端口号了。但是新问题又来了：难道订单服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？

  • 首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理

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

Spring Cloud核心组件：Ribbon

Feign怎么知道该请求哪台机器呢？

  • Ribbon就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上
  • Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法。这是啥？简单来说，就是如果订单服务对库存服务发起10次请求，那就先让你请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器，接着再来—个循环，第1台机器、第2台机器。。。以此类推。

此外，Ribbon是和Feign以及Eureka紧密协作，完成工作：

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

Duboo

Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架
最早是阿里巴巴开源的RPC框架，后来贡献给了Apache

Apache Dubbo |ˈdʌbəʊ| 提供了六大核心能力：

1.面向接口代理的高性能RPC调用
2.智能容错和负载均衡
3.服务自动注册和发现
4.高度可扩展能力
5.运行期流量调度
6.可视化的服务治理与运维。

RPC:Remote Procedure Call 远程过程调用
SOA: Service-Oriented Architecture 面向服务的架构
把一个项目根据功能或者业务设计成一个个独立的服务。

核心解决方案：

1.Dubbo-分布式
2.Spirng Cloud-微服务
3.Istio-服务网格化
大型企业标准微服务：微服务项目+自动化测试+CI&CD

Dubbo核心：

调用关系说明：

  1. 服务容器负责启动，加载，运行服务提供者。
  2. 服务提供者在启动时，向注册中心注册自己提供的服务。
  3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
  4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
  5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
  6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

Dubbo 架构具有以下几个特点：

分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。

连通性

  • 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
  • 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
  • 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销
  • 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者，同时汇报调用时间到监控中心，此时间包含网络开销
  • 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
  • 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
  • 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
  • 注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

    健壮性

  • 监控中心宕掉不影响使用，只是丢失部分采样数据
  • 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
  • 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
  • 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
  • 服务提供者无状态，任意一台宕掉后，不影响使用
  • 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复

    伸缩性

  • 注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
  • 服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者

升级性 当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力。

Dubbo高频面试题

1.Dubbo是什么 Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架，可以实现： 1.面向接口代理的高性能RPC调用

2.智能容错和负载均衡

3.服务自动注册和发现

4.高度可扩展能力

5.运行期流量调度

6.可视化的服务治理与运维。

2.Dubbo的注册中心 image.png 3.Dubbo的传输协议 image.png Dubbo:传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。 Hessian:传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。 4.Dubbo的重试机制 失败重试可以通过retrytimes （重试次数,默认100），retryperiod（重试周期，默认3000ms）进行设置。

5.Dubbo的负载均衡策略

loadBalancer 随机、轮训、最少活跃、Hash均衡

Dubbo与SpringCloud的比较

一、dubbo与SpringCloud的核心要素比较

1、dubbo由于是二进制的传输，占用带宽会更少 2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

5、dubbo的注册中心可以选择zk,redis等，springcloud的注册中心用eureka或者Consul

[

](https://blog.csdn.net/xuri24/article/details/89283802)