三、SpringCloud入门概述1. 什么是微服务1. 为什么要使用微服务1. 微服务的优缺点是什么说说你在项目开发中遇到的坑1. SpringCloud和SpringBoot的关系SpringBoot专注于开苏方便的开发单个个体微服务SpringCloud是关注全局的微服务协调整理治理框架它将SpringBoot开发的一个个单体微服务整合并管理起来为各个微服务之间提供配置管理、服务发现、断路器、路由、为代理、事件总栈、全局锁、决策竞选、分布式会话等等集成服务SpringBoot可以离开SpringCloud独立使用开发项目但SpringCloud离不开SpringBoot属于依赖关系SpringBoot专注于快速、方便的开发单个个体微服务SpringCloud关注全局的服务治理框架2. 微服务技术栈组件请求 → 网关入口 → 注册中心找服务 → 负载均衡分发选实例 → Feign调用 → 熔断保护兜底全程配置由配置中心管理配置中心管配置 微服务核心全家桶所有外部请求浏览器/APP先到 Gateway做路由、鉴权、限流、日志再转发到对应服务【统一入口服务网关Gateway】-- Gateway/调用方 从 注册中心 拉取目标服务的可用实例列表【服务发现注册中心Nacos/Eureka】-- 从实例列表中按策略轮询/随机选一个实例确定 IP端口 【负载均衡LoadBalancer】-- 用 HTTP 调用目标服务接口Feign 更常用像本地方法【服务调用Feign/RestTemplate】-- 调用失败/超时达到阈值触发熔断/降级快速失败防止雪崩【熔断保护Resilience4j/Sentinel】-- 所有组件/服务的配置超时、限流规则、路由规则从配置中心读取支持动态刷新【配置支撑配置中心 Nacos/Config】开发搭建顺序从0到11.先搭注册中心 配置中心Nacos 二合一2. 写服务提供者注册到注册中心3. 写服务消费者用 Feign LoadBalancer 调用提供者4. 加 熔断 保护调用链路5. 最后配 Gateway 统一对外入口。服务网关统一入口Spring Cloud Gateway主流、Zuul旧版作用路由转发、鉴权、限流、日志、跨域地位所有外部请求的“大门”。服务注册与发现核心底座Nacos主流/Eureka/Zookeeper/Consul作用服务注册、服务发现、健康检查地位所有微服务的“通讯录”没有它服务间找不到彼此。负载均衡流量分发Spring Cloud LoadBalancer官方、Ribbon旧版作用把请求均匀分给多实例避免单点压力地位Feign/RestTemplate 内置默认轮询。服务调用通信核心OpenFeign首选、REST(RestTemplate)、RPC、gRPC作用服务间 HTTP 调用Feign 是声明式、像本地方法一样调用地位微服务通信的“电话线”。熔断降级容错保护Resilience4j官方、Sentinel阿里、Hystrix旧作用服务雪崩防护、熔断、降级、限流地位微服务的“保险丝”配置中心统一配置Nacos主流、Spring Cloud Config作用集中管理配置、动态刷新、环境隔离地位所有服务的“配置管家”。3. SpringCloud和dubbo的区别是什么Dubbo 和 SpringCloud对比DubboSpringCloud服务注册中心ZookeeperNacos(主流)、Eureka、Zookeeper、Consul服务调用方式RPCREST API服务网关无Spring Cloud Gateway(主流)、Zuul(旧版)服务监控Dubbo-monitorSpring Boot Admin断路器不完善Resilience4j(官方)、Sentinel(阿里)、Hystrix(旧)分布式配置无Nacos(主流)、Spring Cloud Config服务跟踪无Spring Cloud Sleuth消息总栈无Spring Cloud Bus数据流无Spring Cloud Stream批量任务无Spring Cloud Task最大区别Spring Cloud 抛弃了Dubbo的RPC通信采用的是基于HTTP的REST方式4. 作为服务注册中心Eureka比Zookeeper好在哪里4. Eureka、Nacos、Zookeeper服务注册中心比较Eureka、Nacos、Zookeeper作为 Spring Cloud 服务注册中心核心差异体现在一致性模型、功能生态、CAP 取舍、健康检查与易用性上以下是结构化对比与选型建议1.CAP 与一致性EurekaAP优先保证可用性网络分区时仍能注册/发现数据最终一致适合对可用性要求高、允许短暂不一致的场景Nacos注册中心选 AP高可用配置中心选 CP强一致兼顾可用性与配置准确性灵活适配业务ZookeeperCP强一致性优先写操作需过半节点确认网络分区时不可写适合对数据一致性要求极高的场景如分布式锁。CAP定理CAP 三要素CConsistency 一致性所有节点同一时间数据完全一致读操作总能拿到最新写结果。AAvailability 可用性服务始终可用任何请求都能得到响应不保证是最新数据。PPartition Tolerance 分区容错性网络分区节点间断连时系统仍能正常工作。1️⃣ AP 和 CP 是分布式系统中 CAP 定理 的两个核心选择AP 与 CP 的核心定义1. AP高可用优先牺牲强一致性保证可用性分区容错。网络分区时服务不中断允许数据短暂不一致最终一致。对应注册中心Eureka、Nacos 注册中心模式。2. CP强一致优先牺牲部分可用性保证一致性分区容错。网络分区时为保证数据一致会阻塞写操作或拒绝请求直到分区恢复。对应注册中心Zookeeper、Nacos 配置中心模式。2️⃣ 结合注册中心的通俗理解APEureka哪怕部分节点断连新服务仍能注册、客户端仍能发现服务只是可能读到旧数据不影响业务运行。CPZookeeper网络分区时为保证所有节点数据完全一致会暂停服务注册/发现直到数据同步完成优先保证数据准确。3️⃣ 简单说AP 求“能用”CP 求“准”注册中心选 AP 是为了服务不中断选 CP 是为了数据不差错。2.健康检查机制Eureka客户端定时发心跳服务端未收到则标记下线无主动探测服务假死时发现延迟高Nacos支持客户端心跳服务端主动探测TCP 端口、HTTP 接口、MySQL 连通性下线更及时还支持优雅上下线Zookeeper基于临时节点客户端断连节点自动删除实时性强但频繁上下线易引发性能问题。3. 功能与生态Eureka纯注册中心无配置管理功能极简依赖 Spring Cloud 其他组件补全能力。Nacos一体化解决方案同时支持服务注册发现与配置中心支持动态配置推送、权重路由、灰度发布适配微服务全场景。Zookeeper分布式协调底座注册是衍生能力需搭配 Spring Cloud Config 等做配置管理开发运维成本高。4. 集群与性能EurekaPeer to Peer 集群节点对等扩容简单无主从写性能高但数据同步延迟大NacosRaft 集群主从架构支持多集群、多环境隔离性能均衡适合大规模集群ZookeeperZAB 协议集群需奇数节点写性能随节点数增加下降读性能高适合读多写少场景。Eureka、Nacos和 Zookeeper 对比维度EurekaNacosZookeeperCAP原则AP高可用可切换注册中心AP、配置中心CPCP强一致数据一致性最终一致允许短暂不同步注册最终一致强一致同步阻塞健康检查客户端心跳服务端被动客户端心跳服务端主动探测(TCP/HTTP/MySQL)临时节点断点自动删除核心定位纯服务注册、发现服务注册发现配置中心一体化分布式协调服务注册是能力之一一致性协议无Peer to Peer复制注册中心Raft、配置中心RaftZAB协议集群容错某节点挂了其他节点继续服务集群高可用支持多地域过半写机制节点数需奇数1. Spring Cloud 中的注册中心Eureka五、Eureka 服务注册中心Spring Cloud 中的注册中心是微服务架构里用于管理所有服务实例的注册、发现与健康状态的核心组件。它的核心作用分为三点1.服务注册各个微服务启动后会将自己的服务名称、IP 地址、端口号等信息上报到注册中心。2.服务发现当服务需要调用其他服务时无需硬编码目标服务地址而是从注册中心查询目标服务的可用实例列表。3.健康监测注册中心会定期检测服务实例的存活状态剔除故障实例避免请求被路由到不可用的服务上。Spring Cloud 常用的注册中心有 Eureka、Nacos、Consul 等其中 Nacos 还兼具配置中心的功能。2. Spring Cloud 中的服务调用方式Spring Cloud 中的服务调用方式指的是微服务架构下不同服务实例之间实现远程通信、调用对方接口的具体技术方案与模式。主流的服务调用方式主要有两种1.基于 REST 的同步调用以 RestTemplate 或 WebClient 为核心工具结合服务注册中心如 Eureka、Nacos实现服务发现直接通过 HTTP 协议调用目标服务的 REST 接口适用于大多数同步通信场景。2. 基于 RPC 的高效调用以 Feign声明式 HTTP 客户端为代表底层本质还是 HTTP但封装了接口定义、负载均衡等能力调用方式更像本地方法也可集成 Dubbo 等 RPC 框架通过自定义协议实现更高性能的服务调用。5. Spring Cloud 负载均衡Spring Cloud 里的负载均衡Load Balancing就是把请求均匀分发到同一个服务的多个实例上避免单点压力过大同时提高可用性。核心作用• 分摊流量防止单个实例被压垮• 故障自动剔除请求只发给健康实例• 提升系统吞吐量与容错能力两种模式• 服务端负载均衡如 Nginx请求先到统一网关/代理由它转发到后端客户端只认一个入口地址• 客户端负载均衡Spring Cloud 主流客户端从注册中心拿到服务实例列表本地按策略选一个实例直接调用代表组件LoadBalancer / Ribbon旧版常见负载均衡策略• 轮询Round Robin依次轮流徐浩一• 随机Random随机选一个• 权重Weighted按配置权重分配• 最少连接Least Connections选连接数最少的• 基于响应时间Response Time选响应快的与前面的组件关系• RestTemplate加 LoadBalanced 注解即可开启• Feign默认集成负载均衡直接用服务名调用• Gateway路由时自动对目标服务做负载均衡一句话记负载均衡就是“把请求分给多台机器谁闲给谁谁好给谁”。4. Spring Cloud 中服务调用方式 Rest 和服务接口调用 Feign 区别在 Spring Cloud 里RestRestTemplate 和 Feign 本质都是 HTTP 调用但写法、易用性、功能封装差很多实际项目基本都用 Feign。下面用最清晰的对比帮你区分4.1. 写法与体验最直观区别:• RestTemplate1.手动拼 URL、参数、请求头、响应解析2.代码偏“底层”像原生 HTTP 调用3. 示例Stringurlhttp://service-provider/user/userId;UseruserrestTemplate.getForObject(url,User.class);• Feign1.写一个接口 注解像调用本地方法2.自动拼接 URL、参数、序列化/反序列化3. 示例FeignClient(service-provider)publicinterfaceUserClient{GetMapping(/user/{id})UsergetUserById(PathVariable(id)Longid);}// 调用UseruseruserClient.getUserById(userId);4.2. 服务发现与负载均衡• RestTemplate需要配合 LoadBalanced 注解才能用服务名调用• Feign内置集成 Ribbon/LoadBalancer直接写服务名即可自动负载均衡4.3. 功能封装Feign 更强•Feign 天然支持1.声明式请求GET/POST/PUT/DELETE2.路径/查询/表单/JSON 参数自动处理3.请求/响应拦截器4.超时、重试配置5.与 Hystrix/Sentinel 集成做熔断降级• RestTemplate这些都要自己写或额外配置4.4. 适用场景• RestTemplate简单调用、临时调用、不想引入 Feign 依赖时• Feign微服务架构标准用法服务间大量调用、复杂接口、团队协作首选一句话总结 RestTemplate手动 HTTP 调用灵活但繁琐 Feign声明式、注解驱动、像本地方法一样调用服务生产环境主流。5. RestTemplate LoadBalancer负载均衡的例子核心配置开启负载均衡ConfigurationpublicclassRestTemplateConfig{/** * 加上 LoadBalanced 注解RestTemplate 就具备负载均衡能力 * 调用时直接用服务名不用写具体 IP:端口 */BeanLoadBalancedpublicRestTemplaterestTemplate(){returnnewRestTemplate();}}调用示例直接用服务名RestControllerpublicclassConsumerController{AutowiredprivateRestTemplaterestTemplate;/** * 调用名为 service-provider 的服务 * 格式http://服务名/接口路径 */GetMapping(/user/{id})publicStringgetUser(PathVariableLongid){Stringurlhttp://service-provider/user/id;returnrestTemplate.getForObject(url,String.class);}}3.依赖Spring Cloud LoadBalancer!--SpringCloudLoadBalancer依赖SpringCloud2020推荐--dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-loadbalancer/artifactId/dependency!--若使用Nacos/Eureka注册中心需引入对应依赖--dependencygroupIdcom.alibaba.cloud/groupIdartifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId/dependency关键说明• 加 LoadBalanced 后RestTemplate 会自动从注册中心获取服务实例列表• 调用时用 http://服务名/接口 格式框架自动做负载均衡默认轮询策略• 无需手动处理 IP、端口也不用关心服务实例数量变化8. REST 和 RPC对比4. 负载均衡的意义是什么5. 微服务之间是如何独立通讯的6. springcloud如何实现服务的注册7. Eureka和Zookeeper的区别8. Eureka的自我保护机制是什么10. 什么是Ribbon10. Ribbon负载均衡能干嘛11. 什么是Feign优点是什么12. Feign和Ribbon区别13. 什么是Spring Cloud Bus9. 什么是Hystrix9. 服务降级和服务熔断9. SpringCloud断路器的作用Spring Cloud 断路器Spring Cloud 中的断路器Circuit Breaker是微服务架构中防止服务雪崩的核心保护机制核心作用是快速失败、避免级联故障。核心原理3种状态1.闭合Closed服务正常请求正常通过2.打开Open服务异常超时/报错达到阈值断路器打开直接拒绝请求快速失败3.半开Half-Open打开一段时间后尝试放行少量请求若成功则闭合失败则重新打开主要功能• 熔断故障时切断调用防止请求堆积• 降级熔断时返回预设兜底数据如默认值、缓存保证系统可用• 限流控制并发请求量保护服务不被压垮• 监控统计异常、成功率、响应时间辅助定位问题主流实现• Resilience4jSpring Cloud 2020 官方推荐轻量、响应式• Sentinel阿里开源流量控制、熔断降级、系统保护一体化• HystrixNetflix 开源已停止维护老项目常用一句话总结断路器就像电路里的保险丝服务出问题时“跳闸”保护整体等恢复后再“合闸”避免一个服务挂掉拖垮整个微服务集群。15. 什么是SpringCloudConfig15. 分布式配置中心能干嘛16. 什么是SpringCloud Gateway17. 什么是Zuul路由网关Spring Cloud 中的服务网关Spring Cloud 中的服务网关是微服务架构的入口组件统一接收并转发客户端请求同时提供路由、过滤、限流等核心能力。它的主要作用包括1.路由转发根据请求路径或规则将请求精准路由到对应的微服务实例。2.统一过滤集中处理鉴权、日志记录、跨域、请求/响应转换等通用逻辑避免每个服务重复开发。3.流量管控实现限流、熔断、降级保护后端服务不被高并发压垮。4.服务聚合将多个微服务的接口聚合为一个接口对外提供简化客户端调用逻辑。Spring Cloud 主流的网关组件有 Gateway基于 WebFlux非阻塞和 Zuul基于 Servlet阻塞Gateway 是目前更推荐的选型。