SpringCloud 常见面试题（一）

概念

什么是微服务？你是怎么理解微服务的？

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）,每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

通俗地来讲：

微服务就是一个独立的职责单一的服务应用程序。在 intellij idea 工具里面就是用maven开发的一个个独立的module，具体就是使用springboot 开发的一个小的模块，处理单一专业的业务逻辑，一个模块只做一个事情。

微服务强调的是服务大小，关注的是某一个点，具体解决某一个问题/落地对应的一个服务应用，可以看做是idea 里面一个 module。

微服务有什么好处？

微服务优点很多，但是我们通常说一个东西好肯定会跟另一个东西比较， 通常说微服务好会和单体项目进行比较。以下是微服务相对于单体项目的一些显著好处：

单体项目的缺点：

• 可扩展性受限： 单体应用通常在可扩展性方面受到限制，因为整个应用程序必须一起扩展。这意味着即使只有一个组件需要更多资源，也必须扩展整个应用程序，这可能会导致资源浪费。
• 难以维护和更新： 随着时间的推移，单体应用程序往往变得越来越庞大和复杂，难以理解、维护和更新。每次修改都可能引发意想不到的影响。
• 高风险： 单体应用程序中的一个小错误或故障可能会导致整个应用程序崩溃，因此存在较高的风险。此外，长时间不更新的单体应用可能会受到安全威胁。
• 技术栈限制： 单体应用程序通常使用相同的技术栈，这可能会限制您在项目中使用最新的技术和工具的能力。
• 团队协作复杂： 单体应用程序的所有组件都在一个代码库中，这可能导致开发团队之间的冲突和协作问题，尤其在大型团队中更为突出。

微服务项目的优点：

• 可扩展性： 微服务架构允许您根据需要独立地扩展单个服务，而不必扩展整个应用程序，这提供了更高的可扩展性。
• 灵活性和快速开发： 微服务允许开发团队独立设计、开发和部署服务，这提高了灵活性，允许团队更快地推出新功能和更新。
• 故障隔离和容错性： 单个微服务的故障通常不会影响其他服务，提高了应用程序的容错性，同时更容易识别和解决故障。
• 技术多样性： 微服务允许您选择适合每个服务的最佳技术栈，这有助于充分利用各种技术和工具的优势。
• 独立部署和维护： 微服务可以独立部署和维护，这减少了风险，使团队能够更快速地进行修复和更新。
• 团队协作： 不同团队可以独立工作在不同服务上，这提高了团队的自治和协作能力，减少了冲突。

总的来说，微服务项目通过提供更高的可扩展性、灵活性和容错性，以及更容易管理的部署和维护过程，有助于克服单体应用程序的一些限制和缺点。但请注意，微服务架构也会引入一些新的复杂性，需要更多的管理和监控。

单体应用、SOA 和微服务架构有什么区别

单体应用、SOA和微服务架构都是不同的架构风格，适用于不同的情况。

单体应用像一个整体，所有的功能都打包在一个应用中。这种架构风格容易部署和测试，但随着系统规模的扩大，它的灵活性和可维护性会降低。

SOA是一种面向服务的架构风格，将系统划分为多个独立的服务。这些服务可以通过网络调用，并且可以跨平台、跨语言进行交互。SOA的优点是提供了跨系统的服务复用和松散耦合的交互方式，但实现SOA需要投入大量的工作，包括服务的定义、接口的选择、协议的制定等。

微服务架构进一步将系统划分为多个小型、独立的服务，每个服务都是一个单独的应用程序，可以独立部署、运行和扩展。微服务架构具有更高的灵活性和可维护性，适用于复杂的大型系统，强调服务的自治和独立性。但是，实施微服务架构也需要投入大量的工作，包括服务的定义、通信机制的选择、服务的管理等。

分布式和微服务有什么区别?

分布式系统和微服务架构是两个相关但不同的概念，它们的注重点其实不太一样。

分布式系统：它是由多台计算机或多节点组成的系统，各节点之间通过网络进行通信和协作，共同完成一个或多个共享的任务也就是说分布式的各个节点其实目标是一致的，之所以要分布式只是为了有更好的能力，能更快、更高效地承接任务。比如常见的分布式文件系统、分布式数据库。

