微服务常见问题整理（2021）
微服务常见问题
什么是微服务
（把传统服务拆分⾄最⼩服务单元，每个服务专注⼀件事，服务之间⾼内聚，松耦合）
技术维度理解
微服务化的核⼼就是将传统的⼀站式应⽤，根据业务拆分成⼀个⼀个的服务，彻底地去耦合，每⼀个微服务提供单个业务功能的服务，⼀个服务做⼀件事，从技术⾓度看就是⼀种⼩⽽独⽴的处理过程，类似进程概念，能够⾃⾏单独启动或销毁，拥有⾃⼰独⽴的数据库。
微服务是如何通讯的
1、远程调⽤基于HTTP的RESTful API
2、 消息 ，通过消息中间件来做服务通信，⽐如rabitmq
springcloud 与dubbo有哪些区别？
相同点：SpringCloud 和Dubbo可以实现RPC远程调⽤框架，可以实现服务治理。
不同点：SpringCloud是⼀套⽬前⽐较⽹站微服务框架了，整合了分布式常⽤解决⽅案遇到了问题注册中⼼Eureka、负载均衡器Ribbon ，客户端调⽤⼯具Rest和Feign，分布式配置中⼼Config，服务保护Hystrix，⽹关Zuul Gateway ，服务链路Zipkin，消息总线Bus等。
优点: 把客户端和服务端解耦，更松耦合 提⾼可⽤性，因为消息中间件缓存了消息，直到消费者可以消费，⽀持很多通信机制⽐如通知、请求/异步响应、发布/订阅、发布/异步响应
缺点：消息中间件有额外的复杂性
dubbo内部实现功能没有SpringCloud强⼤（全家桶），只是实现服务治理，缺少分布式配置中⼼、⽹关、链路、总线等，如果需要⽤到这些组件，需要整合其他框架。
请谈谈对SpringBoot 和SpringCloud的理解
SpringBoot专注于快速、⽅便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。
SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的⼀个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务
SpringBoot可以离开SpringCloud独⽴使⽤开发项⽬，但是SpringCloud离不开SpringBoot，属于依赖的关系.
分布式系统⾯临的问题
复杂分布式体系结构中的应⽤程序有数⼗个依赖关系，每个依赖关系在某些时候将不可避免地失败。
服务雪崩：多个微服务之间调⽤的时候，假设微服务A调⽤微服务B和微服务C，微服务B和微服务C⼜调⽤其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调⽤响应时间过长或者不可⽤，对微服务A的调⽤就会占⽤越来越多的系统资源，进⽽引起系统崩溃，所谓的“雪崩效应”.
⼀般情况对于服务依赖的保护主要有以下三种解决⽅案：
1、熔断模式：这种模式主要是参考电路熔断，如果⼀条线路电压过⾼，保险丝会熔断，防⽌⽕灾。放到我们的系统中，如果某个⽬标
服务调⽤慢或者有⼤量超时，此时，熔断该服务的调⽤，对于后续调⽤请求，不在继续调⽤⽬标服务，直接返回，快速释放资源。如果⽬标服务情况好转则恢复调⽤。
隔离模式：这种模式就像对系统请求按类型划分成⼀个个⼩岛的⼀样，当某个⼩岛被⽕少光了，不会
影响到其他的⼩岛。例如可以对不同类型的请求使⽤线程池来资源隔离，每种类型的请求互不影响，如果⼀种类型的请求线程资源耗尽，则对后续的该类型请求直接返回，不再调⽤后续资源。这种模式使⽤场景⾮常多，例如将⼀个服务拆开，对于重要的服务使⽤单独服务器来部署，再或者公司最近推⼴的多中⼼。
限流模式：上述的熔断模式和隔离模式都属于出错后的容错处理机制，⽽限流模式则可以称为预防模式。限流模式主要是提前对各个类型的请求设置最⾼的QPS阈值，若⾼于设置的阈值则对该请求直接返回，不再调⽤后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。
什么事服务熔断，什么是服务降级
服务熔断：熔断机制是应对雪崩效应的⼀种微服务链路保护机制。当扇出链路的某个微服务不可⽤或者响应时间太长时，会进⾏服务的降级，进⽽熔断该节点微服务的调⽤，快速返回”错误”的响应信息。当检测到该节点微服务调⽤响应正常后恢复调⽤链路。
在SpringCloud框架⾥熔断机制通过Hystrix实现。Hystrix会监控微服务间调⽤的状况，当失败的调⽤到⼀定阈值，缺省是5秒内20次调⽤失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。
Hystrix服务降级：其实就是线程池中单个线程障处理，防⽌单个线程请求时间太长，导致资源长期被占有⽽得不到释放，从⽽导致线程池被快速占⽤完，导致服务崩溃。
整体资源快不够⽤了，忍痛将某些服务先关掉，待度过难关，再回来开启。
所谓降级，就是⼀般是从整体符合考虑，就是当某个服务熔断之后，服务器将不再被调⽤，此刻客户端可以⾃⼰准备⼀个本地的fallback回调，返回⼀个缺省值，这样做，虽然服务⽔平下降，但好⽍可⽤，⽐直接挂掉要强。
请求超时降级，线程资源不⾜降级，降级之后可以返回⾃定义数据
微服务的优缺点，项⽬中遇到的坑
优点
每个服务专注⼀件事，更⼩ 更内聚，开发简单，效率⾼
每个服务可以使⽤不同语⾔开发
每个服务独⽴，服务建松耦合
易于第三⽅集成
缺点
维护成本增加，
系统复杂性增加
分布式⼀致性问题
数据⼀致性问题
服务通信成本增加
服务依赖
性能监控
什么是 Eureka服务注册与发现
Eureka是⼀个基于REST的服务，⽤于定位服务，以实现云端中间层服务发现和故障转移。
服务注册与发现对应微服务架构来说⾮常重要，有了服务发现和注册，值需要使⽤服务的标志符，就可以访问到服务，⽽不需要更改调⽤的配置⽂件。
Eureka的基本架构是什么？
eureka ⽐zookepper 好在哪
AP理论指出，⼀个分布式系统不可能同时满⾜C(⼀致性)、A(可⽤性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进⾏权衡。
Zookeeper 保证的是CP, Eureka 则是AP。
zk服务注册功能对可⽤性的要求要⾼于⼀致性。但是zk会出现这样⼀种情况，当master节点因为⽹络故障与其他节点失去联系时，剩余节点会重新进⾏leader选举。
问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集都是不可⽤的，这就导致在选举期间注册服务瘫痪。
分布式和微服务的关系
分布式更注重可⽤，最终⼀致性
Ribbon负载均衡
Spring Cloud Ribbon是基于Netflix Ribbon实现的⼀套客户端 负载均衡的⼯具。
Ribbon会⾃动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使⽤Ribbon实现⾃定义的负载均衡算法。
feign能⼲什么
Feign旨在使编写Java Http客户端变得更容易。
利⽤RestTemplate对http请求的封装处理，形成了⼀套模版化的调⽤⽅法。
Feign集成了Ribbon
利⽤Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡。
⽽与Ribbon不同的是，通过feign只需要定义服务绑定接⼝且以声明式的⽅法，优雅⽽简单的实现了服务调⽤
什么是 Hystrix断路器
Hystrix是⼀个⽤于处理分布式系统的延迟和容错的开源库，在分布式系统⾥，许多依赖不可避免的会调⽤失败，⽐如超时、异常等，Hystrix能够保证在⼀个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提⾼分布式系统的弹性。
hystrix 断路器能⼲什么
服务降级
整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来
服务熔断
熔断机制是应对雪崩效应的⼀种微服务链路保护机制。
当扇出链路的某个微服务不可⽤或者响应时间太长时，会进⾏服务的降级，进⽽熔断该节点微服务的调⽤，快速返回”错误”的响应信息。当检测到该节点微服务调⽤响应正常后恢复调⽤链路。在SpringCloud框架⾥熔断机制通过Hystrix实现。Hystrix会监控微服务间调⽤的状况，当失败的调⽤到⼀定阈值，缺省是5秒内20次调⽤失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。
服务限流
接近实时的监控
除了隔离依赖服务的调⽤以外，Hystrix还提供了准实时的调⽤监控（Hystrix Dashboard），Hystrix会持续地记录所有通过Hystrix发起的请求的执⾏信息，并以统计报表和图形的形式展⽰给⽤户，包括每秒执⾏多少请求多少成功，多少失败等。Netflix通过hystrix-metrics-event-stream项⽬实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合，对监控内容转化成可视化界⾯。
什么是 zuul路由⽹关
Zuul 包含了对请求的路由和过滤两个最主要的功能：
其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统⼀⼊⼝的基础⽽过滤器功能则负责对请求的处理过程进⾏⼲预，
是实现请求校验、服务聚合等功能的基础.Zuul和Eureka进⾏整合，将Zuul⾃⾝注册为Eureka服务治理下的应⽤，同时从Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。
注意：Zuul服务最终还是会注册进Eureka
提供=代理+路由+过滤 三⼤功能
什么是SpringCloud Config分布式配置中⼼
SpringCloud Config为微服务架构中的微服务提供集中化的外部配置⽀持，配置服务器为各个不同微服务应⽤的所有环境提供了⼀个中⼼化的外部配置。
分布式配置中⼼能⼲嘛？
集中管理配置⽂件
不同环境不同配置，动态化的配置更新，分环境部署⽐如dev/test/prod/beta/release
运⾏期间动态调整配置，不再需要在每个服务部署的机器上编写配置⽂件，服务会向配置中⼼统⼀拉取配置⾃⼰的信息
当配置发⽣变动时，服务不需要重启即可感知到配置的变化并应⽤新的配置将配置信息以REST接⼝的形式暴露

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。