目录：
1、什么是微服务？
2、什么是微服务架构？
3、微服务的优缺点是什么？说下你在项目中碰到的坑。
4、微服务之间如何独立通讯？
5、你所知道微服务的技术栈有哪些？列举一二。
6、什么是Spring Cloud？
7、REST和RPC的区别？
8、SpringCloud 和 Dubbo 有哪些区别?
9、SpringCloud如何实现服务的注册和发现？
10、eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？
11、什么是CAP，并说明Eureka包含CAP中的哪些?
12、什么是服务熔断？什么是服务降级？
13、什么是Hystrix？它如何实现容错？
14、什么是Hystrix断路器？我们需要它吗？
15、项目中zuul常用的功能
16、服务网关的作用
17、ribbon和feign区别
18、ribbon的负载均衡策略
19、什么是 Spring Cloud Bus?我们需要它吗?
20、链路跟踪Sleuth
21、SpringBoot 和 SpringCloud 之间关系？
22、SpringCloud常用组件以及原理？
正文：
1、什么是微服务？
单个轻量级服务一般为一个单独微服务，微服务讲究的是 专注某个功能的实现，比如登录系统只专注于用户登录方面功能的实现，讲究的是职责单一，开箱即用，可以独立运行。通俗的来讲：
微服务就是一个独立的职责单一的服务应用程序。在 intellij idea 工具里面就是用maven开发的一个个独立的module，具体就是使用springboot 开发的一个小的模块，处理单一专业的业务逻辑，一个模块只做一个事情。将传统的all in one应用，根据业务功能的不同，拆分成一个个的服务，去掉以往的严重耦合现象，每个服务提供单个业务功能。微服务强调的是服务大小，关注的是某一个点，具体解决某一个问题/落地对应的一个服务应用，可以看做是idea 里面一个 module。
比如你去医院：你的牙齿不舒服，那么你就去牙科。你的头疼，那么你就去脑科。一个个的科室，就是一个微服务，一个功能就是一个服务。
2、什么是微服务架构？
微服务架构 就是 对微服务进行管理整合应用的。微服务架构 依赖于 微服务，是在微服务基础之上的。
例如：在医院里，每一个科室都是一个独立的微服务，那么 这个医院 就是 一个大型的微服务架构，就类似 院长 可以 对下面的 科室进行管理。微服务架构主要就是这种功能。
3、微服务的优缺点是什么？说下你在项目中碰到的坑。
优点：松耦合，聚焦单一业务功能，无关开发语言，团队规模降低。在开发中，不需要了解多有业务，只专注于当前功能，便利集中，功能小而精。微服务一个功能受损，对其他功能影响并不是太大，可以快速定位问题。微服务只专注于当前业务逻辑代码，不会和 html、css 或其他界面进行混合。可以灵活搭配技术，独立性比较舒服。
缺点：随着服务数量增加，管理复杂，部署复杂，服务器需要增多，服务通信和调用压力增大，运维工程师压力增大，人力资源增多，系统依赖增强，数据一致性，性能监控。
4、微服务之间如何独立通讯？
同步通信：dobbo通过 RPC 远程过程调用、springcloud通过 REST 接口json调用 等。
异步：消息队列，如：RabbitMq、ActiveM、Kafka 等。
5、你所知道微服务的技术栈有哪些？列举一二。
6、什么是Spring Cloud？
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
7、REST和RPC的区别？
REST风格的系统交互更方便，RPC调用服务提供方和调用方式之间依赖太强。
REST调用系统性能较低，RPC调用效率比REST高。
REST的灵活性可以跨系统跨语言调用，RPC只能在同语言内调用。
REST可以和Swagger等工具整合，自动输出接口API文档。
8、SpringCloud 和 Dubbo 有哪些区别?
首先，他们都是分布式管理框架。
dubbo 是二进制传输，占用带宽会少一点。SpringCloud是http 传输，带宽会多一点，同时使用http协议一般会使用JSON报文，消耗会更大。
dubbo 开发难度较大，所依赖的 jar 包有很多问题大型工程无法解决。SpringCloud 对第三方的继承可以一键式生成，天然集成。
SpringCloud 接口协议约定比较松散，需要强有力的行政措施来限制接口无序升级。
最大的区别:
Spring Cloud抛弃了Dubbo 的RPC通信，采用的是基于HTTP的REST方式。
严格来说，这两种方式各有优劣。虽然在一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适。
9、SpringCloud如何实现服务的注册和发现？
服务在发布时 指定对应的服务名（服务名包括了IP地址和端口） 将服务注册到注册中心（eureka或者zookeeper）。
这一过程是springcloud自动实现 只需要在main方法添加@EnableDisscoveryClient 同一个服务修改端口就可以启动多个实例。
调用方法：传递服务名称通过注册中心获取所有的可用实例 通过负载均衡策略调用（ribbon和feign）对应的服务。
10、eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？
zookeeper 是CP原则，强一致性和分区容错性。
eureka 是AP 原则 可用性和分区容错性。
zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，耗时过长，虽然最终能够恢复，但是选取主节点期间会导致服务不可用，这是不能容忍的。
eureka各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。
11、什么是CAP，并说明Eureka包含CAP中的哪些?
CAP理论：一个分布式系统不可能同时满足C (一致性),A(可用性),P(分区容错性).由于分区容错性P在分布式系统中是必须要保证的,因此我们只能从A和C中进行权衡.
Zookeeper保证了CP（C：一致性，P：分区容错性）
Eureka保证了AP（A：高可用，P：分区容错性）
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。也就是说，服务注册功能对高可用性要求比较高，但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。
Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：
Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）。
当网络稳定时，当前实例新的注册信息会被同步到其他节点。
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪。
12、什么是服务熔断？什么是服务降级？
服务熔断：作用类似于我们家用的保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用。
服务降级：是从整个系统的负荷情况出发和考虑的，对某些负荷会比较高的情况，为了预防某些功能（业务场景）出现负荷过载或者响应慢的情况，在其内部暂时舍弃对一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息。这样，虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性。
13、什么是Hystrix？它如何实现容错？
Hystrix是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。
通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。
思考以下微服务
假设如果上图中的微服务9失败了，那么使用传统方法我们将传播一个异常。但这仍然会导致整个系统崩溃。
随着微服务数量的增加，这个问题变得更加复杂。微服务的数量可以高达1000.这是hystrix出现的地方 我们将使用Hystrix在这种情况下的Fallback方法功能。我们有两个服务employee-consumer使用由employee-consumer公开的服务。
简化图如下所示
现在假设由于某种原因，employee-producer公开的服务会抛出异常。我们在这种情况下使用Hystrix定义了一个回退方法。这种后备方法应该具有与公开服务相同的返回类型。如果暴露服务中出现异常，则回退方法将返回一些值。
14、什么是Hystrix断路器？我们需要它吗？
由于某些原因，employee-consumer公开服务会引发异常。在这种情况下使用Hystrix我们定义了一个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。
如果firstPage method() 中的异常继续发生，则Hystrix电路将中断，并且员工使用者将一起跳过firtsPage方法，并直接调用回退方法。断路器的目的是给第一页方法或第一页方法可能调用的其他方法留出时间，并导致异常恢复。可能发生的情况是，在负载较小的情况下，导致异常的问题有更好的恢复机会 。
15、项目中zuul常用的功能
提供动态路由
提供安全、鉴权处理
跨域处理
全局动态路由的hystrix(熔断、降级、限流)处理
16、服务网关的作用
简化客户端调用复杂度，统一处理外部请求。
数据裁剪以及聚合，根据不同的接口需求，对数据加工后对外。
多渠道支持，针对不同的客户端提供不同的网关支持。
遗留系统的微服务化改造，可以作为新老系统的中转组件。
统一处理调用过程中的安全、权限问题。
Spring Cloud中的网关有：Zuul和Spring Cloud Gateway，最新版本中推荐使用后者。
17、ribbon和feign区别
Ribbon添加maven依赖 spring-starter-ribbon 使用@RibbonClient(value="服务名称") 使用RestTemplate调用远程服务对应的方法。
feign添加maven依赖 spring-starter-feign 服务提供方提供对外接口 调用方使用 在接口上使用@FeignClient("指定服务名")
Ribbon和Feign的区别：
Ribbon和Feign都是用于调用其他服务的，不过方式不同。
启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的@EnableFeignClients。
服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，
不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。
18、ribbon的负载均衡策略
RoundRobinRule: 轮询策略，Ribbon以轮询的方式选择服务器，这个是默认值。所以示例中所启动的两个服务会被循环访问;
RandomRule: 随机策略，也就是说Ribbon会随机从服务器列表中选择一个进行访问;
BestAvailableRule: 最大可用策略，即先过滤出故障服务器后，选择一个当前并发请求数最小的;
WeightedResponseTimeRule: 带有加权的轮询策略，对各个服务器响应时间进行加权处理，然后在采用轮询的方式来获取相应的服务器;
AvailabilityFilteringRule: 可用过滤策略，先过滤出故障的或并发请求大于阈值的一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个;
ZoneAvoidanceRule: 区域感知策略，先使用主过滤条件（区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例清单，依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数（默认1）和最小过滤百分比（默认0），最后对满足条件的服务器则使用RoundRobinRule(轮询方式)选择一个服务器实例。
19、什么是 Spring Cloud Bus?我们需要它吗?
Spring Cloud Bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其他的消息指令。Spring Cloud Bus的一个核心思想是通过分布式的启动器对Spring Boot应用进行扩展，也可以用来建立一个多个应用之间的通信频道。
考虑以下情况:我们有多个应用程序使用 Spring Cloud Config 读取属性，而 Spring 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 发挥作用的地方。
20、链路跟踪Sleuth
当我们项目中引入Spring Cloud Sleuth后，每次链路请求都会添加一串追踪信息，格式是[server-name, main-traceId,sub-spanId,boolean]：
server-name：服务结点名称。
main-traceId：一条链路唯一的ID，为TraceID。
sub-spanId：链路中每一环的ID，为SpanID。
boolean：是否将信息输出到Zipkin等服务收集和展示。
Sleuth的实现是基于HTTP的，为了在数据的收集过程中不能影响到正常业务，Sleuth会在每个请求的Header上添加跟踪需求的重要信息。这样在数据收集时，只需要将Header上的相关信息发送给对应的图像工具即可，图像工具根据上传的数据，按照Span对应的逻辑进行分析、展示。
21、SpringBoot 和 SpringCloud 之间关系？
SpringBoot：专注于快速方便的开发单个个体微服务（关注微观）；SpringCloud：关注全局的微服务协调治理框架，将SpringBoot开发的一个个单体微服务组合并管理起来（关注宏观）；
SpringBoot可以离开SpringCloud独立使用，但是SpringCloud不可以离开SpringBoot，属于依赖关系。
22、SpringCloud常用组件以及原理？
组件：
Eureka：服务注册与发现
Zuul：服务网关
Ribbon：客户端负载均衡
Feign：声明性的Web服务客户端
Hystrix：断路器
Config：分布式统一配置管理
组件工作流程图：
Eureka：
原理：
注册中心本质：存储每个客户端的注册信息，EurekaClient从EurekaServer同步获取服务注册列表，通过一定的规则选择一个服务进行调用。Eureka架构图如下：
服务提供者：是一个Eureka client，向 Eureka Server注册和更细自己的信息，同时能从Eureka Server注册表中获取到其他服务的信息。
服务注册中心：提供服务注册和发现的功能。每个Eureka Client向Eureka Server注册自己的信息，也可以通过Eureka Server获取到其他服务的信息达到发现和调用其他服务的目的。
服务消费者：是一个Eureka client，通过Eureka Server获取注册的其他服务信息，从而找到所需要的服务发起远程调用。
注册：服务提供者向Eureka Server端注册自身的元数据以供服务发现。
续约：通过发送心跳到Server以维持和更新注册表中服务实例元数据的有效性。在一定时长内，Server没有收到Client的心跳信息，将默认下线，会把服务实例信息从注册表中删除。
下线：服务提供方在关闭时候主动向Server注销服务实例元数据，这时服务提供方实例数据将从Server的注册表中删除。
获取注册表：服务消费者Client向Server请求注册表信息，用于服务发现，从而发起远程调用。
工作流程：
1、Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息
2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务
3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常
4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例
5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端
6、当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式
7、Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地
8、服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存
9、Eureka Client 获取到目标服务器信息，发起服务调用
10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除
参考文章：
https://cxyroad.blog.csdn.net/article/details/112855602
https://blog.csdn.net/u013469325/article/details/105668828/
https://segmentfault.com/a/1190000023558936