面试篇：SpringCloud

Spring Spring Boot SpringCloud

Spring Boot 和 Spring 是什么关系?

SpringBoot 底层就是 Spring，简化使用 Spring 的方式而已，多加了好多的自动配置

Spring Boot 和 Spring Cloud 是什么关系?

Spring Boot 是 Spring 的一套快速配置脚手架，可以基于 Spring Boot 快速开发单个微服务。

Spring Cloud 是一个基于 Spring Boot 实现的开发工具；Spring Boot 专注于快速、方便集成的单个微服务个体，Spring Cloud 关注全局的服务治理框架；

Spring Boot 使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置。

Spring Cloud 很大的一部分是基于 Spring Boot 来实现，必须基于 Spring Boot 开发。

可以单独使用 Spring Boot 开发项目，但是 Spring Cloud 离不开 Spring Boot。

SpringCloud

微服务是一种架构方式，最终肯定需要技术架构去实施。

后台硬：作为Spring家族的一员，有整个Spring全家桶靠山，背景十分强大。

技术强：Spring 作为Java领域的前辈，可以说是功力深厚。有强力的技术团队支撑。

群众基础好：可以说大多数程序员的成长都伴随着Spring框架。

SpringCloud与Spring的各个框架无缝整合，对大家来说一切都是熟悉的配方，熟悉的味道。

使用方便：相信大家都体会到了SpringBoot给我们开发带来的便利，而SpringCloud完全支持SpringBoot的开发，用很少的配置就能完成微服务框架的搭建

Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。

SpringCloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。

Eureka：注册中心

Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址

提供者：启动后向Eureka注册自己信息（地址，提供什么服务）

消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新

心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

作用：实现服务治理（服务注册与发现）

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

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

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

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

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

Zuul：服务网关

作用：api网关，路由，负载均衡等多种作用

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

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

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现鉴权、动态路由等等操作。Zuul就是我们服务的统一入口

默认的路由规则

在使用Zuul的过程中，上面讲述的规则已经大大的简化了配置项。但是当服务较多时，配置也是比较繁琐的。因此Zuul就指定了默认的路由规则：

默认情况下，一切服务的映射路径就是服务名本身。

例如服务名为： user-service ，则默认的映射路径就是： /user-service/**

路由前缀

zuul: 
    prefix: /api # 添加路由前缀 
    routes: 
        user-service: # 这里是路由id，随意写 
            path: /user-service/** # 这里是映射路径 
            service-id: user-service # 指定服务名称

我们通过 zuul.prefix=/api 来指定了路由的前缀，这样在发起请求时，路径就要以/api开头。

路径 /api/user-service/user/1 将会被代理到 /user-service/user/1

负载均衡和熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystrix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：

zuul: 
    retryable: true 
ribbon: 
    ConnectTimeout: 250 # 连接超时时间(ms) 
    ReadTimeout: 2000 # 通信超时时间(ms) 
    OkToRetryOnAllOperations: true # 是否对所有操作重试 
    MaxAutoRetriesNextServer: 2 # 同一服务不同实例的重试次数 
    MaxAutoRetries: 1 # 同一实例的重试次数 
hystrix: 
    command: 
        default: 
            execution:

Ribbon：负载均衡

Ribbon是Netflix发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为。

为Ribbon配置服务提供者地址列表后，Ribbon就可以基于某种负载均衡算法，自动的帮助服务消费者去请求。

Ribbon默认为我们提供了很多的负载均衡算法，例如轮询、随机等。

同时我们也可以为Ribbon实现自定义的负载均衡算法。

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

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

Feign：服务调用

简介

feign是声明式的web service客户端，它让微服务之间的调用变得更简单了，类似controller调用service。Spring Cloud集成了Ribbon和Eureka，可在使用Feign时提供负载均衡的http客户端。

点击查看[SpringCloud之Feign简介及使用]

Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。

Feign中本身已经集成了Ribbon依赖和自动配置。

Hystrix支持

Feign默认也有对Hystrix的集成

只不过，默认情况下是关闭的。我们需要通过下面的参数来开启

feign:
    hystrix: 
        enabled: true # 开启Feign的熔断功能

Hystix：熔断器

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

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

SpringCloud相关

微服务之间如何独立通讯的?

同步通信：dobbo通过 RPC 远程过程调用、springcloud通过 REST 接口json调用等。

异步：消息队列，如：RabbitMq、ActiveM、Kafka 等。

SpringCloud 和 Dubbo 有哪些区别?

首先，他们都是分布式管理框架。

dubbo 是二进制传输，占用带宽会少一点。SpringCloud是http 传输，带宽会多一点，同时使用http协议一般会使用JSON报文，消耗会更大。

dubbo 开发难度较大，所依赖的 jar 包有很多问题大型工程无法解决。SpringCloud 对第三方的继承可以一键式生成，天然集成。

SpringCloud 接口协议约定比较松散，需要强有力的行政措施来限制接口无序升级。

最大的区别:

Spring Cloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。

SpringBoot 和 SpringCloud 之间关系？

SpringBoot：专注于快速方便的开发单个个体微服务（关注微观）；SpringCloud：关注全局的微服务协调治理框架，将SpringBoot开发的一个个单体微服务组合并管理起来（关注宏观）；

SpringBoot可以离开SpringCloud独立使用，但是SpringCloud不可以离开SpringBoot，属于依赖关系。

什么是熔断？什么是服务降级？

服务熔断的作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。

服务降级是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。

微服务的优缺点是什么

优点：松耦合，聚焦单一业务功能，无关开发语言，团队规模降低。在开发中，不需要了解多有业务，只专注于当前功能，便利集中，功能小而精。微服务一个功能受损，对其他功能影响并不是太大，可以快速定位问题。微服务只专注于当前业务逻辑代码，不会和 html、css 或其他界面进行混合。可以灵活搭配技术，独立性比较舒服。

缺点：随着服务数量增加，管理复杂，部署复杂，服务器需要增多，服务通信和调用压力增大，运维工程师压力增大，人力资源增多，系统依赖增强，数据一致性，性能监控。

eureka和zookeeper都可以提供服务注册与发现的功能，两个的区别

zookeeper 是CP原则，强一致性和分区容错性。

eureka 是AP原则可用性和分区容错性。

zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，耗时过长，虽然最终能够恢复，但是选取主节点期间会导致服务不可用，这是不能容忍的。

eureka各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。