微服务：其实是一种服务的架构风格，它主要是为了把一个大而全的服务，拆分成多个可以独立、松耦合的服务单元，为了让这些服务单元可以独立部署、运行、管理比如电商服务拆分成微服务，可以分为商品服务、用户服务、订单服务、库存服务等等

什么是Spring Cloud ？

Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

现在有哪些流行的微服务解决方案？

目前最主流的微服务开源解决方案有三种：

Dubbo：

• Dubbo 是一个高性能、轻量级的 Java 微服务框架，最初由阿里巴巴（Alibaba）开发并于2011年开源。它提供了服务注册与发现、负载均衡、容错、分布式调用等功能，后来一度停止维护，在近两年，又重新开始迭代，并推出了Dubbo3。
• Dubbo 使用基于 RPC（Remote Procedure Call）的通信模型，具有较高的性能和可扩展性。它支持多种传输协议（如TCP、HTTP、Redis）和序列化方式（如JSON、Hessian、Protobuf），可根据需求进行配置。
• Dubbo更多地被认为是一个高性能的RPC（远程过程调用）框架，一些服务治理功能依赖于第三方组件实现，比如使用ZooKeeper、Apollo等等。

Spring Cloud Netflix：

• Spring Cloud Netflix 是 Spring Cloud 的一个子项目，结合了 Netflix 开源的多个组件，但是Netflix自2018年停止维护和更新Netflix OSS项目，包括Eureka、Hystrix等组件，所以Spring Cloud Netflix也逐渐进入了维护模式。
• 该项目包含了许多流行的 Netflix 组件，如Eureka（服务注册与发现）、Ribbon（客户端负载均衡）、Hystrix（断路器）、Zuul（API 网关）等。它们都是高度可扩展的、经过大规模实践验证的微服务组件。

Spring Cloud Alibaba：

• Spring Cloud Alibaba 是 Spring Cloud 的另一个子项目，与阿里巴巴的分布式应用开发框架相关。它提供了一整套与 Alibaba 生态系统集成的解决方案。
• 该项目包括 Nacos（服务注册与发现、配置管理）、Sentinel（流量控制、熔断降级）、RocketMQ（消息队列）等组件，以及与 Alibaba Cloud（阿里云）的集成。它为构建基于 Spring Cloud 的微服务架构提供了丰富的选项。

这三种方案有什么区别：

特点	Dubbo	Spring Cloud Netflix	Spring Cloud Alibaba
开发语言	Java	Java	Java
服务治理	提供完整的服务治理功能	提供部分服务治理功能	提供完整的服务治理功能
服务注册与发现	ZooKeeper/Nacos	Eureka/Consul	Nacos
负载均衡	自带负载均衡策略	Ribbon	Ribbon\Dubbo负载均衡策略
服务调用	RPC方式	RestTemplate/Feign	Feign/RestTemplate/Dubbo
熔断器	Sentinel	Hystrix	Sentinel/Resilience4j
配置中心	Apollo	Spring Cloud Config	Nacos Config
API网关	Higress/APISIX	Zuul/Gateway	Spring Cloud Gateway
分布式事务	Seata	不支持分布式事务	Seata
限流和降级	Sentinel	Hystrix	Sentinel
分布式追踪和监控	Skywalking	Spring Cloud Sleuth + Zipkin	SkyWalking或Sentinel Dashboard
微服务网格	Dubbo Mesh	不支持微服务网格	Service Mesh（Nacos+Dubbo Mesh）
社区活跃度	相对较高	目前较低	相对较高
孵化和成熟度	孵化较早，成熟度较高	成熟度较高	孵化较新，但迅速发展

-在面试中，微服务一般主要讨论的是Spring Cloud Netflix，其次是Spring Cloud Alibaba，Dubbo更多的是作为一个RPC框架来问。

Spring Cloud有什么优势

使用 Spring Boot 开发分布式微服务时，我们面临以下问题

