spring cloud面试题

微服务的四大核心问题

解决方案：

什么是微服务

微服务的核心是将传统的一站式应用，根据业务需求分成一个个的模块，每一个模块都是一个独立的服务，可以独立运行，独立部署，独立测试等，非常方便开发。拆分后每一个服务专注于一件业务，服务与服务之间的耦合性降低

什么是springCloud

SpringCloud是基于springboot提供了一套微服务解决方案，包括了注册与发现，配置中心，监控，服务网关，负载均衡等组件，利用springboot的开发方便性，巧妙的简化了分布式系统基础设施的开发。

SpringCloud和Dubbo有哪些区别

1. 通信方面：cloud采用Http协议的rest进行通信，dubbo采用Tcp协议进行rpc通信。（http协议会有更大的报文，所以占用宽带更大，而tcp协议占用宽带更小）
2. 配置方面：dubbo更加专注于通信，cloud是一个全家桶的配置集成，使用更为方便。
3. 使用方面：如果不使用springcloud，使用dubbo，那么就要考虑组件之间的配合性，如果不是技术很好的人，不建议使用dubbo
4. 社区活跃数没有cloud高。

dubbo由于是二进制的传输，占用带宽会更少

springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

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

总结：
在业界，一般有两种微服务的实践方法：基于dubbo的微服务架构、基于Spring Cloud的微服务架构。从概念上来讲，Dubbo和Spring Cloud并不能放在一起对比，因为Dubbo仅仅是一个RPC框架，实现Java程序的远程调用，实施服务化的中间件则需要自己开发；而Spring Cloud则是实施微服务的一系列套件，包括：服务注册与发现、断路器、服务状态监控、配置管理、智能路由、一次性令牌、全局锁、分布式会话管理、集群状态管理等。

五大组件

springcloud五大组件：1、服务发现Netflix Eureka；2、客服端负载均衡Netflix Ribbon；3、断路器Netflix Hystrix；4、服务网关Netflix Zuul；5、分布式配置。

1、Eureka

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

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

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

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

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

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

2、Ribbon

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

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

注意看上图，关键点就是将外界的rest调用，根据负载均衡策略转换为微服务调用。Ribbon有比较多的负载均衡策略，以后专门讲解。

3、Hystrix

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

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

4、Zuul

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

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

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

5、Config

作用：配置管理

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

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

Springboot和SpringCloud，谈谈你对它们的理解

什么是服务熔断服务降级

服务降级：当某个服务在一个时间段出现了高并发时，为了保证整个系统的稳定和高性能，就把那些非核心的服务暂时关掉，把更多的资源分给核心服务。
服务熔断：主要是应对雪崩效应的自我保护机制，可以看作为降级的特俗处理。
雪崩效应：



区别：
触发原因：服务熔断是因为调用链路上的某一个链路节点出现了异常导致的，而服务降级是因为在某一个时间段出现了高并发导致的。

微服务的优缺点分别是什么，说一下你在项目中遇到的坑

优点

1）将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。
2）微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。面对搞并发的场景可以将服务集群化部署，加强系统负载能力。
3）服务间采用HTTP协议通信，服务与服务之间完全独立。每个服务可以根据业务场景选取合适的编程语言和数据库。
4）微服务每个服务都是独立部署的，每个服务的修改和部署对其他服务没有影响。

缺点

复杂度高

微服务间通过REST、RPC等形式交互，相对于Monolithic模式下的API形式，需要考虑被调用方故障、过载、消息丢失等各种异常情况，代码逻辑更加复杂。

运维复杂

在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统。

总结
微服务在近几年大火，它具备了灵活部署、可扩展、技术异构等优点，但同时也带来了开发、运维的复杂性。是否要采用微服务架构需要根据系统的特点，结合企业的组织架构、团队能力等多个方面进行综合的判断，而不是为了微服务而微服务。

你所知道的微服务技术栈有哪些

docker

