本期主题：
3天掌握《Java编程与面试2024》的黄金章节技能点，即第3章，微服务配置篇25问。
……
第三章【微服务配置篇：SpringBoot+SpringCloud】（25问）
具体问题如下：
一、什么是SpringBoot？
二、SpringBoot常用的starter？
三、SpringBoot自动配置原理？
四、SpringBoot starter工作原理？
五、SpringBoot的优点？
六、SpringCloud解决了哪些问题？
七、SpringBoot与SpringCloud的关系？
八、微服务是如何调用的？
九、微服务调用的原理？
十、微服务如何实现负载均衡？
十一、配置详解？
十二、Eureka？
十三、Eureka的高可用配置？
十四、谈谈微服务？
十五、微服务和SOA的关系？
十六、SpringCoud是如何实现服务注册与发现的？
十七、Ribbon和Feign的区别？
十八、雪崩效应？
十九、熔断机制？
二十、Eureka的基础架构？
二十一、Eureka和Zookeeper都可以提供服务注册与发现的功能，而两者的区别是？
二十二、CAP理论？
二十三、Ribbon和Nginx的区别？
二十四、服务注册与发现？
二十五、微服务的负载均衡，为何用？怎么用？
......
下面，让我来具体说说这25个问题吧！
一、什么是SpringBoot？
1、用来简化spring初始搭建，以及开发过程中使用特定的方式，进行配置(properties或者yml文件)。
2、创建独立的Spring应用程序main方法运行。
3、嵌入Tomcat无需部署war包，直接打成jar包，用nohup java -jar–&启动就好。
4、简化了maven的配置。
5、自动配置Spring添加对应的starter自动化配置。
...
下面，让我来具体说说…
SpringBoot是由Pivotal团队提供的全新框架…
旨在简化新Spring应用的初始搭建，以及开发过程。
从根本上讲，SpringBoot是一个基于Spring框架的开源框架…
它提供了一套开发工具和约定，使得构建独立、可执行的、生产级别的Spring应用，变得更加容易。
SpringBoot具有4大核心特性，即自动化配置，外部化配置，内嵌容器，健康检查和监控。
1、自动化配置
通过自动配置机制，根据项目中引入的依赖和约定…
自动配置应用程序中的各种组件和功能。
这减少了开发者，手动编写大量XML或注解配置的工作量，降低了出错的可能性。
2、外部化配置
支持将配置信息从代码中分离出来，使开发者能够在不同环境下…
灵活切换配置参数，例如使用不同的数据库或消息队列。
3、内嵌容器
支持内置的Servlet容器（如Tomcat、Jetty、Uow等）…
这意味着，你可以将应用程序，打包为一个可执行的JAR文件…
并直接运行，无需单独安装和配置外部容器。
4、健康检查和监控
提供了健康检查和监控功能，可以监控应用程序的运行状态和性能指标…
确保应用程序的稳定性和可靠性。
此外…
SpringBoot还致力于提供快速的应用开发体验，并使得开发者…
能够更专注于业务逻辑的实现，而不是花费大量时间在配置和部署上。
因此…
无论是Web应用、RESTful服务还是批处理作业，SpringBoot都能帮助开发者…
更快速、更便捷地构建及部署Java应用程序，提高开发效率和项目的可维护性。
划重点：
最新版本的SpringBoot（截至2024年4月）是3.2.x系列，提供了更多的特性和改进…
如系统要求提升、安全性增强、虚拟线程支持以及Jakarta EE迁移等。
这些新特性和改进，使得SpringBoot在构建现代、高效和安全的Java应用程序方面，更加强大和灵活。
…
二、SpringBoot常用的starter？
1、spring-boot-starter-web(嵌入Tomcat和web开发需要的servlet和jsp支持)
2、spring-boot-starter-data-jpa(数据库支持)
3、spring-boot-starter-data-Redis(Redis支持)
4、spring-boot-starter-data-solr(solr搜索应用框架支持)
5、mybatis-spring-boot-starter(第三方mybatis集成starter)
…
三、SpringBoot自动配置原理？
1、@Eofiguration这个注解会“猜“你将如何配置spring，前提是你已经添加了jar依赖项。
如果spring-boot-starter-web已经添加Tomcat和SpringMVC…
这个注释，就会自动假设您在开发一个web应用程序，并添加相应的Spring配置；
会自动去maven中读取每个starter中的spring.factories文件；
该文件里，配置了所有需要被创建spring容器中bean。
2、在main方法中，加上注解@SpringBootApplication和@Eofiguration。
…
四、SpringBoot starter工作原理？
1、SpringBoot在启动时，扫描项目依赖的jar包，寻找包含spring.factories文件的jar。
2、根据spring.factories，配置加载Autofigure。
3、根据@ditional注解的条件，进行自动配置，并将bean注入到Spring text。
…
五、SpringBoot的优点？
1、减少开发、测试时间和努力。
2、使用Javafig有助于避免使用XML。
3、避免大量的maven导入和各种版本冲突。
4、提供意见发展方法，
5、通过提供默认值快速开始开发。
6、没有单独的web服务器需要...
这就意味着，不再需要启动Tomcat、Glassfish，或其它任何东西。
7、需要更少的配置，因为没有web.xml文件。
只需添加用@figuration注释的类，然后添加用@Bean注释的方法…
Spring将自动加载对象，并像以前一样对其进行管理。
甚至可以将@Autowired添加到bean方法中，以使用Spring自动装入需要的依赖关系中。
…
六、SpringCloud解决了哪些问题？
配置管理（注册中心eureka、zk）…
服务发现、服务注册、断路器、路由策略、全局锁、分布式会话…
客户端调用、接口网关（zuul）、服务管理系统。
下面，让我来具体说说…
Spring Cloud主要解决了，在构建微服务架构时，面临的一系列问题。
主要有6个，即服务注册与发现，配置管理，负载均衡，熔断与降级，服务拆分与治理，生态系统丰富。
具体来说，它提供了以下关键解决方案：
1、服务注册与发现
通过集成服务注册中心（如Eureka、sul等）…
Spring Cloud使得微服务之间，能够自动注册和发现彼此…
从而实现了服务之间的无缝通信。
这大大简化了，服务之间的调用过程，提高了系统的可维护性和可扩展性。
2、配置管理
Spring Cloud fig提供了集中式的配置管理功能…
使得开发者，可以方便地管理所有微服务的配置信息。
通过动态更新和版本控制，它确保了配置的一致性和可维护性，降低了因配置错误导致的问题。
3、负载均衡
Spring Cloud提供了多种负载均衡器（如Ribbon、Spring Cloud LoadBalancer等）…
能够在服务消费者之间分配请求，确保每个服务实例，都能得到合理的负载。
这有助于，提高系统的可用性和性能，避免单点故障。
4、熔断与降级
通过集成Hystrix等组件，Spring Cloud实现了熔断和降级机制。
当某个服务，出现故障或响应过慢时…
熔断器会快速失败调用，避免整个系统崩溃。
同时，降级机制，可以在服务不可用时，提供备选方案，确保系统的稳定运行。
5、服务拆分与治理
Spring Cloud支持微服务的细粒度拆分，使得开发者，能够更灵活地设计系统架构。
同时，它提供了服务治理功能，如流量控制、熔断隔离等等…
帮助开发者，更好地管理和维护微服务集群。
6、生态系统丰富
Spring Cloud拥有庞大的生态系统，包括许多开源项目和第三方库。
这些库，可以帮助开发者，更容易地构建各种类型的微服务，如API网关、认证中心、监控中心等。
总的来说：
Spring Cloud通过提供一系列工具和组件…
简化了微服务的开发、部署和管理过程，降低了构建分布式系统的复杂性。
这使得开发者，能够更专注于，业务逻辑的实现，提高开发效率和质量。
…
七、SpringBoot与SpringCloud的关系？
1、SpringBoot简化了xml配置，快速整合框架。
2、Springcloud是一套微服务解决方案—RPC远程调用。
3、关于SpringCloud依赖与SpringBoot（web组件用的SpringMVC），为什么Springcloud会依赖与SpringBoot？
因为SpringCloud写接口就是SpringMVC接口。
4、SpringBootproperties和yml中可以使用${random}设置一些随机值。
…
下面，让我来具体说说…
SpringBoot与SpringCloud的关系可以被视为一种相辅相成、互为补充的协作关系。
具体来说，它们之间的关系主要体现在3个方面，即基础与扩展，互补与协同，依赖与独立。
1、基础与扩展
SpringBoot为开发者，提供了快速构建Spring应用程序的基础能力…
它注重于简化配置、内嵌服务器以及自动配置等特性；
使得开发者，能够更快速地启动和运行单个Spring应用程序。
而SpringCloud，则是在SpringBoot的基础上…
提供了构建分布式系统和微服务架构所需的工具和框架，它关注于全局的微服务协调整理和治理。
2、互补与协同
SpringBoot虽然能够快速构建单个微服务…
但对于微服务之间的协调、配置管理、服务发现等问题，并未提供完整的解决方案。
而SpringCloud，则通过提供一系列的功能组件…
如配置中心、服务发现、断路器、路由等，来弥补SpringBoot在这些方面的不足。
这使得开发者，能够利用SpringBoot快速构建微服务个体…
再利用SpringCloud，将这些微服务整合并管理起来，形成一个完整的微服务架构。
3、依赖与独立
虽然SpringCloud依赖于SpringBoot作为其基础…
但SpringBoot本身并不需要SpringCloud就可以独立使用。
这意味着开发者，可以根据项目的实际需求，选择只使用SpringBoot来构建简单的Spring应用程序…
或者结合使用SpringBoot和SpringCloud来构建复杂的微服务架构。
综上所述：
SpringBoot与SpringCloud之间的关系是一种基础与扩展、互补与协同的关系。
它们各自具有独特的功能和优势，但又能够相互协作…
共同为开发者提供构建高效、稳定、可扩展的分布式系统，及微服务架构的能力。
…
八、微服务是如何调用的？
微服务的调用，主要依赖于服务之间的通信机制。
具体实现方式会根据，所选择的通信协议和框架有所不同，但大致流程是相似的。
微服务调用三步走如下：
首先…
服务消费者（即发起调用的微服务）会通过某种机制获取到服务提供者（即被调用的微服务）的地址信息。
这种机制可以是服务注册与发现中心…
如Eureka、sul或Nacos等；
也可以是静态配置，如直接在配置文件中指定服务地址。
获取到服务地址后，服务消费者，会根据选定的通信协议和框架来构建请求。
常见的通信协议包括HTTP、gRPC、Thrift等，而框架则可能是Spring Cloud、Dubbo等。
例如，如果使用HTTP协议和Spring Cloud框架，服务消费者可能会使用RestTemplate或Webt来构建HTTP请求。
接下来…
服务消费者，会发送请求到服务提供者。
这个过程可能涉及到网络传输、序列化与反序列化等步骤。
网络传输，负责将请求，从服务消费者发送到服务提供者…
而序列化与反序列化，则负责将请求对象，转换为可以在网络上传输的格式，并在接收端，恢复为原始对象。
服务提供者收到请求后，会进行相应的业务处理，并返回结果给服务消费者。
这个过程，同样涉及到网络传输、序列化与反序列化等步骤。
最后…
服务消费者，接收到服务提供者返回的结果，根据需要进行相应的处理。
这样，一个完整的微服务调用过程，就完成了。
在整个过程中，为了确保调用的可靠性和稳定性，可能还会涉及到一些额外的机制…
如超时处理、重试机制、熔断器等等。
这些机制可以在网络故障、服务不可用等情况下，提供一定的容错能力，保证系统的稳定性和可用性。
总的来说：
微服务的调用，是一个涉及到服务发现、通信协议、网络传输、序列化与反序列化等多个步骤的复杂过程。
在设计和实现微服务调用时，我们需要根据具体的业务需求和技术选型，来进行综合考虑和权衡。
…
九、微服务调用的原理？
微服务调用的原理，其实主要基于分布式系统的设计理念。
简单来说，每个微服务都是一个独立的、可独立部署的服务，它们之间通过轻量级的通信机制进行交互。
一、首先…
微服务之间需要有一种机制，来发现彼此的位置。
这通常通过服务注册与发现机制来实现的。
例如使用服务注册中心，如sul、Eureka或Nacos等等。
服务提供方，会将自己的地址，注册到注册中心…
服务调用方，则通过注册中心，查找需要调用的服务的地址。
二、其次…
在微服务调用时，为了实现高可用性和水平扩展，通常会使用负载均衡技术。
负载均衡器，可以将请求分发到多个服务实例上，从而均衡负载，提高系统的吞吐量和稳定性。
在实际调用过程中，微服务之间通常通过HTTP、RPC或消息队列等轻量级通信协议进行通信。
这种通信方式，保证了服务之间的松耦合，使得服务可以独立地升级和扩展，而不会影响到其他服务。
三、此外…
为了保证数据的独立性和隔离性，每个微服务，通常会有自己的独立数据库或数据存储。
这样，当某个服务的数据结构或存储方式需要变更时…
只需要修改该服务即可，不会影响到其他服务。
四、最后…
自动化部署和运维也是微服务调用的重要一环。
通过容器化技术（如Docker）和自动化工具（如Kuberes）…
可以实现微服务的快速部署和管理，提高了开发和运维的效率。
总的来说：
微服务调用的原理，就是通过服务注册与发现、负载均衡、轻量级通信、独立数据库以及自动化部署和运维等技术手段…
实现各个微服务之间的解耦、独立部署和扩展，从而构建出高效、稳定、灵活的分布式系统。
…
十、微服务如何实现负载均衡？
微服务实现负载均衡的方式是多种多样的，这主要取决于具体的业务场景和技术选型。
常见负载均衡实现方式有4种，即通过硬件负载均衡器实现，使用软件负载均衡器实现，基于服务注册与发现机制的负载均衡实现，通过容器编排工具实现。
下面，让我来具体说说…
一、通过硬件负载均衡器实现
硬件负载均衡器通常位于网络的前端，接收来自客户端的请求…
然后根据预设的策略，将请求分发到不同的微服务实例上。
这种方式，具有较高的性能和稳定性，但需要额外的硬件设备投入。
二、使用软件负载均衡器实现
软件负载均衡器，通常集成在微服务框架或中间件中，如Nginx、HAProxy等。
这些软件，可以通过配置，实现请求的分发和路由，支持更灵活的负载均衡策略。
三、基于服务注册与发现机制的负载均衡实现
这也是常见的实现方式。
服务提供者，将自己的地址注册到注册中心…
服务消费者，通过注册中心获取服务提供者的地址列表；
然后根据负载均衡策略，选择一个进行调用。
这种方式可以实现服务的动态发现和调用，对服务的扩展和容错处理具有较好的支持。
在具体实现上，负载均衡策略也是多种多样的。
常见的策略包括轮询、随机、最少连接数等。
1、轮询策略，将请求依次分发给各个服务实例；
2、随机策略，则随机选择一个服务实例进行调用；
3、最少连接数策略，则根据服务实例当前的连接数进行选择，以实现负载均衡。
四、通过容器编排工具实现
随着容器化技术的发展，容器编排工具如Kuberes，也提供了强大的负载均衡能力。
通过Kuberes的Service资源，可以方便地实现微服务的自动发现和负载均衡。
总的来说：
微服务实现负载均衡的方式是多种多样的…
我们需要根据具体的业务场景和技术选型进行选择和配置。
同时，负载均衡策略的选择，也需要根据实际需求和系统特性进行权衡和调整，以达到最佳的负载均衡效果。
…
十一、配置详解？
1、eureka.t.register-with-eureka：
是否向注册中心注册自己，注册为true反之为false。
2、eureka.t.fetch-registry：
是否需要去检索服务，检索为true反之为false。
3、eureka.t.serviceUrl.defaultZone :
指定服务注册中心的地址。
...
十二、Eureka？
1、Eureka可分为三个角色：
服务发现者、服务注册者、注册发现中心。
但是这三个角色，并不和实际部署的模型，是一对一的关系。
2、所有的网络通信，都是基于http(s)协议的。
3、Eureka和AWS是紧密结合的，无论是配置还是源码...
比如Region、zone…...
Region可以通过配置文件进行配置，如果不配置默认使用us-east-1。
同样Zone也可以配置，若不配置默认使用defaultZone。
...
十三、Eureka的高可用配置？
Eureka Server的高可用，实际上就是将自己作为服务向其它服务注册中心注册自己。
这样就可以形成一组互相注册的服务注册中心...
以实现服务清单的互相同步，达到高可用效果。
...
十四、谈谈微服务？
以前所有的代码，都放在同一个工程中，部署在同一个服务器，这就造成了同一项目的不同模块、不同功能互相抢占资源...
微服务，就是将工程根据不同的业务规则，拆分成微服务，部署在不同的服务器上，实现服务之间相互调用。
实现Java微服务的有Dubbo(只能用来做微服务)...
SpringCloud(提供了服务的发现、断路器等)。
微服务的7个特点：
1、按业务划分为一个独立运行的程序，即服务单元；
2、服务之间通过HTTP协议相互通信；
3、自动化部署；
4、可以用不同的编程语言；
5、可以用不同的存储技术；
6、服务集中化管理；
7、微服务是一个分布式系统。
微服务的6点优势：
1、将一个复杂的业务拆分为若干小的业务，将复杂的业务简单化。
新人只需要了解它所接管的服务的代码，这就减少了新人的学习成本。
2、由于微服务是分布式服务，服务于服务之间没有任何耦合。
微服务系统的微服务单元，具有很强的横向拓展能力。
3、服务与服务之间，采用HTTP网络通信协议来通信...
单个服务内部高度耦合，服务与服务之间完全独立，无耦合。
这使得微服务，可以采用任何的开发语言和技术来实现，提高开发效率、降低开发成本。
4、微服务是按照业务进行拆分的，并有坚实的服务边界...
若要重写某一业务代码，不需了解所以业务，重写简单。
5、微服务的每个服务单元是独立部署的...
即独立运行在某个进程中，微服务的修改和部署，对其它服务没有影响。
6、微服务在CAP理论中，采用的AP架构，具有高可用分区容错特点。
高可用主要体现在系统7x24不间断服务...
它要求系统有大量的服务器集群，从而提高系统的负载能力。
分区容错也使得系统更加健壮。
微服务的4点不足：
1、微服务的复杂度
构建一个微服务比较复杂，服务与服务之间，通过HTTP协议或其它消息传递机制通信。
开发者要选出最佳的通信机制，并解决网络服务差时，带来的风险。
2、分布式事物
将事物分成多阶段提交，如果一阶段某一节点失败，仍会导致数据不正确。
如果事物涉及的节点很多，某一节点的网络出现异常...
会导致整个事务处于阻塞状态，大大降低数据库的性能。
3、服务划分
将一个完整的系统，拆分成很多个服务，是一件非常困难的事...
因为这涉及了具体的业务场景。
4、服务部署
最佳部署容器Docker。
...
十五、微服务和SOA的关系？
微服务相对于和ESB联系在一起的SOA，轻便敏捷得多...
微服务，将复杂的业务组件化，也是一种面向服务思想的体现。
对于微服务来说，它是SOA的一种体现，但是它比ESB实现的SOA，更加轻便、敏捷和简单。
...
十六、SpringCoud是如何实现服务注册与发现的？
服务发布时，指定对应的服务名(IP地址和端口号)，将服务注册到注册中心(eureka和zookeeper)...
但是这一切是SpringCloud自动实现的；
只需要在SpringBoot的启动类上，加上@EnableDisscoveryt注解。
同一服务修改端口，就可以启动多个实例调用方法：
传递服务名称，通过注册中心获取所有的可用实例...
通过负载均衡策略(Ribbon和Feign)调用对应的服务。
...
十七、Ribbon和Feign的区别？
两者有3点具体区别，即启动类使用的注解不同，服务的指定位置不同，调用方式不同。
Ribbon添加的maven依赖是spring-starter-ribbon。
使用@Ribbo(value=“服务名称”)，使用RestTemplate调用远程服务对应的方法。
Feign添加的maven依赖是spring-starter-feign...
服务提供方提供对外接口，调用方使用，在接口上使用Feig(“指定服务名”)。
3点具体区别：
1、启动类使用的注解不同
Ribbon使用的是@Ribbo，Feign使用的是@EnableFeigs。
2、服务的指定位置不同
Ribbon是在@Ribbo注解上声明。
Feign则是在定义抽象方法的接口中使用@Feig声明。
3、调用方式不同
Ribbon需要自己构建http请求，模拟http请求...
然后使用RestTemplate发送给其它服务，步骤比较繁琐。
而Feign，则是在Ribbon的基础上进行了一次改进，采用接口调用的方式...
将需要调用的其它服务的方法，定义成抽象方法即可...
不需要自己构建http请求。
不过要注意的是，抽象方法的注解、方法签名，要和提供方的完全一致。
...
十八、雪崩效应？
分布式系统中的服务通信，依赖于网络...
网络不好，必然会对分布式系统带来很大的影响。
在分布式系统中，服务之间相互依赖，即...
如果一个服务之间出现了故障或者网络延迟，在高并发的情况下...
会导致线程阻塞，在很短的时间内，该服务的线程资源会消耗殆尽，最终使得该服务不可用。
由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。
为了防止此类事件的发生，分布式系统必然要采取相应的措施，如熔断机制（SpringCloud采用的是Hystrix）。
...
十九、熔断机制？
1、服务故障则开启熔断器
当一个服务出现故障时，请求失败次数超过设定的阀值（默认50）之后...
该服务就会开启熔断器，之后该服务就不进行任何业务逻辑操作，执行快速失败，直接返回请求失败的信息。
其它依赖于该服务的服务，就不会因为得不到响应而造成线程阻塞。
这是除了该服务，以及依赖于该服务的部分功能不可用外，其它功能正常。
2、熔断器的自我修复机制
当一个服务熔断后，经过一段时间（5s）半打开熔断器。
半打开的熔断器，会检查一部分请求（只能有一个请求）是否正常...
其它请求执行快速失败；
检查的请求如果响应成功，则可判断该服务正常了，就可关闭该服务的熔断器，反之则继续打开熔断器。
这种自我熔断机制和自我修复机制...
可以使程序更加健壮，也可以为开发和运维，减少很多不必要的工作。
3、熔断组件提供监控
熔断组件往往会提供一系列的监控...
比如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等等。
从而，可以让开发人员和运维人员去了解服务的状况。
...
二十、Eureka的基础架构？
Eureka的基础架构的组成部分是...
1、服务注册中心（失效剔除、自我保护）；
2、服务提供者（服务注册、服务同步、服务续约）；
3、服务消费者（获取服务、服务调用、服务下线）。
...
下面，就来说下具体内容吧！
1、服务注册中心
Eureka提供的服务端，提供服务注册与发现的功能。
1.1、失效剔除
对于那些非正常下线的服务实例（内存溢出、网络故障导致的）...
服务注册中心，不能收到“服务下线”的请求，为了将这些无法提供服务的实例从服务列表中剔除...
Eureka Server在启动的时候，会创建一个定时任务...
默认每隔一段时间（默认60s），将当前清单中超时（默认90s）没有续约的服务，剔除出去。
1.2、自我保护
Eureka Server在运行期间，会统计心跳失败的比例，在15分钟之内是否低于85%...
如果出现低于的情况（生产环境由于网络不稳定会导致）...
Eureka Server会将当前的实例注册信息保护起来，让这些实例不过期，尽可能保护这些注册信息。
但是在这保护期间内，实例出现问题...
那么客户端，就很容易拿到实际上已经不存在的服务实例，会出现调用失败的情况。
所以客户端必须有容错机制，比如可以使用请求重试、断路器等机制。
在本地进行开发时，可以使用 eureka.server.enable-self-preseervation=false参数...
来关闭保护机制，以确保注册中心，可以将不可用的实例剔除。
2、服务提供者
提供服务的应用，可以是SpringBoot应用，也可以是其它的技术平台，且遵循Eureka通信机制的应用。
它将自己提供的服务，注册到Eureka，以供其它应用发现（如service层）。
2.1、服务注册
服务提供者，在启动的时候，会通过发送Rest请求的方式...
将自己注册到Eureka Server（服务注册中心）中，同时带上自身服务的一些元数据；
Eureka Server接收到这个Rest请求后，将元数据存储在一个双层结构Map中；
第一层的key是服务名，第二层key是具体服务的实例名。
2.2、服务同步
若有两个或两个以上的Eureka Server（服务注册中心）时...
它们之间是互相注册的。
当服务提供者，发送注册请求到一个服务注册中心时...
它会将该请求，转发到集群中相连的其它注册中心；
从而实现，注册中心间的服务同步，这样服务提供者的服务信息，可以通过任意一台服务中心获取到。
2.3、服务续约
在注册完服务之后，服务提供者会维护一个心跳，来持续告诉Eureka Server：“我还活着”...
以防止Eureka Server的“剔除任务”将该服务实例，从服务列表中排除出去。
配置：eureka.instance.lease-renewal-in-seds=30(续约任务的调用间隔时间，默认30秒，也就是每隔30秒向服务端发送一次心跳，证明自己依然存活)。
eureka.instance.lease-expiration-duration-in-seds=90(服务失效时间，默认90秒，也就是告诉服务端，如果90秒之内没有给你发送心跳就证明我“死”了，将我剔除)。
3、服务消费者
消费者应用，从服务注册中心获取服务列表...
从而使消费者，可以知道去何处调用其所需要的服务。
比如Ribbon实现消费方式，Feign实现消费方式。
3.1、获取服务
当启动服务消费者时，它会发送一个Rest请求给注册中心...
获取上面注册的服务清单；
Eureka Server会维护一份只读的服务清单，来返回给客户端，并且每三十秒更新一次。
3.2、服务调用
在服务消费者获取到服务清单后，通过服务名...
可以获得具体提供服务的实例名和该实例的元信息，采用Ribbon实现负载均衡。
3.3、服务下线
当服务实例，进行正常的关闭操作时...
它会触发一个服务下线的Rest请求，给Eureka Server，告诉服务注册中心“我要下线了”。
服务端接收到请求之后，将该服务状态设置为下线，并把下线时间传播出去。
...
二十一、Eureka和Zookeeper都可以提供服务注册与发现的功能，而两者的区别是？
简单来说，Zookeeper保证了CP(C：一致性，P：分区容错性)；
Eureka保证了AP(A：高可用，P：分区容错)。
1、Zookeeper
当向注册中心查询服务列表时...
我们可以容忍，注册中心返回的是几分钟以前的信息；
但不能容忍直接down掉，不可用的。
也就是说，服务注册功能对高可用性要求比较高。
但是Zookeeper会出现这样的一种情况...
当master节点，因为网络故障与其它节点失去联系时...
剩余的节点，会重新选leader。
问题在于，选取leader的时间过长(30~120s)，且选取期间Zookeeper集群都不可用...
这样就会导致，选取期间注册服务瘫痪。
在云部署的环境下，因网络问题...
使得Zookeeper集群，失去master节点，是较大概率会发生的事。
虽然服务最终恢复，但是漫长的选择时间，导致的注册长期不可用，是不能容忍的。
2、Eureka
它则看明白这一点，因此在设计上优先保证了高可用性。
Eureka各个节点都是平等的，几个节点挂掉，不会影响到正常节点的工作...
剩余的节点，依然可以提供注册和查询服务。
而Eureka的客户端，再向某个Eureka注册时...
如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在...
就能保证注册服务的可用(保证可用性)，只不过查到的信息，可能不是最新的(不保证一致性)。
除此之外，Eureka还有一种自我保护机制...
如果在15分钟内，超过85%的节点都没有正常心跳...
那么Eureka，就认为客户端与注册中心出现了网络故障。
而此时，就会出现以下几种情况：
2.1、Eureka不再从注册列表移除，因为长时间没收到心跳，而应该过期的服务；
2.2、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(保证当前节点可用)；
2.3、当网络稳定时，当前实例新的注册信息，会被同步到其它节点中。
Eureka还有客户端缓存功能(Eureka分为客户端程序和服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口)。
所以，即便Eureka集群中所有节点都失效，或者发生网络分隔故障，导致客户端不能访问任何一台Eureka服务器。
Eureka服务的消费者，任然可以通过Eureka客户端缓存，来获取所有的服务注册信息。
甚至最极端的环境下，所有正常的Eureka节点，都不对请求产生响应...
也没有更好的服务器解决方案，来解决这种问题。
得益于Eureka的客户端缓存技术，消费者服务...
仍然可以通过Eureka客户端，查询与获取注册服务信息，这点很重要；
因此Eureka，可以很好的应对网络故障，导致部分节点失去联系的情况。
而不像Zookeeper那样，使整个注册服务瘫痪。
...
二十二、CAP理论？
1、sistency
指数据的强一致性。
如果写入某个数据成功，之后读取，读到的都是新写入的数据；
如果写入失败，读到的都不是写入失败的数据。
2、Availability
指服务的可用性。
3、Partition-tolerance
指分区容错。
...
二十三、Ribbon和Nginx的区别？
1、Nginx性能好，但Ribbon可以剔除不健康节点，Nginx剔除比较麻烦。
2、Ribbon是客户端负载均衡，Nginx是服务端负载均衡。
...
二十四、服务注册与发现？
服务注册，就是向服务注册中心，注册一个服务实例...
服务提供者将自己的服务信息（服务名、IP地址等）告知注册中心。
服务发现，是服务消费另一个服务时，注册中心将服务的实例，返回给服务消费者...
一个服务，既是服务提供者又是服务消费者。
服务注册中心健康检查机制...
当一个服务实例注册成功以后，会定时向注册中心，发送一个心跳证明自己可用；
若停止发送心跳，证明服务不可用将会别剔除；
若过段时间继续向注册中心提供心跳，将会重新加入服务注册中心列表中。
...
二十五、微服务的负载均衡，为何用？怎么用？
1、为什么要用？
微服务是将业务代码拆分为很多小的服务单元...
服务之间的相互调用通过HTTP协议来调用，为了保证服务的高可用，服务单元往往都是集群化部署的。
2、消费者该调用，哪个服务提供者的实例呢？
服务消费者集成负载均衡组件，该组件会向服务消费者...
获取服务注册列表信息，并隔一段时间重新刷新获取列表。
当服务消费者消费服务时，负载均衡组件，获取服务提供者所有实例的注册信息...
并通过一定的负载均衡策略（可以自己配置）选择一个服务提供者实例；
向该实例进行服务消费，这样就实现了负载均衡。
……
以上，就是今天的分享啦！
希望，对你的求职面试，编程工作有那么一点点、一丢丢、一戳戳地帮助哈～
喜欢我分享的，就一键三连于我，可好？！