• 与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。
• 服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。
• 冗余-分布式系统中的冗余问题。
• 负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。
• 性能-问题 由于各种运营开销导致的性能问题。
• 部署复杂性-Devops 技能的要求。

说下微服务有哪些组件？

微服务给系统开发带来了一些问题和挑战，如服务调用的复杂性、分布式事务的处理、服务的动态管理等。为了更好地解决这些问题和挑战，各种微服务治理的组件应运而生，充当微服务架构的基石和支撑。

微服务的各个组件和常见实现：

• 注册中心：用于服务的注册与发现，管理微服务的地址信息。常见的实现包括：
  • Spring Cloud Netflix：Eureka、Consul
  • Spring Cloud Alibaba：Nacos
• 配置中心：用于集中管理微服务的配置信息，可以动态修改配置而不需要重启服务。常见的实现包括：
  • Spring Cloud Netflix：Spring Cloud Config
  • Spring Cloud Alibaba：Nacos Config
• 远程调用：用于在不同的微服务之间进行通信和协作。常见的实现保包括：
  • RESTful API：如RestTemplate、Feign
  • RPC（远程过程调用）：如Dubbo、gRPC
• API网关：作为微服务架构的入口，统一暴露服务，并提供路由、负载均衡、安全认证等功能。常见的实现包括：
  • Spring Cloud Netflix：Zuul、Gateway
  • Spring Cloud Alibaba：Gateway、Apisix等
• 分布式事务：保证跨多个微服务的一致性和原子性操作。常见的实现包括：
  • Spring Cloud Alibaba：Seata
• 熔断器：用于防止微服务之间的故障扩散，提高系统的容错能力。常见的实现包括：
  • Spring Cloud Netflix：Hystrix
  • Spring Cloud Alibaba：Sentinel、Resilience4j
• 限流和降级：用于防止微服务过载，对请求进行限制和降级处理。常见的实现包括：
  • Spring Cloud Netflix：Hystrix
  • Spring Cloud Alibaba：Sentinel
• 分布式追踪和监控：用于跟踪和监控微服务的请求流程和性能指标。常见的实现包括：
  • Spring Cloud Netflix：Spring Cloud Sleuth + Zipkin
  • Spring Cloud Alibaba：SkyWalking、Sentinel Dashboard

Spring、SpringMVC、Springboot、 Springcloud 的区别是什么？

Spring

Spring是一个生态体系（也可以说是技术体系），是集大成者，它包含了Spring Framework、Spring Boot、Spring Cloud等。它是一个轻量级控制反转(IOC)和面向切面(AOP)的容器框架，为开发者提供了一个简易的开发方式。

Spring的核心特性思想之一IOC，它实现了容器对Bean对象的管理、降低组件耦合，使各层服务解耦。

Spring的另一个核心特性就是AOP，面向切面编程。面向切面编程需要将程序逻辑分解为称为所谓关注点的不同部分。跨越应用程序多个点的功能称为跨领域问题，这些跨领域问题在概念上与应用程序的业务逻辑分离。有许多常见的例子，如日志记录，声明式事务，安全性，缓存等。

如果说IOC依赖注入可以帮助我们将应用程序对象相互分离，那么AOP可以帮助我们将交叉问题与它们所影响的对象分离。二者目的都是使服务解耦，使开发简易。

当然，除了Spring 的两大核心功能，还有如下这些，如：

• Spring JDBC
• Spring MVC
• Spring ORM
• Spring Test

SpringMVC

Spring与MVC可以更好地解释什么是SpringMVC，MVC为现代web项目开发的一种很常见的模式，简言之C（控制器）将V（视图、用户客户端）与M（模块，业务）分开构成了MVC ，业内常见的MVC模式的开发框架有Struts。

Spring MVC是Spring的一部分，主要用于开发WEB应用和网络接口，它是Spring的一个模块，通过DispatcherServlet, ModelAndView 和View Resolver，让应用开发变得很容易。

SpringBoot

SpringBoot是一套整合了框架的框架。

它的初衷：解决Spring框架配置文件的繁琐、搭建服务的复杂性。

