1.什么是SpringCloud？

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包

2.SpringCloud的组成

这就有很多了，我讲几个开发中最重要的
Spring Cloud Eureka：服务注册与发现
Spring Cloud Zuul：服务网关
Spring Cloud Ribbon：客户端负载均衡
Spring Cloud Feign：声明性的Web服务客户端
Spring Cloud Hystrix：断路器
Spring Cloud Confifig：分布式统一配置管理

3.Spring Cloud 和dubbo区别?

（1）服务调用方式：dubbo是RPC , springcloud 是 Rest Api
（2）注册中心：dubbo 是zookeeper ，springcloud是eureka，也可以是zookeeper
（3）服务网关，dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素

4.什么是Eureka？

Eureka作为SpringCloud的服务注册功能服务器，他是服务注册中心，系统中的其他服务使用Eureka的客户端将其连接到Eureka Service中，并且保持心跳，这样工作人员可以通过EurekaService来监控各个微服务是否运行正常。

5.Eureka怎么实现高可用

集群吧，注册多台Eureka，然后把SpringCloud服务互相注册，客户端从Eureka获取信息时，按照Eureka的顺序来访问。

6. 什么是Eureka的自我保护模式

默认情况下，如果Eureka Service在一定时间内没有接收到某个微服务的心跳，Eureka Service会进入自我保护模式，在该模式下Eureka Service会保护服务注册表中的信息，不在删除注册表中的数据，当网络故障恢复后，Eureka Servic 节点会自动退出自我保护模式。

7.Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别

1.ZooKeeper中的节点服务挂了就要选举 在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的， 选举就是改微服务做了集群，必须有一台主其他的都是从
2.Eureka各个节点是平等关系,服务器挂了没关系，只要有一台Eureka就可以保证服务可用，数据都是最新的。 如果查询到的数据并不是最新的，就是因为Eureka的自我保护模式导致的
3.Eureka本质上是一个工程,而ZooKeeper只是一个进程
4.Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪
5.ZooKeeper保证的是CP，Eureka保证的是AP
CAP： C：一致性>Consistency; 取舍：(强一致性、单调一致性、会话一致性、最终一致性、弱一致性) A：可用性>Availability; P：分区容错性>Partition tolerance;

8.谈谈服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“ 扇出 ”（像一把打开的折扇）。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，这就是所谓的” 雪崩效应 “。也就是系统的 高可用 受到了破坏。

9.什么是断路器？

当一个服务调用另外一个服务由于网络原因或者自身原因出现问题，调用者就会等待被调用者的响应，当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）
断路器有三种状态：
打开状态：一段时间内，达到一定的次数无法调用，并且多次监测没有恢复的迹象，断路器完全打开，那么下次请求就不会请求到该服务。
半开状态：短时间内，有恢复迹象，断路器会讲部分请求发给该服务，正常调用时，断路器关闭。
关闭状态：当服务一直处于正常状态，能正常调用。

10.什么是Hystrix?

在分布式系统，我们一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪崩，Hystrix就是这样的一个工具，防雪崩力气，他具有服务降级，服务熔断，服务隔离，监控等一些防止雪崩的技术。

Hystrix有四种防雪崩方式：
服务降级（Fall Back）：假设微服务A要调用的服务B不可用了，需要服务B提供一个兜底的解决方法，而不是让服务A在那里傻等，耗死。不让客户端等待并立刻返回一个友好提示，比如像客户端提示服务器忙，请稍后再试等。哪些情况会触发服务降级呢？比如 程序运行异常 、 超时 、 服务熔断触发服务降级 、 线程池/信号量打满 也会导致服务降级。
服务熔断（Break）：服务熔断就相当于物理上的 熔断保险丝 。类比保险丝达到最大服务访问后，直接拒绝访问，拉闸断电，然后调用服务降级的方法并返回友好提示。
**服务隔离：**隔离服务之间相互影响，线程池/信号量隔离
应用系统会被完全保护起来，即使其中一个服务线程池满了，也不会影响到应用的其他服务。
当引入一个新的客户端的时候，如果发生问题，只会影响新的服务，并不会影响其他服务。
当一个失败的服务恢复正常时，系统会立即恢复正常的性能。
如果我们的应用系统一些参数配置错误，那么线程池的运行状况将会很快被检测出来，如延迟、超时、拒绝等。同时可以通过动态属性实时执行来处理纠正错误的参数配置。
如果服务的性能有变化需要调整，可以通过线程池指标动态属性修改，不会影响其他服务请求。
Hystrix拥有专门的线程池可提供内置的并发功能，可以在同步调用之上构建异步外观模式。
线程池隔离的缺陷：增加了计算的开销，每个业务请求在执行的时候，会涉及请求排队、线程调度、上下文切换等处理
服务监控：在服务发生调用时，会讲每秒请求数，成功请求数等运行指标记录下来

原来的主逻辑如何恢复呢? => 当熔断器打开后，对主逻辑进行熔断之后，Hystrix会启动一个 休眠时间窗 ， 在这个时间窗内，降级逻辑是临时的主逻辑，当休眠时间窗到期，熔断器会进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求能够正常访问，则熔断器会进入闭合状态，从而恢复主逻辑，如果注册请求依然有问题，则熔断器继续保持打开状态，并且休眠时间窗重新计时。

