2.1 java面试题：说一说springcloud 的组件作用和各个组件之间是如何写作的。

好的根据你最近的深入学习Nacos、Sentinel、OpenFeign、Gateway等和银行核心背景我为你准备了四个版本的答案。面试官通过这个问题表面上问组件协同实际上在考察你对微服务架构的整体理解深度。一、初级回答会用框架能说清基本流程回答要点能说出各个组件是干什么的以及一个请求的基本流转路径。“我用过 Spring Cloud Alibaba 这套微服务框架。各个组件是这样协同的首先服务提供者启动时会把自己的服务名、IP 和端口注册到Nacos 注册中心。服务消费者启动时去 Nacos 订阅它需要的服务拉取提供者的地址列表并缓存到本地。当消费者需要调用提供者时它不用写具体的 IP而是通过OpenFeign声明一个接口用服务名去调用。OpenFeign 会从本地缓存的服务列表里通过Ribbon或 LoadBalancer的负载均衡策略比如轮询选出一个具体的提供者实例然后把 HTTP 请求发过去。外部的请求是先经过Gateway 网关的网关从 Nacos 拿到所有路由的服务列表也做一次负载均衡然后把请求转发给对应的微服务。网关还负责鉴权、限流这些公共功能。总结就是注册中心负责管理地址网关负责统一入口OpenFeign 负责简化调用Ribbon 负责负载均衡。”二、中级回答能讲清细节结合实际配置回答要点能讲出具体的配置方式、负载均衡策略以及能解决什么生产问题。“我们银行核心系统用的是 Spring Cloud Alibaba 全套我来结合一个典型的交易链路说一下。1. 服务注册与发现所有的微服务比如存款服务、贷款服务启动时通过spring.cloud.nacos.discovery配置自动注册到 Nacos 集群。我们会配置namespace做环境隔离group做业务分组还会给实例打上cluster-name实现就近调用。2. 网关层路由与负载均衡外部请求先到Spring Cloud Gateway。Gateway 本身也是从 Nacos 拉取服务列表它内置的ReactiveLoadBalancerClientFilter会用 Spring Cloud LoadBalancer 做第一次负载均衡。我们在这里配了限流Sentinel 集成和鉴权GlobalFilter。3. 内部服务间调用比如网关把请求转发给deposit-servicedeposit-service需要调用loan-service时我们使用OpenFeign。定义FeignClient(name loan-service, fallbackFactory ...)接口OpenFeign 代理内部会调用 LoadBalancer 做第二次负载均衡选出一个loan-service的实例发 HTTP 请求。我们配置了超时、重试并且写操作禁用重试防止资金风险。4. 负载均衡是谁做的负载均衡分两层服务端负载均衡在网关层客户端负载均衡在服务间调用。都是通过 Spring Cloud LoadBalancer 实现的策略默认是轮询我们可以通过配置文件改成加权、随机或者自定义基于权重的策略来配合灰度发布。5. 高可用与容错如果某个loan-service实例挂了Nacos 的心跳检测会把它剔除推送更新给所有消费者。同时我们集成了Sentinel当调用失败率过高时自动熔断返回兜底数据保护系统。”三、高级回答能剖析原理结合源码和异常处理回答要点能讲出底层原理如 OpenFeign 动态代理、Nacos 心跳机制并能画出调用链的异常处理策略。“我深入看过 Spring Cloud Alibaba 的核心源码可以讲一下协同运作的底层原理。注册中心 Nacos 的 AP/CP 双模式我们的核心服务使用持久实例CP 模式Raft 协议保证服务列表强一致非核心服务使用临时实例AP 模式Distro 协议依靠心跳上报。Nacos 客户端每 5 秒发送心跳服务端 15 秒无心跳标记不健康30 秒剔除。消费者通过定时拉取6秒和 UDP 推送来同步变更。OpenFeign 的动态代理机制当调用FeignClient接口时Spring 容器生成 JDK 动态代理对象。代理内部将方法调用构造成RequestTemplateURL、参数、请求体然后交给 LoadBalancer 选择实例替换服务名为真实 IP。底层 HTTP 客户端我们替换成了OkHttp支持连接池和 HTTP/2提升性能。负载均衡的源码级细节LoadBalancer 的ServiceInstanceListSupplier从 Nacos 拿到列表后经过RoundRobinLoadBalancer默认或我们自定义的GrayLoadBalancer做选择。我们的灰度路由是通过 Nacos 元数据version实现的网关和服务间调用都支持。异常处理与自愈我们自研了一个HealthChecker服务定时扫描所有实例的/actuator/health连续失败时通过 Nacos API 将实例下线enabledfalse实现自动摘流。再配合 Sentinel 的降级规则比如慢调用比例超过 50% 就熔断返回缓存数据。分布式事务的协调在放款流程这种跨服务调用中我们用Seata TCC保证一致性。Feign 调用作为分支事务参与全局事务由 Seata Server 协调。通过GlobalTransactional发起各个服务的 Try/Confirm/Cancel 接口通过 Feign 调用保证资金安全。”四、资深回答能从架构角度对比选型讲出设计理念和权衡回答要点能跳出单一框架讲出 Dubbo 与 Spring Cloud 的选型决策依据以及架构演进中的取舍和实际挑战。“你这个问题本质是在问微服务治理体系的架构设计我结合我们银行真实演进来谈。1. 架构选型为什么内部 RPC 用 Dubbo对外用 Spring Cloud我们核心交易链路存款、贷款、账务全部采用Dubbo Zookeeper后期迁到 Nacos。Dubbo 的自定义二进制协议 Netty 长连接比 HTTP 性能高数倍而且服务治理能力更强动态路由、权重、分组。ZK 提供强一致的注册中心保证服务列表绝对正确。而对外合作方的 OpenAPI我们用Spring Cloud Gateway OpenFeign因为 HTTP 普适性好易于对接。这是典型的“内循环高性能外循环标准化”的架构。2. 负载均衡的分层设计我们设计了四层负载L4 层F5/云 SLB对外入口。网关层L7Spring Cloud Gateway 的 LoadBalancer做跨服务的路由和灰度引流。客户端层Dubbo 的RandomLoadBalance加权随机避免热点或LeastActiveLoadBalance最小活跃数均衡耗时。数据层Redis Cluster 的 slot 分片也是一种负载。3. 协同运转的核心挑战与解决注册中心脑裂ZooKeeper 靠过半机制Nacos CP 模式用 Raft。我们为 ZK 配置了奇数节点并定期演练故障切换。推送延迟Nacos 1.x UDP 推送可能丢包2.x 用 gRPC 双向流彻底解决。我们在交易服务中强制要求升级到 Nacos 2.x保证变更通知秒级生效。雪崩预防即使有 Sentinel 熔断我们仍为核心接口如扣款配置了内存级限流防止刚重启时 Sentinel 规则未加载的窗口期被打挂。4. 架构演进中的思考早期我们用 Spring Cloud Gateway OpenFeign 全部微服务后来发现内部调用的延迟和吞吐无法满足核心交易要求于是将核心链路下沉到 Dubbo网关层仍保留 HTTP。这就是“多协议、分级治理”的思路。现在也在尝试 Service MeshIstio将负载均衡、重试、熔断等能力下沉到 Sidecar让应用更轻量。”面试建议你可以根据面试官的层次和职位要求选择合适的版本。但无论哪个版本都要结合自己银行的实际案例让回答有血有肉。比如“我们放款流程中通过 Feign 调核心账务配置了超时和 Sentinel 降级防止雪崩”这样最具说服力。在微服务和分布式架构中负载均衡的策略决定了请求如何被分配到不同的服务实例上。下面我从策略分类、典型算法、适用场景、以及 Dubbo/Spring Cloud 中的落地帮你梳理清楚。一、常见负载均衡策略一览策略核心思想优点缺点适用场景轮询 (Round Robin)按顺序依次分配简单、绝对均衡不考虑服务器性能差异同规格实例、无状态服务随机 (Random)完全随机挑选简单统计上均衡可能短期内分配不均同轮询略有概率倾斜加权轮询/加权随机给不同实例配权重按权分配能根据性能分配流量权重需要人工维护实例配置不同如 CPU、内存最小活跃数 (Least Active)选择当前处理请求最少的实例动态均衡避免堆积需实时统计每个实例的活跃数长连接、耗时不一的接口一致性哈希 (Consistent Hash)将请求参数如用户ID哈希到固定节点相同请求总是落到同一实例扩缩容影响小可能负载不均衡有状态服务、缓存、需要粘性最快响应时间 (Weighted Response Time)统计平均响应时间给快的实例更高权重自动适应性能变化统计窗口可能引起波动服务质量波动较大的场景二、在 Dubbo 和 Spring Cloud 中的对应实现1. Dubbo 中的负载均衡Dubbo 提供了四种内置策略可以通过DubboReference(loadbalance xxx)或 XML 配置。Dubbo 策略对应算法说明random(默认)加权随机按权重随机权重相同则纯随机roundrobin加权轮询平滑加权轮询避免简单加权轮询的突刺问题leastactive最小活跃数优先选活跃数最小的差值相同时按加权随机选consistenthash一致性哈希按方法参数默认第一个参数做哈希相同参数总发同一实例2. Spring Cloud 中的负载均衡早期用 Ribbon现在默认是Spring Cloud LoadBalancerFeign、Gateway 均集成它。LoadBalancer 实现对应策略RoundRobinLoadBalancer(默认)轮询RandomLoadBalancer(需自定义)随机自定义ReactorServiceInstanceLoadBalancer加权、最小活跃、一致性哈希等配置示例修改 Feign 的负载均衡策略spring:cloud:loadbalancer:ribbon:enabled:false# 关闭 Ribbon使用 LoadBalancerdiscovery:client:simple:instances:loan-service:-uri:http://10.0.0.1:8080metadata:weight:8-uri:http://10.0.0.2:8080metadata:weight:2然后编写自定义LoadBalancer实现加权随机。三、银行场景下的策略选择在银行核心系统中我们根据交易类型和实例性能做了精细化的负载均衡无状态查询余额、利率使用加权轮询。因为实例性能经基准测试已明确提前配好权重稳定且均衡。耗时波动大的接口征信、反洗钱使用最小活跃数。避免某些实例因第三方调用卡顿而堆积请求。需要粘性的场景合约状态机、会话缓存使用一致性哈希以用户ID或合同号作为哈希键保证同一用户的多次请求落到同一实例提高缓存命中率。灰度发布自定义基于元数据的路由。通过在 Nacos 元数据中标记version2.0让网关或 LoadBalancer 只把特定用户流量引导到新版本实例上。四、面试话术“负载均衡的常用策略有轮询、随机、加权、最小活跃数和一致性哈希。Dubbo 默认是加权随机Spring Cloud LoadBalancer 默认是轮询。在银行核心系统里无状态查询我们用加权轮询长耗时接口用最小活跃数避免堆积需要粘性的会话或状态机用一致性哈希。灰度发布则是自定义了基于元数据的路由策略。选型关键是看接口特性有无状态、耗时是否稳定、要不要粘性。”这样回答既全面又具体还能结合你的实际工作场景。