它的设计理念：约定优于配置（convention over configuration）。

基于此理念实现了自动配置，且降低项目搭建的复杂度。

搭建一个接口服务，通过SpringBoot几行代码即可实现。基于Spring Boot，不是说原来的配置没有了，而是Spring Boot有一套默认配置，我们可以把它看做比较通用的约定，而Spring Boot遵循的是约定优于配置原则，同时，如果你需要使用到Spring以往提供的各种复杂但功能强大的配置功能，Spring Boot一样支持。

在Spring Boot中，你会发现引入的所有包都是starter形式，如：

• spring-boot-starter-web-services，针对SOAP Web Services
• spring-boot-starter-web，针对Web应用与网络接口
• spring-boot-starter-jdbc，针对JDBC
• spring-boot-starter-cache，针对缓存支持

Spring Boot是基于 Spring 框架开发的用于开发 Web 应用程序的框架，它帮助开发人员快速搭建和配置一个独立的、可执行的、基于 Spring 的应用程序，从而减少了繁琐和重复的配置工作。

Spring Cloud

Spring Cloud事实上是一整套基于Spring Boot的微服务解决方案。它为开发者提供了很多工具，用于快速构建分布式系统的一些通用模式，例如：配置管理、注册中心、服务发现、限流、网关、链路追踪等。Spring Boot是build anything，而Spring Cloud是coordinate anything，Spring Cloud的每一个微服务解决方案都是基于Spring Boot构建的。

SpringBoot和SpringCloud的区别？

SpringBoot专注于快速方便得开发单个个体微服务。

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、。断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务

SpringBoot可以离开SpringCloud独立使用开发项目， 但是SpringCloud离不开SpringBoot ，属于依赖的关系.

SpringBoot专注于快速、方便得开发单个微服务个体，SpringCloud关注全局的服务治理框架。

Spring Cloud各个微服务之间为什么要用http交互？难道不慢吗？

Spring Cloud是一个为分布式微服务架构构建应用程序的开发工具箱，是Spring Boot的扩展，通过各种微服务组件的集成，极大地简化了微服务应用程序的构建和开发。在分布式系统中，各个微服务之间的通信是非常重要的，而HTTP作为通信协议具有普遍性和可扩展性，是Spring Cloud微服务架构中主流的通信方式。

尽管使用HTTP作为微服务之间的通信协议存在一定的网络开销，但是这种不可避免的网络开销远低于我们所能得到的好处。使用HTTP通信可以实现松耦合和异步通信，微服务之间可以彼此独立地进行开发和测试，单个微服务的故障不会影响整个系统的运行，也可以支持各种不同的技术栈之间的互操作性。

另外，使用HTTP作为通信协议还具有优秀的可扩展性。HTTP协议定义了不同的请求方法（例如 GET、POST、DELETE 等），不同请求方法的扩展格式也很灵活，可以用来传递各种类型的数据和格式，同时HTTP协议支持缓存，减少重复性的数据传输和带宽开销。

当然，为了提高微服务之间的通信效率，我们也可以通过一些优化手段来减少HTTP协议的网络开销。例如，使用数据压缩和缓存技术来压缩和缓存请求和响应，减少网络数据传输量和响应时间；使用负载均衡技术来合理地分配请求和响应，避免单个微服务出现性能瓶颈；使用高速缓存技术来缓存请求和响应，避免重复的请求和响应等等。

因此，Spring Cloud各个微服务之间使用HTTP交互是一个比较成熟的选择。虽然它可能存在一些网络开销，但是在实际应用中，这种开销是可以优化和控制的，甚至可以提高系统的可扩展性和可靠性。

注册中心

注册中心是用来干什么的？

注册中心是用来管理和维护分布式系统中各个服务的地址和元数据的组件。它主要用于实现服务发现和服务注册功能。

总结一下注册中心的作用：

