springcloud面试题

微服务概念

• 微服务架构就是将单体的应用程序根据业务功能划分成多个应用程序，这多个应用程序就成为微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信。
• 被划分后的个体微服务这些服务通常用springboot进行开发，SpringCloud是关注全局的微服务协调整理治理框架，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务，这些功能的实现技术都是采用的当前市场主流技术整合到springcloud的
• 独立部署。服务间可以使用不同的编程语言，不同数据库。

SpringBoot和SpringCloud的区别？

SpringBoot专注于快速方便的开发。
，它将SpringBoot开发的一个个单体微服务整合并管理起

• 本质上说分布式是一种架构风格，架构模式；将单一的应用程序拆分为多个小服务(①考虑功能性模块，如eureka，hystrix，zuul②根据业务不同，拆分出不同的业务模块，如order，pay，product③提取公共模块，如短信，邮件，图片上传oss…作为共用的工具类提取出来)；
• 每个服务运行独立的自己的进程中(由单体架构进程内通信变为微服务架构进程间通信)，服务之间互相协调、互相配合，最终为用户提供，服务之间相互协调配合，共同为用户提供最终服务，每个服务服务间采用轻量的进程通信(基于 http 和 restful api)；
• 每个服务能够独立开，发并独立部署到生产环境，注意避免统一的集中式的服务开发与管理,提高生成效率，容易查bug；

配置中心

实现

eurake、nacos、zookeeper做配置中心

目的

n个provider被n个conusmer调用，非常难进行管理，所以通过服务注册中心来完成服务间的依赖管理，实现负载均衡，容错，服务注册与发现，模块通信

服务注册与发现

• 服务注册：eurake为例，微服务各模块都在Eruake Server中注册，注册自己的ip、applicationName、监听端口，注册后成为eurake client
• 每个eurake client模块可以通过依赖注入获取discoveryClient组件来获取到Eruake Server中服务的注册信息

架构图

微服务间远程调用

消费者调用生产者的过程有大量远程调用，手动编写http接口调用过于繁琐

openfeign注解中的是服务名称代表一个服务类型，一个服务类型下可能对应多个生产者服务器，openfeign内部集成了负载均衡组件，实现分布式的负载均衡调用，通过服务名称获取从配置中心获取对应的ip和监听地址，接口方法上的注解代表请求路径和请求入参，通过这些部分拼接

https://${@FeignClient.ip}:{@FeignClient:port}/ ${@GetMapping}/${PathVariable}

架构图

负载均衡

一个服务部署到多台机器,那Feign怎么知道请求那台服务器呢,这是SpringCloud就派上用场了,Ribbon 务就是解决这个问题的,他的作用是负载均衡,会帮你在每一次请求的时候选择一台机器,均匀的把请求发送到各个机器上 ,Ribbon的负载均衡默认的使用RoundRobin轮询算法

架构图

Hystrix

处理分布式系统故障、容错的开源库，分布式系统中不可避免的出现服务的调用失败，导致超时、异常等，Hystrix在保证一个依赖出问题的时候不会涉及到其它模块

服务雪崩

高并发的情况下,如何积分服务模块出现故障，导致接口执行严重超时，大量请求涌到订单服务,订单服务首先调用积分服务时，因为订单服务异常，超时执行时间过长可能会导致大部分tomcat的线程都被卡到这个订单服务上，其它服务需要被使用时没有足够的线程，进而导致其它服务也受到影响导致执行超时，也就是微服务系统中往往一个服务出现故障，就可能会由于tomcat线程池的缘故导致故障蔓延，导致所谓的服务雪崩

服务熔断

果别人请求订单服务,订单服务还是可以正常调用库存服务扣减库存、调用仓储服务通知发货。只不过调用积分服务的时候，由于每次都会报错，就不必再每次去调用订单服务了。所以我们直接对积分服务熔断不就得了，比如在5分钟内请求积分服务直接就采用服务降级，不要去走网络请求卡住几秒钟，这个过程，就是所谓的服务熔断！

服务降级

积分服务挂被熔断需要进行服务降级，这里的策略是每次调用积分服务，你就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，你可以根据这些记录手工加一下积分。这个过程，就是所谓的降级

