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