目录
1. SpringCloud和SpringBoot的区别和关系?
4. Zookeeper保证的CP和Eureka保证的AP是什么?
1. SpringCloud和SpringBoot的区别和关系?
- SpringBoot专注于快速方便的开发单个个体微服务。
- SpringCloud关注全局的微服务协调治理框架以及一整套的落地解决方案,它将SpringBoot开发的一个个单体的微服务整合并管理起来,为各个微服务之间提供:配置管理,服务发现,断路器,路由,微代理,事件总线等集成服务。
- SpringBoot是可以离开SpringCloud独立使用,但是SpringCloud离不开SpringBoot,属于依赖关系。
- 总结:SpringBoot专注于快速,方便地开发单个微服务个体,SpringCloud关注全局的服务治理框架。
2. SpringCloud由哪些组件组成?
- Eureka和Nacos:服务注册与发现。
- Zuul和SpringCloudGateway:服务网关。
- Ribbon:客户端负载均衡。
- Feign:声明性的Web服务客户端。
- Hystrix:断路器。
- SpringCloudConfig或Nacos:分布式统一配置管理。
3. Eureka和Zookeeper的区别?
- Zookeeper中的节点服务挂了就要选举,在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可以用,选举就是改微服务做了集群,必须有一台主机其他都是从机。
- Eureka各个节点是平等的关系,服务器挂了没关系,只要有一台Eureka就可以保证服务可用,数据都是最新的。如果查询到的数据不是最新的,那是Eureka的自我保护机制导致的。
- Eureka本质上是一个工程,而Zookeeper是一个进程。
- Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,不会像Zookeeper一样使得整个注册系统瘫痪。
- Zookeeper保证的是CP,Eureka保证的是AP。
4. Zookeeper保证的CP和Eureka保证的AP是什么?
这句话是在比较Zookeeper和Eureka两个分布式服务架构的一致性和可用性之间的权衡。
- 一致性:在分布式系统中,所有节点都能够看到相同的数据,并且这些数据会随着时间的推移而同步更新。换句话说,一致性要求所有节点在同一时间看到的应该是相同状态的数据。
- 可用性:分布式系统中,每个请求必须得到响应,并且这个响应必须在有限的时间范围内返回,换句话说,可用性要求系统必须保持能够处理请求的状态。
Zookeeper和Eureka都是提供分布式服务的框架,他们在一致性和可用性做了不同的权衡:
- Zookeeper:保证一致性和分区容错性,也就是所谓的CP。Zookeeper提供了分布式锁,选举算法等功能,通过Zookeeper可以实现高可靠的分布式系统。在Zookeeper集群中,如果某个节点失效或者网络分区,仍然可以保证其余节点的数据一致性。
- Eureka:强调可用性和分区容错性,也就是AP。Eureka提供服务治理,负载均衡等功能,通过Eureka可以方便地实现微服务架构。在一个Eureka集群中,如果某个节点失效或者网络分区,仍然可以保证剩余节点之间的可用性。
因此在选择Zookeeper和Eureka作为分布式服务框架,需要根据具体的场景和需求进行权衡利弊,如果注重数据一致性,并且可以忍受一定的服务不可用,则可以选择Zookeeper;如果需要保证服务高可用,并且接受一定的数据不一致,可以选择Eureka。
5. Eureka的工作原理
Eureka是Netflix开源的基于RESTful API服务发现的框架。它旨在帮助开发者构建更加可靠和可扩展的云端应用,同时也是SpringCloud微服务架构体系中非常重要的一环。
Eureka工作原理可以简单概括为:服务提供者向Eureka注册自己的服务实例,服务消费者从Eureka获取可用的实例列表,并通过负载均衡算法选择其中一个实例进行调用。
工作流程如下:
- 服务提供者启动时,会向Eureka发送注册请求,告知自己的服务实例信息,如IP地址,端口号,服务名等。
- Eureka收到服务提供者的注册请求后,将其存储在自己的注册表中,在心跳检测的机制下,定期检查服务实例的可用性。
- 服务消费者向Eureka发起服务调用请求时,Eureka会返回全部可用的服务实例列表给服务消费者,并根据负载均衡算法选择其中一个实例进行调用,如果发现某个实例不可用,则自动从注册表移除,并告知给消费者。
- 当服务提供者关闭或者网络出现错误,服务实例会自动从注册表删除,并通知Eureka,它会及时更新注册表。
总之Eureka通过心跳检测,服务注册,缓存机制等多种方式,提供了一种可靠的服务发现和负载均衡的解决方案,帮助开发者更好地构建高可用和可扩展的云端应用。
6. Feign服务调用的过程
Feign是一种声明式的,模块化的HTTP客户端,可以轻松地使用Netflix OOS(Ribbon,Hystrix等)实现基于HTTP的服务调用。其调用过程如下:
- 在代码中定义一个接口,并使用@FeignClient注解标记该接口,指定被调用服务的名称和相关配置。
- 通过使用该接口的方法进行服务调用。此时SpringCloud会根据@FeignClient注解中指定的服务名,在服务注册中心查找对应的服务实训,之后再根据Ribboon负载均衡策略选择一个可用的服务实例进行调用。
- Feign会根据接口方法上的请求参数和路径信息生成HTTP请求,再调用远程服务时,可以在请求头部添加自定义的信息(如传递认证信息或用户状态信息)。
- 接着Feign会将HTTP请求发送到选定的服务实例。
- 当服务实例返回响应时,Feign会将相应封装成定义好的接口的返回值类型,返回给调用方。
- 如果远程服务调用失败,Feign能够捕获异常信息并进行处理,如熔断,降级等操作。
总结:使用Feign惊醒服务调用的过程主要包括接口定义,服务选择,HTTP请求转换,响应处理等步骤。它使服务调用更加简明扼要,规范。
7. 什么是Hystrix?
Hystrix是Netflix开源的一款容错框架,主要用于处理复杂分布式系统交互中的延迟和故障,防止因依赖服务的不可用而导致整个系统的崩溃。
在微服务架构中,服务之间的调用是通过HTTP请求完成的。当某个服务因为网络故障或其他原因不能正常响应时,这会导致服务调用方的请求被阻塞,最终可能导致整个系统瘫痪。Hystrix就是为了解决这类问题而诞生的。
Hystrix提供了以下功能:
- 服务熔断:当某个服务出现故障时,Hystrix会将该服务的请求熔断,并且快速返回一个预设好的错误信息,这样就避免了大量请求堆积在不可用的服务上,进而造成更大的故障。
- 线程隔离:可以将每个请求都放到单独的线程中,这样可以防止某个请求耗费更多的时间或资源,导致其他的请求受到影响。
- 请求缓存:使用Hystrix可以快速缓存服务的响应结果,从而减少对服务的请求次数,提高系统的性能。
- 自动降级:当某个服务的响应时间达到一定的阈值,Hystrix会自动降级服务的相应质量,保证系统的可用性。
总之Hystrix是一个非常有用的容错框架,可以有效地提高分布式系统的稳定性和可靠性。而且,Hystrix与SpringCloud等微服务框架紧密集成,使得使用Hystrix在微服务模型中变得更加简单和方便。
8. 微服务之间如何通信?
- 同步通信:Dubbo通过RPC远程过程调用,SpringCLoud通过REST API接口json调用等。
- 同步通信是指调用方发送请求后,必须等待服务端返回响应结果,才能继续执行后面的代码。这种情况下,调用方和服务端之间的通信是实时的,双向的。Dubbo框架通过RPC远程过程调用实现同步通信,而SpringCloud通过REST接口实现同步通信。
- 异步通信:消息队列,如RabbitMq,Kafka,ActiveM等。
- 异步通信是指调用方发送请求后,可以立即返回,并不需要等待服务端响应结果,服务端在处理完请求后再次通知调用方。这种情况下,调用方和服务端之间的通信是间接的,通常采用消息队列方式实现。消息队列是一种典型的异步通信方式,它使用一条消息传递机制,将消息发送到队列中,然后由消费者从队列中取出消息进行处理。常见的消息队列:RabbitMQ,ActiveMQ,Kafka等。
异步通信和同步通信各有优缺点,实际开发根据业务需求选择合适的通信方式。同步通信实用性高,但容易导致调用方阻塞和系统资源消耗过多;异步通信开销小,但是对系统的可靠性较高,需要考虑消息丢失等问题。
9. SpringCloud和dubbo的区别?
SpringCloud和dubbo都是优秀的微服务框架,他们提供了分布式系统开发所需要的核心功能。如:服务注册与发现,负载均衡,服务容错,服务熔断,服务降级等,但是还是存在一些差异:
- 架构设计上的区别:Dubbo采用三层架构:接口层,服务层,实现层。每层都可以配置不通的规则,从而实现更细粒度的控制。SpringCloud采用四层架构,API网关层,服务治理层,控制层,为服务层。
- 通信协议上的区别:Dubbo采用RPC调用方式,支持多种序列化的协议(如Hessian,Protobuf等),底层通信使用NIO进行封装,具有较高性能;而SpringCloud采用HTTPR ESTful APi接口通信,以json格式进行数据交换。
- 生态系统上的区别:Dubbo生态系统相对单一,基本只有Dubbo自身提供的组件,如注册中心,负载均衡,远程调用等。SpringCloud整合了众多开源组件:Eureka,Zuul,Hystrix等,提供了完整的微服务架构解决方案。
- 配置方式上的区别:Dubbo采用XML配置文件与java注解相结合的方式配置,虽然可读性高,但也导致了配置量庞大,不易维护;而SpringCloud基于SpringBoot的纯Java配置方式,简化了系统配置。
总之,Dubbo主打RPC通信,高性能,多协议支持,灵活拓展等;SpringCloud则以全面的生态系统,灵活的配置方式,集成众多的开源组件,丰富的云原生功能等方面脱颖而出。
10. Eureka怎么实现高可用?
Eureka是一个服务注册与发现的工具,通过Eureka可以将服务提供者的信息注册到EurekaServer并且服务消费者可以从EurekaServer获取可用的服务提供者列表。
保证高可用性,可以采取以下措施:
- EurekaServer集群:通过部署多个EurekaServer实例 组成集群,提高EurekaServer的可用性。再EurekaClint注册时,需要将注册地址设置为多个EurekaServer的地址;这样即使某些EurekaServer宕机,客户端仍然可以发现服务实例。
- 负载均衡:对于EurekaServer集群,可以使用负载均衡分摊请求负载,在请求EurekaServer时自动选择一台可用的服务器进行响应。
- 备份注册中心:可以将EurekaServer注册信息备份到其他存储设备(数据库或文件),避免注册信息丢失。当EurekaServer宕机,可用快速恢复。
11. 什么是网关?网关的作用?
网关相当于网络服务架构的入口,所有的网络请求必须通过网关转发到具体的服务。网关可用统一管理微服务请求,权限控制,负载均衡,路由转发,监控,安全控制黑名单和白名单等。
12. 什么是SpringCloudZuul(服务网关)
Zuul是对SpringCloud提供的成熟对的路由方案,会根据不同的请求路径,网关会定位到指定的微服务,并代理请求到不同的微服务接口,对外隐蔽了微服务的真正接口地址。
三个重要概念:动态路由表,路由定位,反向代理
- 动态路由表:Zuul支持Eureka路由,手动配置路由,这两种都支持自动更新。
- 路由定位:根据请求路径Zuul有自己的一套定位服务规则以及路由表达式匹配。
- 反向代理:客户端请求到路由网关,网关受理后,再对目标发送请求,拿到响应后再给客户端。
Zuul可用于Eureka,Ribbon,Hystrix等组件配合使用
Zuul使用场景:对外暴露,权限校验,服务聚合,日志审计等
13. 网关与过滤器的区别?
网关是对所有服务的请求进行分析过滤,过滤器是对单个服务而言。
14. 常用网关框架
Nginx,Zuul,Gateway
15. Zuul和Nginx区别?
Zuul是Java语言实现的,主要为java服务提供网关服务,尤其是在微服务架构中可用更加灵活的对网关进行操作。Nginx使用C语言实现,性能高于Zuul,但是实现自定义操作需要熟悉lua语言,对程序员要求较高,可使用Nginx做Zuul集群。
16. 负载均衡的意义是什么?
负载均衡是指将网络流量分发到多个服务器上,以实现系统资源的合理利用和请求处理能力的提高
负载均衡可以改善跨计算机,计算机集群,网络连接,中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载均衡是指再优化资源使用,最大化吞吐量,最小化响应时间并避免任何单一资源的过载。
17. Ribbon是什么?
Ribbon是Netflix发布的开源项目,主要功能提供客户端的软件负载均衡算法。
Ribbon客户端组件提供一系列完善的配置项,如连接超时,重试等。简单说,就是在配置文件中列出所有的及其,Robbin会自动的帮助你基于某种规则(如轮询,随机等)去连接机器。我们也很容易使用Robbin实现自定义的负载均衡算法。
18. Ribbon底层实现原理
Ribbon使用discoveryClient从注册中心读取目标服务信息,对统一接口请求进行计数。使用%取余算法获取目标服务集群索引,返回获取到的目标服务信息。
19. Hystrix防止雪崩的方式?
- 服务降级:接口调用失败就调用本地方法返回一个空。
- 服务熔断:接口调用失败会进入调用接口提前定义好的熔断方法,返回错误信息。
- 服务隔离:隔离服务之间相互影响。
- 服务监控:在服务发生调用时,会将每秒请求数,成功请求数等运行指标记录下来。
20. 微服务中,如何保护服务?
一般使用Hystrix框架,实现服务隔离来避免出现服务的雪崩效应,从而达到保护服务的效果。当微服务中,高并发的数据库访问量导致服务线程阻塞,使单个服务宕机,服务的不可用会蔓延到其他的服务,引起整体服务灾难性后果,使用服务降级能有效为不同的服务分配资源,一旦服务不可用规则返回友好提示,不占用其他服务资源,从而避免单个服务崩溃引发整体服务的不可用。
21. 什么是服务的雪崩?产生的原因?
雪崩效应使大型互联网项目中,某个服务发生宕机,调用这个服务的其他服务也会发生宕机,大型项目的微服务之间的调用使相通的,这样就会将服务的不可用逐步扩大到各个服务,从而使整个项目的服务宕机崩溃。
发生雪崩的原因:
- 因为Tomcat默认情况只有一个线程池来维护客户端发送的所有请求,这个时候某一接口在某一时刻被大量访问就会占据tomcat线程池的所有线程,其他请求处于等待状态,无法连接到服务接口。
22. SpringCloudNetflix
Netflix OOS开源组件集成,包括Eureka,Hystrix,Ribbon,Feign,Zuul等核心组件。
- Eureka:服务治理组件,包括服务端的注册中心和客户端服务发现的机制。
- Ribbon:负载均衡的服务组件,具有多种负载均衡调用策略
- Hystrix:服务容错组件,实现了断路器模式,为以来服务的出错和延迟提供了容错能力
- Feign:基于Ribbon和Hystrix的声明式服务调用组件。
- Zuul:API网关组件,对请求提供路由以及过滤功能。