服务降级

生产者模块的接口程序运行时抛出异常、服务熔断、线程池/信号量打满、接口超时，消费者端请求接口超过它的限定均会被判断为服务异常导致不能正常运行时提供一个降级方案fallback

服务限流

用于秒杀等高并发常见，限制最大线程数，按序进行，防止系统崩溃

断路器

网关

解决痛点

传统的单体架构中只需要开放一个服务给客户端调用，但是微服务架构中是将一个系统拆分成多个微服务，如果没有网关，客户端只能在本地记录每个微服务的调用地址，当需要调用的微服务数量很多时，它需要了解每个服务的接口，这个工作量很大

怎样的改善呢

网关作为系统的唯一流量入口，封装内部系统的架构，所有请求都先经过网关，由网关将请求路由到合适的微服务使用网关的好处在于：

• 简化客户端的工作。网关将微服务封装起来后，客户端只需同网关交互，而不必调用各个不同服务；
• 降低函数间的耦合度。 一旦服务接口修改，只需修改网关的路由策略，不必修改每个调用该函数的客户端，从而减少了程序间的耦合性
  （3）解放开发人员把精力专注于业务逻辑的实现。由网关统一实现服务路由(灰度与ABTest)、负载均衡、访问控制、流控熔断降级等非业务相关功能，而不需要每个服务 API 实现时都去考虑
  ————————————————
  版权声明：本文为CSDN博主「张维鹏」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
  原文链接：https://blog.csdn.net/a745233700/article/details/122917167

2 eureka服务调用

• 采用的CS架构

• Eureka是Xxx物业公司，Provider则是其中的各种超时，饭店，他们要在Xxx工业园租房来住，consumer则是客户
• 两个重要组件①EurekaServer：服务注册中心，微服务各模块都在此注册，随后可以在微服务列表上看到②EurekaClient，除了Eureka的组件，主要是provider和conusmer这两类
• 实际代码①eurekaServer配置微服务port，和eureka的hostname服务名，这个通常是域名，声明自己是eureka注册中心(registerWithEureka=false，fetchRegistry=false)②eurekaClient：配置微服务port+服务名③discoverClient功能是可以清楚的调查清每一个服务模块能够提供的服务，注入DiscoveryClient对象，写方法，调用getServices…
• Eureka的自我保护机制：采用cp的模式，宁可保留错误信息，也不会随意注销任何可能健康的微服务，好死不如赖活着
• eureka的作用①服务器宕机，及时进行清理，心跳连接确定服务状态②实现客户端负载均衡的必备项(客户端配置的ribbon或者feign都要先从服务器端的服务列表拿数据)③服务发现，客户端获取当前服务信息④服务列表，提供服务状态信息

3 ribbon

• 提供客户端的负载均衡算法和服务调用功能，如80通过轮询负载均衡调用8001和8002
• 负载均衡的目的是将用户的请求平摊到多个服务上，达到系统高可用
• 对比nginx：nginx的话是服务器端的负载均衡，拦截所有请求，然后在通过它进行转发，这是集中式的负载均衡；ribbon则是在调用服务注册中心服务时，将注册中心的服务列表缓存到jvm中，然后通过某种规则(如轮询算法，随机算法)远程rpc调用实现负载均衡，是服务端的负载均衡
• 关系，你去医院看病，nginx是导诊台，告诉你去哪个科室(需要那种服务,比如牙科)，而ribbon则是牙科室助理护士，她告诉你哪个牙科大夫有时间就诊
• ribbon = lb负载均衡 + restTempelete的调用
• 工作方式：优先选择一个Eureka Server（es），然后通过某种用户指定的策略，在es的服务列表中按xx策略进行调用

4 CAP理论：

• C是consistency强一致性，A是accessible可重用性，P是parition tolerance分区容错性
• 任何一种系统不可能全部符合CAP特性，只能满足其中两条CA,CP,AP,CAP理论关注的力度是数据而不是整体的设计策略
• eureka是ap(好死不如赖活着)，zookeeper和consul是cp，这三者都集成到了springcloud中