三大核心：仓库，镜像，容器（从仓库中拉取一个镜像，把镜像运行起来就成容器了）
作用：
解决运行环境不一致所导致的问题。这样就不会产生“本地运行没问题，可一到服务器上就不行了”的情况。
限定最大的cpu使用内存硬盘，这样就起到了隔离的作用，避免产生“一块代码产生死循环，把磁盘占满了，其它程序也挂了”的情况。

Docker 可以提供一组应用打包、传输和部署的方法，以便你能更好地在容器内运行任何应用。
特别之处：它只能运行在linux系统上。

环境（部署方便）：借助镜像可以快速进行项目部署，重要的是官方会提供很多可以支持项目程序部署环境的镜像，轻轻一拉便可运行。
资源：每个运行的容器都是基本最小的虚拟机环境，可以简单理解为阉割版的虚拟机。不要问为什么，因为资源有限。伸
缩扩容：在服务资源升级和回滚上，借助升级扩容，一键能完成成千上百的服务集群的快速部署。
网络：内部也有自己的一套网络管理，省时省力。

上面的都是优点，其实缺点也会有的：很多持久化的操作只能借助挂载存储的方式，否则很多之前启动的容器中的数据在意外停止或者是重启的时候便会丢失。如果docker出现了问题，那么排查问题会有一定的麻烦。

什么是eureka

Eureka 是一个基于 Rest 的服务，可以用于定位服务，服务注册和发现对于微服务架构来说是非常重要的。比如访问一个服务时，不需要修改服务调用的配置文件了。非常的简单。它还负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。

什么是是自我保护机制

默认情况下如果EurekaServer在一段时间内（默认90s）没有接受到某个微服务的心跳，那么就会判断这个微服务已经死亡，然后在服务注册表中注销该微服务。
但是当网络分区发生故障（延时、卡顿、拥挤）时，微服务与EurekaServer无法正常通信，但微服务本身是健康的，那么就不应该注销这个微服务。
此时Eureka将会开启自我保护模式来解决这个问题----当EurekaServer节点在短时间内丢失过多客户端时，就会开启自我保护模式，不再注销任何微服务。

什么是zookeeper

是一个开源的分布式协调服务系统，主要用于解决分布式系统集群中应用系统的一致性问题和数据管理问题。

特点

应用场景

配置管理：

选举机制

监听原理（观察者模式）

常用命令

ls（查看某个路径下的目录列表） , create(创建节点) , get（得到节点） , delete（删除节点） , se …

eureka和zookeeper都可以提供服务的注册于发现，请说说两者的区别

CAP:C(一致性),A(可用性),P(容错性)
由于分区容错性在分布式系统中是必须要保证的，因此只能在A和C之间进行权衡

• zookeeper保证CP
• eureka保证CA

1. eureka 保证了可用性，实现最终一致性。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，eureka是不满足强一致性，但还是会保证最终一致性

2. zookeeper CP
   zookeeper在选举leader时，会停止服务，直到选举成功之后才会再次对外提供服务，这个时候就说明了服务不可用，但是在选举成功之后，因为一主多从的结构，zookeeper在这时还是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性

ribbon和nginx负载均衡的区别

Nginx是服务端负载均衡，客户端所有请求都会交给Nginx，然后由Ngxin实现转发请求。

Ribbon本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表后缓存到jvm本地，从而在本地实现RPC远程调用服务技术。

ribbon本地负载均衡适合微服务rpc远程调用，比如：dubbo，springcloud

nginx服务负载均衡适合于针对服务器端，比如：tomcat、jetty

Feign

目前，在Spring cloud 中服务之间通过restful方式调用有两种方式

• restTemplate+Ribbon
• feign

feign：

Feign 是在 Ribbon 的基础上进行了一次改进，是一个使用起来更加方便的 HTTP 客户端。采用接口的方式， 只需要创建一个接口，然后在上面添加注解即可 ，将需要调用的其他服务的方法定义成抽象方法即可， 不需要自己构建 http 请求。然后就像是调用本地的方法，而感觉不到是调用远程方法，使得编写 客户端变得非常容易。