【P0】Spring Cloud 面试篇
什么是微服务架构?
什么是微服务架构?
架构本质:拆分单体应用为对应单一业务能力的微服务
核心特征:
- 独立进程运行,互不依赖
- 轻量机制(HTTP/REST、gRPC)通信
- 自动化部署,可单独更新
- 支持多语言、多数据库的技术异构
- 仅需最低限度集中式管理
为什么需要学习Spring Cloud?
- 基于 Spring Boot 简化配置:依托 Spring Boot 的简洁特性,封装市场优秀服务框架,屏蔽 XML、框架复杂配置(如 Spring MVC、MyBatis 旧版配置),降低使用门槛
- 开箱即用的便捷性:无需复杂搭建(如 Dubbo+Zookeeper 的繁琐配置),仅需引入对应 Jar 依赖即可快速集成所需功能
- 子模块直击业务痛点:各核心子模块针对性解决微服务问题,如 Zuul 处理跨域、Feign 实现负载均衡、Hystrix 提供熔断机制
Spring Cloud 是什么?
- 框架定位:Spring Cloud 是分布式系统基础设施的有序框架集合,聚焦服务发现注册、配置中心、路由、负载均衡等核心能力
- 开发简化:依托 Spring Boot 开发风格,实现分布式功能的一键启动与部署,降低分布式系统开发复杂度
- 设计理念:不重复造轮子,整合成熟第三方服务框架,通过封装屏蔽复杂配置与实现原理,提供简单易懂、易部署维护的开发工具包
SpringCloud 的优缺点?
核心优点:
- 低耦合:模块独立开发,互不影响
- 高效协作:支持团队并行开发,专注各自模块
- 简化配置:以注解为主,减少配置文件依赖
- 跨平台兼容:支持多语言开发微服务
- 数据库灵活:微服务可独立用库或共享库
- 前后端解耦:后端专注接口开发,通过组件实现服务通信
核心缺点:
- 部署复杂:增加运维工作难度
- 数据管理难:多微服务独立数据库时,数据协调复杂
- 集成测试繁琐:系统级测试难度提升
- 性能监控难:建议开发大屏监控系统应对
SpringBoot 和 SpringCloud 的区别?
- SpringBoot:专注快速开发单个微服务个体,注重快速便捷
- SpringCloud:聚焦全局微局微服务协调整治,整合管理 SpringBoot 开发的单体微服务,提供配置管理、服务发现、断路器等集成服务
- 依赖关系:SpringBoot 可独立使用,SpringCloud 必须依赖 SpringBoot
- 核心差异:前者专注个体开发,后者侧重全局服务治理
SpringCloud 由什么组成?
- Spring Cloud Eureka:服务注册与发现
- Spring Cloud Zuul:服务网关
- Spring Cloud Ribbon:客户端负载均衡
- Spring Cloud Feign:声明性的Web服务客户端
- Spring Cloud Hystrix:断路器
- Spring Cloud Confifig:分布式统一配置管理
使用 Spring Boot 开发分布式微服务时,我们面临什么问题?
- 系****统复杂性:面临网络问题、延迟 / 带宽开销、安全风险等分布式特有的额外开销
- 服务发现:需通过服务目录实现服务注册与查找,解决服务间如何定位、通信的问题
- 冗余管理:需处理分布式环境下的冗余控制问题(如数据、服务冗余)
- 负载平衡:需将工作负荷合理分配到多计算资源(计算机、集群、CPU 等),避免资源过载或闲置
- 性能损耗:各类运营开销(如通信、协调)易导致系统性能下降
Spring Cloud 和 Dubbo 区别?
- 服务调用方式:Dubbo 基于 RPC;SpringCloud 采用 Rest Api
- 注册中心:Dubbo 常用 Zookeeper;SpringCloud 主流为 Eureka,也支持 Zookeeper,目前 Nacos 使用较多
- 生态完整性:
- Dubbo 无内置服务网关,需整合第三方
- SpringCloud 含 Zuul 路由网关(请求分发),并集成断路器、Git 配置版本控制、事务总线等完整微服务要素
什么是SpringCloud & Alibaba?
- Spring Cloud:Spring 开源组织旗下子项目,提供分布式微服务系统工具集,助力快速构建微服务应用
- Spring Cloud Alibaba:Spring Cloud 的子项目,含微服务开发必备组件,是基于并符合 Spring Cloud 标准的阿里系微服务解决方案
Eureka
服务注册和发现是什么意思?SpringCloud 如何实现?
- 解决配置痛点:规避传统属性文件配置的弊端 —— 当服务增多、部署扩展时,手动修改服务地址等属性易出错、难维护
- 核心机制:所有服务在 Eureka 服务器注册,服务间调用通过 Eureka 查找目标服务
- 关键价值:无需手动处理服务地址变更,自动适配服务上下线与位置调整,降低服务管理复杂度
什么是 Eureka?
- 核****心角色:Eureka 是 Spring Cloud 的服务注册中心,承担服务注册与状态监控职能
- 工作流程:
- 系统中其他微服务通过 Eureka 客户端,连接并注册到 Eureka Server
- 已注册服务通过持续发送心跳,维持与 Eureka Server 的通信
- 核心价值:工作人员可通过 Eureka Server 实时监控各微服务的运行状态(如是否在线)
Eureka 怎么实现高可用?
- 核心方案:部署 Eureka Server 集群,避免单点故障
- 关键配置:集群内各 Eureka 节点互注册,确保服务注册表信息同步
- 客户端访问:客户端配置集群地址列表,按序访问正常节点获取服务信息,保障服务发现不中断
什么是 Eureka 的自我保护模式?
- 触发条件:默认情况下,Eureka Server 若一定时间内未接收某微服务心跳,会触发自我保护模式
- 核心行为:进入该模式后,Eureka Server 会保护服务注册表信息,不删除注册表中的数据
- 恢复机制:当网络故障修复后,Eureka Server 节点会自动退出自我保护模式
DiscoveryClient的作用
- 可以从注册中心中根据服务别名获取注册的服务器信息。
Eureka 和 ZooKeeper 都可以提供服务注册与发现的功能,请说说两个的区别?
核心机制差异:
- 集群角色与可用性:
- ZooKeeper:节点分主从,主节点挂了需选举,选举期间注册服务瘫痪
- Eureka:节点平等,单节点挂不影响,只要有一台正常即可保障服务可用
- 本质定位:
- Eureka:微服务注册发现工程
- ZooKeeper:分布式协调进程
- 网络故障应对:
- Eureka:可应对部分节点失联,不导致注册系统瘫痪(数据非最新可能因自我保护模式)
- ZooKeeper:网络分区易引发整体注册服务不可用
CAP理论遵循:
- ZooKeeper:保证 CP(一致性 + 分区容错性),优先强一致性
- Eureka:保证 AP(可用性 + 分区容错性),优先服务可用性(允许短暂数据不一致)
Zuul
什么是网关?
网关是网络服务架构的统一入口,所有网络请求需经网关转发,才能抵达具体服务。
网关的作用是什么?
- 统一入口:作为所有网络请求的唯一入口,集中接收并分发请求到对应服务
- 请求路由:根据规则将请求转发至目标微服务,实现服务间请求导航
- 协议转换:处理不同协议间的转换(如 HTTP 与 RPC),简化客户端与服务端交互
- 横切关注点处理:集中实现认证授权、限流熔断、日志监控、缓存、跨域等功能,减少服务重复开发
- 服务隔离与保护:通过限流、负载均衡等机制,防止单个服务过载影响整体系统
- 简化客户端:客户端只需对接网关,无需了解后端服务细节,降低调用复杂度
什么是Spring Cloud Zuul(服务网关)?
- 核心定位:Spring Cloud 提供的路由方案,按请求路径定位微服务并代理请求,隐藏微服务真实接口地址
- 三大关键概念:
- 动态路由表:支持 Eureka 路由、手动配置路由,且均能自动更新
- 路由定位:通过自身规则与路由表达式匹配,根据请求路径定位服务
- 反向代理:接收客户端请求后,转发至目标服务,获取响应后回传客户端
- 组件协作:可与 Eureka(服务发现)、Ribbon(负载均衡)、Hystrix(熔断)等组件配合使用
- 典型应用场景:对外统一暴露接口、权限校验、服务聚合、日志审计
网关与过滤器有什么区别?
网关是对所有服务的请求进行分析过滤,过滤器是对单个服务而言。
常用网关框架有那些?
- Nginx、Zuul、Gateway
Zuul 与 Nginx 有什么区别?
- 技术实现:
- Zuul:Java 语言实现,适配 Java 服务,微服务架构中网关操作更灵活
- Nginx:C 语言实现,性能优于 Zuul,自定义定义需熟悉 Lua,对开发者要求高
- 协作模式:可使用 Nginx 搭建 Zuul 集群,结合两者优势
既然Nginx可以实现网关?为什么还需要使用Zuul框架?
Zuul是SpringCloud集成的网关,使用Java语言编写,可以对SpringCloud架构提供更灵活的服务。
如何设计一套API接口?
- 接口分类:
- 内网 API 接口:用于局域网,为内部服务器提供服务
- 开放 API 接口:面向外部合作单位,需遵循 Oauth2.0 权限认证协议
- 核心考量:设计时需兼顾安全性、幂等性等关键问题
ZuulFilter常用有那些方法?
- Run():过滤器的具体业务逻辑
- shouldFilter():判断过滤器是否有效
- fifilterOrder():过滤器执行顺序
- fifilterType():过滤器拦截位置
如何实现动态Zuul网关路由转发?
- 请求拦截:通过 path 配置拦截指定请求
- 服务定位:依据 ServiceId 到配置中心获取目标转发服务列表
- 负载均衡与转发:内部集成 Ribbon,实现本地负载均衡并完成请求转发
Zuul网关如何搭建集群?
- 集群配置:通过 Nginx 的
upstream
模块配置 Zuul 服务集群节点 - 请求拦截转发:利用
location
规则拦截目标请求,将请求转发至upstream
配置的 Zuul 集群 - 负载策略:默认采用轮询机制,将请求均匀分配到 Zuul 集群各节点
Ribbon
负载均衡的意义是什么?
- 优化资源利用:动态分配请求至负载较轻节点,避免部分节点过载、部分闲置,减少资源浪费
- 提升系统性能:分流请求到多节点并行处理,提高吞吐量、降低响应时间,优化用户体验
- 保障高可用:实现故障自动转移,当节点故障时将请求转发至正常节点,避免单点故障导致服务中断
- 支撑弹性扩展:可配合弹性伸缩,新增节点快速接入分担压力、闲置节点下线降本,适配业务流量波动
Ribbon 是什么?
- 定位:Netflix 开源的客户端负载均衡组件,提供软件负载均衡算法
- 核心功能:
- 支持连接超时、重试等完善配置
- 自动基于规则(如轮询、随机等)连接配置文件中列出的机器
- 易于实现自定义负载均衡算法
- 特性类比:功能类似 Nginx,聚焦客户端侧负载均衡
Nginx 和 Ribbon 的区别?
- Nginx:
- 反向代理 + 负载均衡
- 拦截客户端请求,基于 upstream 配置的策略转发
- 转发过程由 Nginx 服务器完成
- Ribbon:
- 客户端负载均衡
- 从注册中心获取目标服务器信息
- 客户端直接采用轮询等策略访问服务,全程在客户端操作
Ribbon 底层实现原理?
- Ribbon 负载均衡机制:
- 通过 discoveryClient 从注册中心读取目标服务信息
- 对同一接口请求计数,采用 % 取余算法获取目标服务集群索引
- 返回匹配的目标服务信息
- @LoadBalanced 注解作用:开启客户端客户端负载均衡功能
Hystrix
什么是短路器?
- 服务雪崩成因:当服务调用因网络 / 自身问题失败时,调用者会持续等待;若大量请求涌向故障服务,会引发连锁等待,导致雪崩效应。
- 断路器三种状态:
- 打开状态:短时间内调用失败次数达标且无恢复迹象,后续请求直接拦截,不转发至故障服务。
- 半开状态:监测到故障服务有恢复迹象,仅将部分请求转发;若调用正常,断路器切换为关闭状态。
- 关闭状态:服务调用持续正常,断路器保持关闭,请求正常转发至服务。
什么是 Hystrix?
- 核心定位:分布式系统中的防雪崩工具,用于应对服务依赖失败场景,避免引发雪崩效应,具备服务降级、熔断、隔离、监控等能力。
- 四种防雪崩方式