• 服务注册：各个服务在启动时向注册中心注册自己的网络地址、服务实例信息和其他相关元数据。这样，其他服务就可以通过注册中心获取到当前可用的服务列表。
• 服务发现：客户端通过向注册中心查询特定服务的注册信息，获得可用的服务实例列表。这样客户端就可以根据需要选择合适的服务进行调用，实现了服务间的解耦。
• 负载均衡：注册中心可以对同一服务的多个实例进行负载均衡，将请求分发到不同的实例上，提高整体的系统性能和可用性。
• 故障恢复：注册中心能够监测和检测服务的状态，当服务实例发生故障或下线时，可以及时更新注册信息，从而保证服务能够正常工作。
• 服务治理：通过注册中心可以进行服务的配置管理、动态扩缩容、服务路由、灰度发布等操作，实现对服务的动态管理和控制。

为什么需要服务注册发现?

在分布式系统中，服务的数量通常会有很多，而且规模还不是一般地大，与此同时，服务的部署和变化也会很频繁，因此，如果要依赖人工去维护这些服务的关系，实现服务的管理以及调用就会变得非常困难。

服务注册与发现的作用就是为了解决这个问题，它通过注册中心来维护服务生产者以及服务消费者之间的关系。当服务启动之后，其就会向注册中心注册自己的信息，比如服务名称、服务端口、服务的P地址等，当服务消费者需要调用某个服务的时候，它会向注册中心发起查询请求，获取对应服务的信息，然后向生产者服务发送请求。如果一些服务上线或者下线，注册中心都可以主动通知消费者，这就动态地实现了服务的上下线，在高峰期加机器，低峰期减机器，减少了管理的成本，十分方便。也可以方便实现服务的监控、管理等等。

SpringCloud可以选择哪些注册中心？

SpringCloud可以与多种注册中心进行集成，常见的注册中心包括：

• Eureka：Eureka 是 Netflix 开源的服务发现框架，具有高可用、弹性、可扩展等特点，并与 Spring Cloud 集成良好，已闭源。ap
• Consul：Consul 是一种分布式服务发现和配置管理系统，由 HashiCorp 开发。它提供了服务注册、服务发现、健康检查、键值存储等功能，并支持多数据中心部署。c/ap
• ZooKeeper：ZooKeeper 是 Apache 基金会开源的分布式协调服务，可以用作服务注册中心。它具有高可用、一致性、可靠性等特点。 cp
• Nacos：Nacos 是阿里巴巴开源的一个动态服务发现、配置管理和服务管理平台。它提供了服务注册和发现、配置管理、动态 DNS 服务等功能。 ap
• etcd：etcd 是 CoreOS 开源的一种分布式键值存储系统，可以被用作服务注册中心。它具有高可用、强一致性、分布式复制等特性。 cp

什么是 Eureka?

Eureka 是一个 Spring Cloud Netflix 的一款老牌注册中心，设计用于实现云端部署微服务架构中的服务注册与发现功能。

在技术领域，特别是分布式系统中，Eureka作为一个基于 RESTFul 的服务，主要职责包括:

• 服务注册：允许服务实例向 EurekaServer 注册自己的信息。这样，每个服务实例都能让 Eureka Server 获取到自身服务以及地址等信息。
• 服务发现：Eureka客户端可以从 Eureka server 查询到注册的服务实例信息，进而实现客户端的软负载均像和故障转移。服务消费者可以查询 Eureka Sener 获取到提供某一服务的所有服务实例列表，然后根据策略选择一个实例进行通信。
• 健康检查：Eureka 通过心跳机制监控服务实例的状态，确保服务列表的时效性和)准确性，如果某个服务实例宕机或天法响应，Eureka Senver将从注册表中移除该实例，避免了将流量导向不可用的服务(默认 90s)。
• 高可用性：Eureka 通过部署多个 Eureka Server 实例并相互复制注册信息，可以构建高可用的服务注册中心集群，提高系统的整体稳定性。

在 Spring Cloud 中，Eureka 被集成作为服务注册与服务发现的核心组件,通过 @EnableEurekaServer 和 @EnableEurekaClient 注解可以轻松实现服务注册中心或服务客户端

Eureka 在2020年后 Netflix 宣布不再积极维护，但它仍然是许多现有系统中服务注册中心的实现方案，并目有社区进行维护，

