SpringCloud的了解和使用
1概述SpringCloud 是一系列框架的有序集合利于SpringBoot 开发的便利性简化了分布式系统基础设施的开发它没有重复造轮子只是将各家公司比较成熟的框架组合起来通过SpringBoot 风格再封装屏蔽复杂的配置和实现原理最终给开发者留下一套简单易懂、易部署、易维护的分布式系统开发包。 SpringCloud 的版本名称伦敦地铁站的名称版本号2SpringCloud 和SpringBoot 的区别与联系1SpringCloud 是一个基于SpringBoot 的云应用开发工具。 2SpringBoot 注重单个微服务SpringCloud 关注服务治理框架。 3SpringCloud 依赖于 SpringBoot 而存在。3SpringCloud 相关组件1. 【服务注册与发现】服务自动注册和发现实现服务间调用 Netflix Eureka---Netflix 组件目前进入维护模式 【Alibaba Nacos】---阿里的国产方案功能强大且社区活跃 【HashiCorp Consul】----非 Netflix 系的主流选择 Spring Cloud Zookeeper--合已使用 ZK 的架构 2. 【API网关】请求路由、统一鉴权、限流熔断 【Spring Cloud Gateway】---基于 Spring WebFlux 的响应式网关现代首选性能优异 Netflix Zuul 1.x---基于 Servlet 的阻塞式网关已进入维护模式不推荐新项目使用 3. 【客户端负载均衡】调用方从注册中心获取服务列表自行选择调用 【Spring Cloud LoadBalancer】---官方首选用于替代已停更的 Netflix Ribbon 4. 【声明式远程调用】声明式 HTTP 客户端 【Spring Cloud OpenFeign】---声明式的 HTTP 客户端简化服务间调用,官方推荐配合 LoadBalancer 使用 【Apache Dubbo】---高性能 Java RPC 框架,在 Spring Cloud Alibaba 生态中支持 5. 【服务容错熔断降级】防止服务雪崩 Spring Cloud Circuit Breaker---统一的熔断器抽象层 API,官方抽象接口 【Alibaba Sentinel】---阿里出品功能远超 Hystrix 【Resilience4J】---轻量级的容错库,推荐设计优雅是 Hystrix 的现代替代品 Netflix Hystrix---著名的经典组件但已停止开发进入维护模式 6. 【分布式配置管理】集中管理配置动态刷新 【Spring Cloud Config】---官方经典方案 【Alibaba Nacos】---动态配置管理,阿里的国产方案提供界面管理支持配置实时生效 7. 【消息驱动与总线】异步解耦 【Spring Cloud Stream】---简化开发可切换 RabbitMQ, Kafka, RocketMQ Spring Cloud Bus---通过轻量级消息代理连接分散的服务,常用于配合 Config 实现配置的动态刷新 Alibaba RocketMQ---阿里出品在特定场景下性能优于 Kafka 8. 【分布式链路追踪】请求链路监控 Spring Cloud Sleuth---为 Spring Cloud 应用提供分布式追踪解决方案,常与 Zipkin, Jaeger 配合使用 9. 安全与密钥管理 Spring Cloud Security---提供 OAuth2、单点登录等安全功能 Spring Cloud Vault---与 HashiCorp Vault 集成安全管理敏感配置 10. 测试与契约 Spring Cloud Contract---支持消费者驱动的契约CDC测试,保障服务间 API 的可靠性 11. 云平台集成 Spring Cloud Kubernetes---适合在 K8s 环境部署的应用 Spring Cloud Alibaba---中国开发者与云环境首选4) 服务注册与发现1. 分client(服务消费者)和server(服务注册者)server 提供注册服务将自己的注册地址(IP端口)注册到注册中心client 可以向server进行注册获取它依赖的其他服务实例列表。 2. 注册中心会通过心跳机制定期检查服务实例的健康状态nacos默认是5S每次eureka默认是30s每次3次监测不到会自动剔除不健康的实例防止请求打到有问题的服务上。5) 网关1. 是微服务架构中的统一入口所有外部请求都先到达网关再由网关路由到后端具体的微服务。 2. 使用网关可以通过访问同一个ip和端口来完成访问不同微服务的需求避免了访问每个微服务都需要有不同ip和端口的问题。 3. 网关的核心功能 1请求路由网关根据请求的路径、域名、Header等信息将请求转发到正确的微服务。 2统一鉴权在网关层集中处理身份认证如JWT验证、OAuth token校验合法请求才放行后端服务可以专注于业务逻辑。 3限流熔断 限流限制每个用户/IP在单位时间内的请求次数防止恶意攻击或突发流量冲垮系统如每秒最多100次。 熔断当某个后端服务持续失败时网关快速返回降级响应避免故障扩散。 4日志监测在网关层统一记录所有请求的日志请求路径、耗时、状态码等便于监控和问题排查。 5跨域处理统一配置CORS策略所有微服务无需单独处理跨域问题。 6协议转换客户端发送HTTP请求网关转成gRPC给后端服务。6) 负载均衡1. 将用户请求分摊到多个服务器上执行从而扩展系统处理能力提高可用性的核心技术。 2. 常见的负载均衡策略有轮询、加权轮询、最少连接、IP哈希随机等。7) 远程调用1. 远程调用是允许一个程序调用另一个地址空间(通常是不同服务器)的函数或者方法就像调用本地方法一样的技术。 2. 远程调用的作用 1解耦服务之间通过网络调用不直接依赖对方的代码实现。 2分布式可以跨越不同的服务器、数据中心、甚至云平台。 3抽象网络细节开发者像调用本地方法一样调用远程服务无需手写Socket、HTTP等底层代码。 3. 远程调用分类 按照通信协议可以分为 1HTTP/REST 常见技术Spring RestTemplate、OpenFeign、WebClient。 特点轻量、跨语言、易调试、基于HTTP协议通常使用 JSON 作为数据格式。 2RPC 框架 常见技术Dubbo、gRPC、Thrift。 特点性能高、通常需配合注册中心、跨语言支持各异。封装了底层通信细节通常支持 TCP 协议、二进制序列化如 Hessian、Protobuf。 4. 核心流程代理 → 序列化 → 网络传输 → 反序列化 → 执行 → 返回。 5. 常见问题与处理方案 1网络延迟跨网络调用比本地调用慢几十到几百毫秒。 处理方案 合理设置超时、异步调用、减少调用次数。 2服务故障被调服务可能宕机或响应慢。 处理方案熔断Sentinel/Hystrix、重试、降级。 3数据一致性分布式环境下难以保证强一致性。 处理方案分布式事务Seata或最终一致性方案。 4链路追踪调用链路复杂难以定位问题。 处理方案分布式链路追踪SkyWalking、Zipkin。 5序列化性能序列化/反序列化耗时。 处理方案选用高效序列化协议Protobuf、Kryo。 6版本兼容接口变更可能导致调用失败。 处理方案接口版本管理、灰度发布。8) 熔断降级1. 微服务中通常会有多个服务之间的相互调用如果某个微服务出现了故障会造成服务雪崩导致整个系统不可用。 2. 熔断降级是微服务架构中的自我保护机制。当某个服务出现故障或者响应过慢时系统不会再等待或者反复重试而是快速失败或者执行备选方案防止故障像雪崩一样扩散到整个系统。 3.熔断器能够在服务失效的时候通过隔离失效的服务来防止级联失效服务修复后熔断器会关闭使系统更快恢复正常。 4. 熔断当下游服务故障达到一直阈值时自动切断对其的调用快速失败。【防止故障像雪崩一样向上游服务扩散】。 降级当熔断触发或者系统高负载时执行替代方案(如返回默认值、缓存数据等)来提供有损服务。【牺牲非核心功能保证核心业务的基本可用性】。 5. 核心技术通过一个名为熔断器的状态机在不同状态间切换来自动管理服务调用。 1关闭状态(正常工作)熔断器的初始状态放行所有请求并暗中统计调用结果(如 失败率、慢调用比例)一旦统计指标超过预设的阈值熔断器就会跳闸进入打开状态。 2打开状态(熔断中)在词状态下所有对该服务的调用都会被直接拒绝并立即执行降级逻辑不在发起远程调用。这个状态会持续一个休眠时间窗让故障服务有时间恢复。 3半开状态(服务探测)休眠时间窗结束后熔断器会进入半开状态他像一个哨兵只放行少量探测请求去尝试调用下游服务如果这些请求成功说明下游服务已经恢复熔断器就切回关闭状态如果失败熔断器再次回到打开状态继续熔断。 6. 熔断策略 1慢调用比例统计窗口中超过响应时间阈值(比如 1s)的请求比例。这是生产环境首选能提前预防线程阻塞。 2异常比例统计窗口中系统级异常(如超时、网络异常)的比例。注意排除业务异常避免误判。 3异常数量统计窗口中异常发生的绝对数量。 7. 降级方案 1兜底数据降级当服务不可用时返回静态默认值或者本地/分布式 缓存 的旧数据。 2快速失败降级熔断触发后直接返回一个友好的失败提示或者抛出特定业务异常。 3功能降级开关大促或者高负载前通过配置中心动态关闭非核心功能。9) 配置管理1. 是系统稳定的基石通过利用代码和自动化来标准化管理IT系统核心目标是确保所有环境(开发、测试、生产)的配置都一致。可靠、可追溯。 2. 作用 1消除配置漂移系统能自动检测并修复与预期状态的偏差保证所有环境配置一致 2让系统更可靠通过自动化避免人为失误配置变更可审计、可回滚让系统行为更稳定。 3提升团队效率开发、测试、运维环境能快速复制文档实时更新部署更快捷。 4确保合规安全完整的变更记录和审批流程能轻松满足合规审计要求并有效管控敏感信息。10) 消息驱动与总线1. 消息驱动(做什么) 定义一种架构风格系统组件之间通过发送和接收消息来通信而不是直接调用。 特点异步、解耦、可靠。发送方不需要等待接收方响应系统弹性更好。 2. 消息总线(用什么做通常指消息中间件) 定义一种中间件架构。它是一条逻辑上的“总线”所有应用都连接到它通过它来订阅、发布或接收消息。 特点集中路由、多对多通信。总线负责消息的分发、过滤、转换。 3. 常见消息总线 Kafka 高吞吐、持久化强、支持流处理。 日志收集、大数据分析、事件溯源。 RabbitMQ 功能丰富、稳定可靠、支持复杂路由。 传统企业应用集成、任务分发、后台作业。 RocketMQ 阿里出品低延迟、高可用。 金融级交易、订单处理、实时同步。 ActiveMQ 老牌支持多种协议。 传统Java应用中。 Pulsar 云原生存储计算分离多租户。 对多租户和弹性有高要求的场景。11) 链路监控1. 核心作用还原一个请求在多个服务之间的完整调用路径方便在错综复杂的服务网络中一眼看清服务在哪里耗时在哪里报错。 2. 常用方案 1JaegerUber开源CNCF毕业项目兼容OpenTelemetry。存储后端灵活(Cassandra/ES)UI强大。适用云原生/K8s环境如果你在用IstioJaeger几乎是标配。 2ZipkinTwitter开源老牌方案稳定可靠。轻量级部署简单Spring Cloud Sleuth默认支持。适用Spring Cloud生态中小规模系统。 3SkyWalking国产开源Apache顶级项目。性能极强对Java生态支持最好自带应用性能监控与告警。适用大型Java微服务希望一个系统同时解决链路监控和应用性能监控。 4Pinpoint韩国Naver开源。代码无侵入统计信息粒度极细能到方法级别。适用对代码侵入零容忍需要精细化分析方法级别耗时。 3. 技术选型 1中小规模 /Spring CloudZipkin Sleuth 足够轻量省事。 2大规模Java/要应用性能监控一体化SkyWalking 是国产优选。 3K8s/Istio云原生Jaeger OpenTelemetry 是标准答案。