系列博客目录
文章目录
- 系列博客目录
- 1.引言
- 2.Spring Cloud
- 2.1 Spring Cloud 5大组件有哪些?
- 面试文稿
- 2.2 服务注册和发现是什么意思?Spring Cloud 如何实现服务注册发现?
- 面试文稿
- 2.3 我看你之前也用过nacos、你能说下nacos与eureka的区别?
- 面试文稿
- 2.4 你们项目负载均衡如何实现的?
- 面试文稿
- 2.5 什么是服务雪崩，怎么解决这个问题?
- 面试文稿
- 2.6 你们的微服务是怎么监控的?
- 面试文稿
- 3. 业务问题
- 3.1 你们项目中有没有做过限流?怎么做的?
- 面试文稿
- 3.2 解释一下CAP和BASE
- 面试文稿
- 2.4 你们采用哪种分布式事务解决方案？
- 面试文稿
- 2.5 分布式服务的接口幂等性如何设计?
- 面试文稿
- 2.6 你们项目中使用了什么分布式任务调度
- 面试文稿
1.引言
一定要有些微服务的内容在简历上，选择比较流行。要不然简历筛选过不了。
2.Spring Cloud
2.1 Spring Cloud 5大组件有哪些?
这是基础的内容考察
回答原则:简单的问题不能答错(一道面试题就能淘汰一个人)新手和老手都要注意。
这些都是在 Spring Cloud 微服务架构中常用的组件，它们各自承担着不同的功能，帮助实现高效、可靠的分布式服务管理。下面是对每个组件的简要解释：
-
Eureka：服务注册中心
- Eureka 是一个 RESTful 风格的服务注册与发现框架，提供了服务注册与服务发现的功能。各个微服务实例会在启动时向 Eureka 注册其信息，其他微服务通过 Eureka 获取服务的实例信息进行调用。
- 它帮助系统中的各个微服务相互发现，并且在服务实例的 IP 地址、端口变化时，能够动态更新，确保服务能够持续可用。
-
Ribbon：客户端负载均衡器
- Ribbon 是一个负载均衡工具，它在客户端实现了服务实例的负载均衡。通过 Ribbon，客户端可以动态地根据负载均衡算法（如轮询、加权等）选择要调用的服务实例。
- 它与 Spring Cloud 集成，可以在服务调用时自动选择一个合适的服务实例，避免了客户端调用硬编码服务地址的问题。
-
Feign：声明式的服务调用
- Feign 是一个声明式的 Web 服务客户端，简化了服务之间的 HTTP 调用。通过 Feign，开发者只需要定义一个接口，Feign 会自动实现该接口并处理 HTTP 请求的发送。
- 它与 Ribbon 集成，可以实现负载均衡，同时也与 Eureka 集成，方便进行服务发现，极大地减少了服务调用的复杂度。
-
Hystrix：服务熔断器
- Hystrix 是一个提供容错处理的库，用来防止服务的级联失败。当某个服务调用失败或超时时，Hystrix 会自动进行熔断，防止故障蔓延到其他服务。
- 它通过“断路器”模式实现服务的隔离，如果服务连续失败，Hystrix 会停止请求该服务，从而保护系统的其他部分不受影响，减少系统故障的范围。
-
Zuul/Gateway：API网关
- Zuul 和 Gateway 都是用于处理 API 请求的网关组件。它们充当客户端与后端服务之间的中介，接收客户端请求并转发到相应的服务。
- Zuul 提供路由、过滤、监控等功能，适用于复杂的服务网关需求。Gateway 是 Spring Cloud 提供的新一代 API 网关，功能上更为全面，支持更强的路由、过滤和安全管理，推荐用于新的项目。
这些组件在 Spring Cloud 中提供了完整的微服务架构支持，使得开发者可以专注于业务逻辑，简化了分布式系统的管理与开发。
面试文稿
候选人：
在早期，Spring Cloud的五大组件通常指的是：
- Eureka：服务注册中心。
- Ribbon：客户端负载均衡器。
- Feign：声明式的服务调用。
- Hystrix：服务熔断器。
- Zuul/Gateway：API网关。
随着Spring Cloud Alibaba的兴起，我们项目中也融入了一些阿里巴巴的技术组件：
- 服务注册与配置中心：Nacos。
- 负载均衡：Ribbon。
- 服务调用：Feign。
- 服务保护：Sentinel。
- API网关：Gateway。
2.2 服务注册和发现是什么意思?Spring Cloud 如何实现服务注册发现?
微服务中必须要使用的组件，考察我们使用微服务的程度
注册中心的核心作用是:服务注册和发现
常见的注册中心:eureka、nocas、zookeeper
面试文稿
服务注册和发现是什么意思？Spring Cloud 如何实现服务注册发现？
候选人：
服务注册与发现主要包含三个核心功能：服务注册、服务发现和服务状态监控。
我们项目中采用了eureka作为服务注册中心，它是Spring Cloud体系中的一个关键组件。
- 服务注册：服务提供者将自己的信息（如服务名称、IP、端口等）注册到eureka。
- 服务发现：消费者从eureka获取服务列表信息，并利用负载均衡算法选择一个服务进行调用。
- 服务监控：服务提供者定期向eureka发送心跳以报告健康状态；如果eureka在一定时间内未接收到心跳，将服务实例从注册中心剔除。
2.3 我看你之前也用过nacos、你能说下nacos与eureka的区别?
Nacos 的 配置中心 功能是它的一个重要组成部分，能够帮助开发团队实现配置的集中管理、动态更新和版本控制。它极大地简化了分布式系统中配置管理的复杂性，提高了系统的灵活性和可维护性。
配置中心的优势：
集中管理：所有微服务的配置集中存储，统一管理，减少了分布式架构中配置分散带来的麻烦。
实时更新：支持配置变更时的实时推送，不需要重启服务，提升了配置更新的效率。
多环境支持：支持不同环境的配置隔离，使得多环境部署更加简单清晰。
面试文稿
- 我看你之前也用过nacos，你能说下nacos与eureka的区别？
候选人：
在使用Nacos作为注册中心的项目中，我注意到Nacos与Eureka的共同点和区别：
- 共同点：两者都支持服务注册与发现，以及心跳检测作为健康检查机制。
- 区别：
- Nacos支持服务端主动检测服务提供者状态，而Eureka依赖客户端心跳。
- Nacos区分临时实例和非临时实例，采用不同的健康检查策略。临时实例采用心跳模式，非临时实例采用主动检测模式
- Nacos支持服务列表变更的消息推送，使服务更新更及时。
- Nacos集群默认采用AP模式，但在存在非临时实例时，会采用CP模式；而Eureka始终采用AP模式。
2.4 你们项目负载均衡如何实现的?
- 负载均衡 Ribbon，发起远程调用feign就会使用Ribbon
- Ribbon负载均衡策略有哪些?
- 如果想自定义负载均衡策略如何实现 ?
最后一个比如先选择北京地区，然后在区域内选择服务。
左边全局生效，右边局部生效只针对user的service
面试文稿
-
你们项目负载均衡如何实现的？
候选人：
在服务调用过程中，我们使用Spring Cloud的Ribbon组件来实现客户端负载均衡。Feign客户端在底层已经集成了Ribbon，使得使用非常简便。
当发起远程调用时，Ribbon首先从注册中心获取服务地址列表，然后根据预设的路由策略选择一个服务实例进行调用，常用的策略是轮询。 -
Ribbon负载均衡策略有哪些？
候选人：
Ribbon提供了多种负载均衡策略，包括：
- RoundRobinRule：简单的轮询策略。
- WeightedResponseTimeRule：根据响应时间加权选择服务器。
- RandomRule：随机选择服务器。
- ZoneAvoidanceRule：区域感知的负载均衡，优先选择同一区域中可用的服务器。
- 如果想自定义负载均衡策略如何实现？
候选人：
自定义Ribbon负载均衡策略有两种方式：- 创建一个类实现IRule接口，这将定义全局的负载均衡策略。
- 在一个微服务的配置文件中指定该特定服务调用的负载均衡策略，这将仅对该服务生效。
2.5 什么是服务雪崩，怎么解决这个问题?
如果降级（位置来的请求）太多，就会触发熔断机制。
面试文稿
- 什么是服务雪崩，怎么解决这个问题？
候选人：
服务雪崩是指一个服务的失败导致整个链路的服务相继失败。我们通常通过服务降级和服务熔断来解决这个问题：- 服务降级：在请求量突增时，主动降低服务的级别，确保核心服务可用。
- 服务熔断：当服务调用失败率达到一定阈值时，熔断机制会启动，防止系统过载。
2.6 你们的微服务是怎么监控的?
为什么监控，为了解决下面的四个问题：
问题定位：微服务链路中有个地方挂了之后，能不能很快找到。
性能分析：有个微服务调用mysql，接口响应时间比较长，超过了2s中，那当前服务链路中有一个服务慢，就让整个链路慢，还不好定位。
服务关系
服务告警
如何实现监控：
面试文稿
3. 业务问题
3.1 你们项目中有没有做过限流?怎么做的?
Tomcat不适合微服务。因为有很多Tomcat实例。
而Nginx和网关比较合适。
回答面试管的时候，只需要说通过Nginx的漏桶算法来限流，漏桶算法就是把水滴代表请求的流量，通过一个漏桶来存储请求，以固定速率漏出请求，多于请求等待或抛弃。
除了控制速率还可以控制并发连接数。
令牌桶与漏桶的区别是，使用令牌桶时，请求获得令牌的速率不是固定的，可能会超过令牌生成的固定速率。
面试文稿
上面QPS比如1000；
-
你们项目中有没有做过限流？怎么做的？
在我们的项目中存在抢券的功能，由于面临可能的突发流量，我们采用了限流策略是使用Nginx按照IP进行限流，通过漏桶算法控制请求处理速率，
-
限流常见算法有哪些？
候选人：
常见的限流算法包括：- 漏桶算法：以固定速率处理请求，平滑突发流量。
- 令牌桶算法：按照一定速率生成令牌，请求在获得令牌后才被处理，适用于请求量有波动的场景。
3.2 解释一下CAP和BASE
学习这两个理论的目的：
- 分布式事务方案的指导
- 分布式系统设计方向
- 根据业务指导使用正确的技术选择
面试文稿
-
什么是CAP理论？
候选人：
CAP理论是分布式系统设计的基础理论，包含一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)。在网络分区发生时，系统只能在一致性和可用性之间选择其一。 -
为什么分布式系统中无法同时保证一致性和可用性？
候选人：
在分布式系统中，为了保证分区容错性，我们通常需要在一致性和可用性之间做出选择。如果系统优先保证一致性，可能需要牺牲可用性，反之亦然。 -
什么是BASE理论？
候选人：
BASE理论是分布式系统设计中对CAP理论中AP方案的延伸，强调通过基本可用、软状态和最终一致性来实现系统设计。
2.4 你们采用哪种分布式事务解决方案？
只要你在简历上写了微服务 项目，就得发送远程请求，就可能涉及到分布式事务。
面试文稿
你们采用哪种分布式事务解决方案？
候选人：
我们项目中使用了Seata的AT模式来解决分布式事务问题。AT模式通过记录业务数据的变更日志来保证事务的最终一致性。
2.5 分布式服务的接口幂等性如何设计?
唯一索引 有的数据库表中没有，所以这里不使用。
面试文稿
- 分布式服务的接口幂等性如何设计？
候选人：
幂等: 多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。新增和增量更新不是幂等的。
我们通过Token和Redis来实现接口幂等性。用户操作时，系统生成一个Token并存储在Redis中，当用户提交操作时，系统会验证Token的存在性，并在验证通过后删除Token，确保每个Token只被处理一次。
2.6 你们项目中使用了什么分布式任务调度
面试文稿
-
xxl-job路由策略有哪些？
候选人：
xxl-job支持多种路由策略，包括轮询、故障转移和分片广播等。 -
xxl-job任务执行失败怎么解决？
候选人：
面对任务执行失败，我们可以：- 选择故障转移路由策略，优先使用健康的实例执行任务。
- 设置任务重试次数。
- 通过日志记录和邮件告警通知相关负责人。
-
如果有大数据量的任务同时都需要执行，怎么解决？
候选人：
我们可以通过部署多个实例并使用分片广播路由策略来分散任务负载。在任务执行代码中，根据分片信息和总数对任务进行分配。
`、`COUNT(1)` 和 `COUNT(column)` 的区别解析)