Spring Cloud如何实现服务的注册?

服务发布时，指定对应的服务名，将服务注册到 注册中心(Eureka 、Zookeeper)。

注册中心加@EnableEurekaServer，服务用@EnableDiscoveryClient，然后用ribbon或feign进行服务直接的调用发现。

说下Eureka、ZooKeeper、Nacos的区别？

特性	Eureka	ZooKeeper	Nacos
开发公司	Netflix	Apache 基金会	阿里巴巴
CAP	AP（可用性和分区容忍性）	CP（一致性和分区容忍性）	既支持AP，也支持CP
功能	服务注册与发现	分布式协调、配置管理、分布式锁	服务注册与发现、配置管理、服务管理
定位	适用于构建基于 HTTP 的微服务架构	通用的分布式协调服务框架	适用于微服务和云原生应用
访问协议	HTTP	TCP	HTTP/DNS
自我保护	支持	-	支持
数据存储	内嵌数据库、多个实例形成集群	ACID 特性的分布式文件系统 ZAB 协议	内嵌数据库、MySQL 等
健康检查	Client Beat	Keep Alive	TCP/HTTP/MYSQL/Client Beat
特点	简单易用、自我保护机制	高性能、强一致性	动态配置管理、流量管理、灰度发布等

可以看到Eureka和ZooKeeper的最大区别是一个支持AP，一个支持CP，Nacos既支持既支持AP，也支持CP。

关于CAP相关理论和概念可以看这篇文章：CAPl理论

• Nacos除了作为注册中心外，还提供了配置管理、服务发现和事件通知等功能。Nacos默认情况下采用AP架构保证服务可用性，CP架构底层采用Raft协议保证数据的一致性。Nacos适合作为微服务注册中心和配置管理中心，支持快速发现、配置管理和服务治理等功能。
• Eureka是只提供注册中心功能的工具，它的设计理念是AP，即保证服务的可用性，不保证一致性。Eureka的各个节点之间相互注册，只要有一台Eureka节点存在，整个微服务就可以通讯。
• 而Zookeeper相比前两者，除了注册中心的功能，还提供了分布式协调服务，比如通知、公告、配置管理等。Zookeeper采用CP设计，可以保证数据的一致性，但是牺牲了一部分服务的可用性。Zookeeper适用于需要分布式协调服务的场景，如配置管理、命名服务等。

请说说Eureka和zookeeper 的区别？

Zookeeper保证了CP，Eureka保证了AP。

CAP理论详情请看CAP理论

A：高可用

C：一致性

P：分区容错性

1. 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。也就是说，服务注册功能对高可用性要求比较高，但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。
2. Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：
   1. Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
   2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
   3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点。

因此，Eureka可以很好地应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪

Nacos和Eureka的区别

Nacos和Eureka整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

• Nacos与eureka的共同点
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
• Nacos与Eureka的区别
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

Eureka实现原理了解吗？

Eureka的实现原理，大概可以从这几个方面来看：

1. 服务注册与发现: 当一个服务实例启动时，它会向Eureka Server发送注册请求，将自己的信息注册到注册中心。Eureka Server会将这些信息保存在内存中，并提供REST接口供其他服务查询。服务消费者可以通过查询服务实例列表来获取可用的服务提供者实例，从而实现服务的发现。
2. 服务健康检查: Eureka通过心跳机制来检测服务实例的健康状态。服务实例会定期向Eureka Server发送心跳，也就是续约，以表明自己的存活状态。如果Eureka Server在一定时间内没有收到某个服务实例的心跳，则会将其标记为不可用，并从服务列表中移除，下线实例。
3. 服务负载均衡: Eureka客户端在调用其他服务时，会从本地缓存中获取服务的注册信息。如果缓存中没有对应的信息，则会向Eureka Server发送查询请求。Eureka Server会返回一个可用的服务实例列表给客户端，客户端可以使用负载均衡算法选择其中一个进行调用。

其它的注册中心，如Nacos、Consul等等，在服务注册和发现上，实现原理都是大同小异。

Eureka Server怎么保证高可用？