11.SpringCloud Fegin

原理：主程序入口添加了@EnableFeignClients注解开启对FeignClient扫描加载处理。根据Feign Client的开发规范，定义接口并加@FeignClientd注解。
当程序启动时，会进行包扫描，扫描所有@FeignClients的注解的类，并且将这些信息注入Spring IOC容器中，当定义的的Feign接口中的方法被调用时，通过JDK的代理方式，来生成具体的RequestTemplate.
当生成代理时，Feign会为每个接口方法创建一个RequestTemplate对象，该对象封装了HTTP请求需要的全部信息，如请求参数名，请求方法等信息都是在这个过程中确定的。然后RequestTemplate生成Request,然后把Request交给Client去处理，这里指的是Client可以是JDK原生的URLConnection,Apache的HttpClient,也可以是OKhttp，最后Client被封装到LoadBalanceClient类，这个类结合Ribbon负载均衡发起服务之间的调用。

结合工作经验自定义Fegin能力：
启动之后执行生成controller逻辑，通过实现CommandLineRunner注解，然后执行底下的run方法，这是一个模版设计模式，注解handdler,扫描包路径下有关注解的接口，然后构建类的信息，如类名，引入内容，方法列表等元信息，然后执行javacodeHanddler的exc接口，根据元信息生成对应的内容，完善元信息，然后再继续执行javaCompleHanddle的方法，拿到所有的元信息，反射所有的controller类，最后获取defaultListableBeanFactory，defaultListableBeanFactory.registerBeanDefinition 注册每一个bean,反射RequestMappingHandlerMapping的detectHandlerMethods方法，将该类的加入，目的是为了让springmvc能找得到。

12.为什么要从单体应用转到微服务架构

单体应用是指所有的代码和功能都集中在一个应用程序中，而微服务架构则将应用程序拆分成多个小型服务，每个服务都专注于执行一个特定的功能或业务流程。

升级成微服务架构的原因有以下几点：

可扩展性：单体应用通常很难水平扩展，因为它们的所有组件都是紧密耦合的。微服务架构允许您将每个服务分别扩展，从而更容易地满足增长的需求。

灵活性：微服务架构使您可以在不影响其他服务的情况下更轻松地修改和部署单个服务。这样可以提高开发速度和部署频率。

可靠性：由于每个微服务只关注一个功能，因此故障只会影响单个服务而不是整个应用程序。这使得故障排除和修复更加容易。

技术异构性：单体应用通常使用一种编程语言和技术栈，而微服务架构允许您使用不同的语言和技术栈来开发不同的服务。这样可以更好地利用新技术和工具，并避免被锁定在单一技术栈中。

团队协作：微服务架构可以促进团队协作，因为每个服务都是独立的，并且可以由不同的团队来开发和维护。这样可以提高开发效率并减少对其他团队的依赖。

总之，微服务架构是一种强大的架构模式，可以提高应用程序的可扩展性、灵活性、可靠性和团队协作能力，使得应用程序更加易于开发、部署和维护。

13.MQ跟kafka的区别

MQ (Message Queue) 和 Kafka 都是常见的消息队列系统，它们都用于在分布式系统中异步传输消息，但是它们有以下不同之处：

架构设计：Kafka 是分布式发布-订阅消息系统，可以在多个生产者和消费者之间传递消息，而 MQ 通常是点对点传递模式。Kafka使用消息发布-订阅的模型，使得多个消费者可以消费同一组消息，从而实现高可扩展性和高吞吐量。而MQ使用队列模型，生产者把消息放到队列中，消费者从队列中取出消息进行处理。

性能：Kafka 是为高吞吐量和低延迟而设计的，具有非常高的性能和可伸缩性。它通过批量发送消息来优化性能，支持百万级别的消息传输，能够轻松处理大量数据。MQ 通常也具有很高的性能，但是在处理大量数据时可能会出现瓶颈。

数据存储：Kafka 使用基于磁盘的数据存储，允许消息在磁盘上长期存储，并支持消息的随机读取和检索。而 MQ 通常采用内存存储，消息在磁盘上的存储可能会导致性能问题。

数据可靠性：Kafka 对于消息的可靠性有很高的保障。它使用分区和副本机制来确保消息不会丢失，并支持数据备份和恢复。MQ 也有类似的机制来确保消息不会丢失，但是它通常不支持数据备份和恢复。

社区和生态系统：Kafka 拥有一个庞大的社区和生态系统，有许多第三方工具和插件可以与之集成，例如Kafka Connect和Kafka Streams。MQ也拥有自己的社区和生态系统，但是与Kafka相比较小。

总之，Kafka 和 MQ 都是可靠的消息队列系统，它们的设计目标、性能和功能略有不同，选择哪种系统取决于具体的应用场景和需求。如果需要高吞吐量和大量数据的处理，则Kafka是更好的选择；如果需要点对点消息传递和更简单的部署，则MQ可能更适合。