6 hystrix
①存在的问题:一个服务的完成会调用成白上千的依赖，中间出现任何一点小问题都可能会导致服务雪崩。解决方案是:hystrix降低分布式系统的延迟，提高容错性，保证在一个依赖故障后不会导致整个服务崩盘，避免联级错误，通常在消费端使用，偶尔在服务端使用

②三大特点:

• 服务降级fallback:程序运行故障，超时，除了发服务熔断，线程池满，这些情况系统会给用户回馈异常信息
• 服务熔断:类似于保险丝熔断或者电压过大跳闸，也就是服务数达到最大超负荷，为避免意外直接拉闸，熔断该节点的服务调用快速找出错误信息，避免雪崩效应，并调用服务降级将错误信息返回给用户，当检测到节点正常时会恢复调用链路
• 服务限流:类似于闸机，一秒钟只允许通过xx个，常见的是秒杀等场景下用户一窝蜂涌入导致服务器崩溃;

③服务降级

• 服务器端超时，要进行服务降级给客户端友好提示，避免客户端长时间等待
• 服务器宕机，出错要有兜底方法
• 服务器端正确，80客户端故障，服务降级

操作流程

• @HystrixCommand中指定兜底方法，在该方法出现异常是自动调用xxx兜底方法，同时，在该方法上指定commandProperty来指定超时错误, @EnableHystrix标志在启动类上启动hystrix
• 解决代码膨胀：在业务类上用@DefaultProperties标注defaultFallback全局熔断方法，只对特殊的方法做定制fallback，
• 解决代码耦合：通过openFeign负载均衡，指定这个接口是降级方法接口，实现类里面的方法则是降级方法，fallback的方法和controller中的方法同名，出现故障即可进行调用

conumser模块：项目发起，实名认证300s，生成订单，支付，登录，注册：3s，方法异常fallback

④服务熔断
就是一个服务的依赖链中出现一个故障立马将其干掉，防止它占用当前服务线程和故障蔓延到整个分布式系统，短路后立马给调用放一个fallback，把这个服务进行熔断并快速返回错误信息，预防更大问题的产生，但最厉害的是：当检测到服务链路正常后会自动恢复调用链路
触发机制：开启断路器(类似于保险丝)，一段时间内(3s)请求失败率(10次请求失败6次)达到多少，触发，当超过时间窗口期(3s后)，如果环境恢复正常那么服务也会慢慢恢复正常，短路期间和恢复期间即使请求和服务正常也会报错

8 分布式事物解决之TCC（（补偿事物）

• try:检查资源预留情况并执行业务操作
• confirm：类似于事务中的commit提交，所有的try都成功才执行confirm
• concel:类似于事务中的回滚，回滚逻辑要自己动手写
• TM:事物管理者，需要作为公共组件单独配置，提高重用性。发起全部分支的try，如果其中任何一部分失败都会进行concel，也就是回滚，全部成功才进行confirm也就是提交，如果里面的方法异常会进行重试，需要注意，提交和回滚是从业务代码层面上进行的，而不是通过数据库进行的

9

9 微服务五大组件

• 服务注册中心：既然设计众多的微服务，我肯定要想办法管理起来，把这些微服务注册到服务注册中心进行统一的管理，而以后调用这些服务时直接去注册中心拿即可，为了预防单点故障我们可以搭建多态台Eureka做了一个的服务器集群
• 微服务项目的同一个服务我们可能注册多个，也就是从服务器列表根据名称调用provider，可能拿到一堆3,5个，那么我们怎么对他们协同调用呢 => 我考虑的是ribbon和openFeign对按照不同的算法他们进行负债均衡调用
• 众多微服务难免不出问题，为了避免服务雪崩等级联问题，我考虑使用hystrix进行服务降级、熔断、限流，来保证服务的健壮性
• 微服务中每个配置文件都是互相独立的，所以我考虑设置了服务配置中心nacos，来对模块进行统一的通知与管理，微服务每个服务模块的端口最终是要暴露给浏览器客户端，被用户进行调用的，而每个微服务对应不同的ip和port，这就会在开发和部署时造成很多麻烦，所以通过微服务来统一ip和端口，统一微服务的访问入口，此外，还可以在此处进行安全过滤，流量监控等安全性相关的微服务全局操作