Eureka Server保证高可用，主要通过这三个方面来实现：

• 多实例部署: 通过将多个Eureka Server实例部署在不同的节点上，可以实现高可用性。当其中一个实例发生故障时，其他实例仍然可以提供服务，并保持注册信息的一致性。
• 服务注册信息的复制: 当一个服务实例向Eureka Server注册时，每个Eureka Server实例都会复制其他实例的注册信息，以保持数据的一致性。当某个Eureka Server实例发生故障时，其他实例可以接管其工作，保证整个系统的正常运行。
• 自我保护机制: Eureka还具有自我保护机制。当Eureka Server节点在一定时间内没有接收到心跳时，它会进入自我保护模式。在自我保护模式下，Eureka Server不再剔除注册表中的服务实例，以保护现有的注册信息。这样可以防止由于网络抖动或其他原因导致的误剔除，进一步提高系统的稳定性。

eureka自我保护机制是什么?

什么是自我保护模式？

1. 自我保护的条件：一般情况下，微服务在 Eureka 上注册后，会每 30 秒发送心跳包，Eureka 通过心跳来判断服务是否健康，同时会定期删除超过 90 秒没有发送心跳服务。
2. 有两种情况会导致 Eureka Server 收不到微服务的心跳
   1. 是微服务自身的原因
   2. 是微服务与 Eureka 之间的网络故障

通常(微服务的自身的故障关闭)只会导致个别服务出现故障，一般不会出现大面积故障，而(网络故障)通常会导致 Eureka Server 在短时间内无法收到大批心跳。考虑到这个区别，Eureka 设置了一个阀值，当判断挂掉的服务的数量超过阀值时，Eureka Server 认为很大程度上出现了网络故障，将不再删除心跳过期的服务。

3. 那么这个阀值是多少呢？

15 分钟之内是否低于 85%；Eureka Server 在运行期间，会统计心跳失败的比例在 15 分钟内是否低于 85%,这种算法叫做 Eureka Server 的自我保护模式。

为什么要自我保护？

1. 因为同时保留"好数据"与"坏数据"总比丢掉任何数据要更好，当网络故障恢复后，这个 Eureka 节点会退出"自我保护模式"。
2. Eureka 还有客户端缓存功能(也就是微服务的缓存功能)。即便 Eureka 集群中所有节点都宕机失效，微服务的 Provider 和 Consumer都能正常通信。
3. 微服务的负载均衡策略会自动剔除死亡的微服务节点。

Consul是什么?

Consul 是 HasiCorp 公司用 Golang 开发的一款开源的服务注册中心以及配置中心，提供了服务注册与发现、健康检查、KV 存储、多数据中心支持、DNS 和 HTTP API 接口等功能，而且提供了可视化控制台用于操作。

Consul 的优点有很多

• 基于 Raft 协议，比较简洁
• 支持简单检查，同时支持 HTTP 和 DNS 协议
• 支持跨数据中心的 WAN 集群
• 提供了跨平台的图形化界面，支持 Windows、Linux、Mac 等系统

单体服务拆成多个微服务，这些服务之间如何自动发现彼此?具体原理是什么?

这些微服务之间一般需要借助注册中心，然后通过服务发现机制定位彼此。

核心原理是：服务启动时将自己的地址和元数据注册到注册中心(Nacos、Consul)，调用方通过注册中心动态获取可用服务实例列表，然后基于负载均衡策略(如轮询、随机)发起请求。

整个过程还得依赖心跳检测确保实例状态实时更新，例如老服务的下线，新服务的上线。

每个微服务启动后，会向注册中心(如Nacos、Consul)发送自己的信息(IP、端口、服务名等)，告诉注册中心"我上线了"

注册中心会存储所有已注册服务的信息，并通过心跳检测(如每隔5秒发一次"我还活着")监控服务状态，若某服务超过一定时间没心跳，注册中心会标记它为"下线"

当服务 A需要调用服务B时，会向注册中心查询服务 B的所有可用实例(IP+端口)，然后从这些实例中选一个(如轮询、随机)发起请求。