1. 什么是微服务?
1:以前的模式是 所有的代码在同一个工程中 部署在同一个服务器中 同一个项目的不同模块不同功能互相抢占资源
2:微服务将工程根据不同的业务规则拆分成微服务 微服务部署在不同的机器上 服务之间进行相互调用
3:Java微服务的框架有 dubbo（只能用来做微服务），spring cloud（提供了服务的发现，断路器等）
4:微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,
5:每一个微服务提供单个业务功能的服务,一个服务做一件事,
6:从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁
7:拥有自己独立的数据
2. SpringCloud的特点
1.约定优于配置
2.使用于各种环境
3.隐蔽了组件的复杂性,并提供了声明式无xml的配置方式
4.开箱即用,快速启动
5.轻量级的组件,如Eureka、Feign、zuul等
6.组件丰富,SpringCloud为微服务提供了非常完整的支持。如配置管理、服务注册发现、动态路由、断路器、网关
3. springcloud如何实现服务的注册和发现
服务在发布时 指定对应的服务名（服务名包括了IP地址和端口） 将服务注册到注册中心（eureka或者zookeeper）
这一过程是springcloud自动实现 只需要在main方法添加@EnableDisscoveryClient 同一个服务修改端口就可以启动多个实例
调用方法：传递服务名称通过注册中心获取所有的可用实例 通过负载均衡策略调用（ribbon和feign）对应的服务
4.Ribbon和Feign的区别
Ribbon和Feign都是用于调用其他服务的，不过方式不同。
1.启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2.服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
3.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，
不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。
5.springcloud断路器的作用
当一个服务调用另一个服务,由于网络原因或者自身原因出现问题时,调用者就会等待被调用者的响应,当更多的服务请求到这些资源时,导致更多的请求等待,这样就会发生连锁效应（雪崩效应）断路器就是解决这一问题
断路器有完全打开状态
一定时间内,达到一定的次数无法调用,并且多次检测没有恢复的迹象,断路器完全打开，那么下次请求就不会请求到该服务
半开
短时间内 有恢复迹象 断路器会将部分请求发给该服务 当能正常调用时 断路器关闭
关闭
当服务一直处于正常状态 能正常调用 断路器关闭
6.微服务之间是如何独立通讯的spring Cloud和 Dubbo有哪些区別?
本质区别：
dubbo 是 基于 RPC 远程 过程调用
cloud 是基于 http rest api 调用
最大区别: Spring Cloudi抛弃了 Dubbo的RPC通信,采用的是基于HTP的REST方式。
严格来说,这两种方式各有优劣。虽然从一定程度上来说,后者牺牲了服务调用的性能,但也避兔了上面提到的原生RPC带来的问题。
而且REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加合适
7.Spring Boot和 Spring Cloud,请你谈谈对他们的理解
spring boot 是一个快速整合第三方框架 关注的是 微观 具体关注快速方便的开发单个个体的 服务
spring cloud 关注的是 宏观 具体关注全局的微服务协调整理治理框架 将spring boot 开发的一个个单体服务整合 并管理起来
它为各个微服务之间提供 配置管理 服务发现 断路器路由 微代理 全局锁 分布式会话 等 集成服务
举个例子 ： 一所医院 boot 是 一个一个科室 cloud 是把一个一个科室 组合起来 对外称之为 医院
存在依赖关系 cloud 离不开boot。
springboot不等于微服务，它只是一套开源框架，跟ssm差不多，只是基于springboot来开发微服务相当方便，所以这两个词一般都是成对出现的。当我们的服务越来越多时，
就可以通过springcloud来统一管理这些服务了，springcloud才算是真正的微服务框架。可以认为 springboot ≈ ssm，springcloud = 多个 springboot
8.hystrix 断路器
服务熔断 是指 由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。
9. 什么是服务降级 微服务的优缺点分別是什么?
用通俗易懂的来说:整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来
优点:
a:每个服务足够内聚足够小,代码容易理解
b:开发简单开发效率高
c:微服务小团队也能独立开发
d:微服务是松耦合的，是一个个有功能意义的服务，无论是开发和部署阶段都时独立的
e:微服务能使用不同的语言开发
f:易于和第三方进行集成
缺点
a:开发人员要处理分布式系统的复杂性
b:多服务运维难度，随着服务的增加，运维压力也增大
c:系统部署间的相互依赖
d:服务间的通信成本
e:系统集成
f:数据的一致性
g:性能的监控
10.说下你在项目开发中碰到的坑你所知道的微服务技术栈有哪些?
1 服务治理 2 服务注册 3 服务调用 4 负载均衡 5 服务监控
11.请说说eureka和 zookeeper,两个的区別?
首先 说CAP 是什么 所谓的CAP C强一致性 A可用性 P 分区容错性
著名的CAP理论指出,
一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。
zookeeper 遵守 CP
当向注册中心查询服务列表时, 我们可以容忍注册中心返回的是几分钟以前的注册信息, 但不能接受服务直接down掉不可用。
也就是说服务注册功能对可用性的要求要高于一致性。
但是zookeeper 会出现这样一种情况, 当 master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行 leader选举。
问题在于,选举 leader的时间太长,30~120s,目选举期间整个zookeeper 集群都是不可用的,这就导致在选举期间注册服务瘫痪。
当有一个zookeeper 挂了 那其他的zookeeper 会进行 一次选举 （强一致性 ： 我一定要保持数据一致性） 而在此选举期间 zookeeper 是不可用的 而当前 有用户正在使用 用户就不爽了 。
eureka 遵守 AP
Eureka:看明白了这一点,因此在设计时就优先保证可用性。
Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。
而 Eureka的客户端在向某个 Eureka注册或时如果发现连接失败,则会自动切换至其它节点
只要有一台 Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的不保证强一致性)。
除此之外, Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么 Eurekas就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1:Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2：Eureka仍然能够接受新服务的注册和査询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
3:当网络稳定时,当前实例新的注册信息会被同步到其它节点中
因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情況,而不会像 zookeeper那样使整个注册服务瘫痪。
12.Eureka组件详解
Eureka由多个instance(服务实例)组成，这些服务实例可以分为两种：Eureka Server和Eureka Client。为了便于理解，我们将Eureka client再分为Service Provider和Service Consumer。
Eureka Server：服务的注册中心，负责维护注册的服务列表。
Service Provider：服务提供者，作为一个Eureka Client，向Eureka Server做服务注册、续约和下线等操作，注册的主要数据包括服务名、机器ip、端口号、域名等等。
Service Consumer：服务消费者，作为一个Eureka Client，向Eureka Server获取Service Provider的注册信息，并通过远程调用与Service Provider进行通信。
Service Provider和Service Consumer不是严格的概念，Service Consumer也可以随时向Eureka Server注册，来让自己变成一个Service Provider。
Spring Cloud针对服务注册与发现，进行了一层抽象，并提供了三种实现：Eureka、Consul、Zookeeper。目前支持得最好的就是Eureka，其次是Consul，最后是Zookeeper。
13.Rabbin负载均衡组件详解
Ribbon是Netflix发布的开源项目，主要功能是为REST客户端实现负载均衡。它主要包括六个组件：
ServerList，负载均衡使用的服务器列表。这个列表会缓存在负载均衡器中，并定期更新。当Ribbon与Eureka结合使用时，ServerList的实现类就是DiscoveryEnabledNIWSServerList，它会保存Eureka Server中注册的服务实例表。
ServerListFilter，服务器列表过滤器。这是一个接口，主要用于对Service Consumer获取到的服务器列表进行预过滤，过滤的结果也是ServerList。Ribbon提供了多种过滤器的实现。
IPing，探测服务实例是否存活的策略。
IRule，负载均衡策略，其实现类表述的策略包括：轮询、随机、根据响应时间加权等，其类结构如下图所示
ILoadBalancer，负载均衡器。这也是一个接口，Ribbon为其提供了多个实现，比如ZoneAwareLoadBalancer。
RestClient，服务调用器。顾名思义，这就是负载均衡后，Ribbon向Service Provider发起REST请求的工具。
14.Feigin远程调用
Feign是一个声明式的Web Service客户端，它的目的就是让Web Service调用更加简单。它整合了Ribbon和Hystrix，从而让我们不再需要显式地使用这两个组件。Feign还提供了HTTP请求的模板，通过编写简单的接口和插入注解，我们就可以定义好HTTP请求的参数、格式、地址等信息。接下来，Feign会完全代理HTTP的请求，我们只需要像调用方法一样调用它就可以完成服务请求。
Feign具有如下特性：
1.可插拔的注解支持，包括Feign注解和JAX-RS注解
2.支持可插拔的HTTP编码器和解码器
3.支持Hystrix和它的Fallback
4.支持Ribbon的负载均衡
5.支持HTTP请求和响应的压缩
以下是一个Feign的简单示例：
15.SpringCloud核心组件
1:Eureka（Eureka是微服务架构中的注册中心，专门负责服务的注册与发现）
Eureka Client： 负责将这个服务的信息注册到Eureka Server中
Eureka Server： 注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号
续约与剔除: 服务实例启动后，会周期性地向Eureka Server发送心跳以续约自己的信息，避免自己的注册信息被剔除。续约的方式与服务注册基本一致：首先更新自身状态，再同步到其它Peer。
如果Eureka Server在一段时间内没有接收到某个微服务节点的心跳，Eureka Server将会注销该微服务节点
2:Feign（ Feign的一个关键机制就是使用了动态代理）
没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个 FeignClient接口，然后调用那个接口就可以了。Feign Client会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起请求、获取响应、解析响应，等等。这一系列脏活累活，人家Feign全给你干了。
1.首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
2.接着你要调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
3.Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
4.最后针对这个地址，发起请求、解析响应
3:Ribbon（作用是负载均衡,会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上）
Ribbon的负载均衡默认使用的最经典的 Round Robin轮询算法,还有随机算法
此外，Ribbon是和Feign以及Eureka紧密协作，完成工作的，具体如下：
首先Ribbon会从 Eureka Client里获取到对应的服务注册列表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。
然后Ribbon就可以使用相应的负载均衡算法，从其中选择一台机器
Feign就会针对这台机器，构造请求地址并发起请求。
4:Hystrix（ Hystrix是隔离、熔断以及降级的一个框架）
微服务架构中恐怖的服务雪崩问题
多服务互相调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。 当然，在请求失败频率较低的情况下，Hystrix还是会直接把故障返回给客户端。只有当失败次数达到阈值（默认在20秒内失败5次）时，断路器打开并且不进行后续通信，而是直接返回备选响应。
隔离：Hystrix会搞很多个小小的线程池 ，比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务，与别的服务互补影响。
熔断：但是如果积分服务都挂了，每次调用都要去卡住几秒钟？有意义吗？当然没有！ 所以我们直接对积分服务熔断，比如在5分钟内请求积分服务直接就返回了，不要去走网络请求卡住几秒钟，这个过程，就是所谓的熔断
降级：没问题，咱们就来个降级：每次调用积分服务，你就在数据库里记录一条消息，如给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，你可以根据这些记录手动加一下积分。 这个过程，就是所谓的降级
5:Zuul（这个组件是负责网络路由的）
所以一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都从网关走，网关会根据请求中的一些特征，将请求转发给后端的相应的各个服务。
而且有一个网关之后，还有很多好处，比如可以做 统一的降级、限流、认证授权、安全 ，等等。
服务治理为心脏，路由网关、消息中心、断路器、链路追踪、配置中心等为依托，构造了整个微服务框架的「五脏六腑 ]