【SpringCloud系列01】从单体到微服务架构演进与SpringCloud全景图个人主页夏天拐跑了西瓜专栏传送门《大模型应用开发》、《Spring 生态全家桶体系化实战》学习方向Java 后端AI‑Agent 大模型应用开发爱好者⭐人生格言路虽远行则将至本文是SpringCloud系列第一篇带你搞懂微服务是什么、为什么要用微服务以及SpringCloud全家桶都有哪些组件。文末附高频面试题。一、为什么需要微服务作为Java开发者相信你或多或少都遇到过这样的场景项目刚上线时功能简单一个war包打天下部署快、改起来爽业务迭代半年后模块越来越多代码几十万行改一行代码心惊胆战团队从3个人扩到10个人大家都在同一个工程里提交代码冲突不断大促期间想给订单模块加机器结果只能整个应用一起扩容浪费资源某个边缘功能出了OOM整个系统跟着挂如果你也遇到过以上任何一个问题说明项目已经到了该考虑微服务的时候。这篇文章不着急写代码先从架构演进的历史聊起搞清楚微服务的来龙去脉。二、架构演进的三个阶段软件架构不是银弹而是随着业务规模逐步演化的。从互联网发展至今后端架构大致经历了三个阶段2.1 单体架构Monolithic什么是单体架构所有功能模块打包在一个工程里最终生成一个jar或war包部署运行。比如一个电商项目用户、商品、订单、支付、后台管理全写在一个项目里。我早年参与过一个网约车项目最开始乘客端、司机端、订单、消息、地图全在一个工程里启动一次要3分钟改个小功能也要全量部署。单体架构的优点开发简单IDE跑起来就完事测试方便本地启动就能调部署容易一个包扔到Tomcat就行适合项目初期快速试错、MVP验证单体架构的痛点重点面试常问痛点具体表现复杂性高代码量从几万涨到几十万行模块边界模糊新人上手要几周技术债务“不坏不修”老代码没人敢动人员流动后更是雪上加霜部署困难改一行文案也要全量打包部署上线窗口越缩越长形成恶性循环可靠性差一个小功能OOM整个进程挂掉所有功能都不能用扩展受限订单模块需要扩容但只能整个应用一起加机器资源浪费阻碍创新想把Spring MVC换成WebFlux几十万行代码改不起想试试Go写某个高性能模块门都没有一句话总结小项目用单体真香大项目用单体要命。2.2 面向服务架构SOA为了解决单体的问题业界提出了SOAService-Oriented Architecture面向服务架构。SOA的核心思想是把系统拆分成多个服务服务之间通过网络调用用服务编排来实现业务流程。SOA通常会引入ESB企业服务总线来做服务之间的通信和转换常见的ESB有WebService、Dubbo早期版本等。但SOA有个问题它更多是传统企业级的架构思路ESB本身很重服务拆分粒度也比较粗很多时候拆完发现还是个大单体。可以说SOA提出了很好的理念但落地成本高没有在互联网公司大规模流行开来。2.3 微服务架构Microservices微服务是SOA思想的一种更轻量、更彻底的实践。微服务架构 80%的SOA服务思想 100%的组件化架构思想Martin Fowler在2014年发表的《Microservices》一文中给微服务下了这样的定义大意微服务是一种架构风格将单个应用程序开发为一组小型、独立的服务每个服务运行在自己的进程中服务间通过轻量级机制通常是HTTP REST API通信。这些服务围绕业务能力构建通过自动化部署机制独立部署可以用不同的编程语言编写使用不同的数据存储技术。打个通俗的比方单体架构像一个大锅饭所有人吃一锅菜咸淡没法调微服务像自助餐每个菜独立盛盘想吃啥拿啥凉了单独换网上还有个很形象的分封制类比服从天子命令 → 接受注册中心统一管理镇守疆土 → 各自负责一块业务随从作战 → 服务之间相互调用交纳贡献 → 共同分担系统流量三、微服务的核心特性一个真正的微服务架构应该具备以下特点服务独立进程每个服务跑在自己的JVM/容器里互不影响围绕业务拆分按领域模型或业务能力拆分不是按技术层拆分轻量级通信服务间用HTTP/REST、gRPC、消息队列等通信不绑定语言独立部署每个服务可以单独上线不依赖其他服务发布节奏技术栈自由Java写业务、Go写网关、Python写数据分析各取所长数据去中心化每个服务管理自己的数据库不共享数据库自动化运维服务多了必须靠自动化CI/CD、容器化是标配四、微服务的优缺点4.1 优点独立部署低耦合改订单服务不影响用户服务上线风险小易于开发维护每个服务代码量少业务聚焦新人上手快启动速度快一个服务可能就几千行代码启动几秒钟按需伸缩大促时只给订单、商品服务加实例省成本技术栈灵活可以根据场景选最合适的技术比如用AI推荐服务用Python容错性好一个服务挂了不会拖垮整个系统配合熔断降级团队分工明确两个披萨团队6-10人负责一个服务职责清晰代码复用基础服务可以通过接口被多个上层服务复用4.2 缺点没有银弹微服务不是免费的午餐它解决了单体的问题但也引入了新的复杂度分布式系统复杂性网络是不可靠的延迟、丢包、分区服务调用链变长排查问题困难需要处理超时、重试、幂等等问题分布式事务难题每个服务有自己的数据库跨服务事务不能用本地事务解决方案2PC、TCC、本地消息表、Saga、最大努力通知业界主流是柔性事务 最终一致性BASE理论面试题什么是BASE理论Basically Available基本可用故障时允许部分功能不可用保证核心功能Soft state软状态允许数据存在中间状态Eventually consistent最终一致性一段时间后数据达到一致不需要实时一致接口调整成本高改一个服务的接口所有调用方都要跟着改需要做好API版本管理推荐用Swagger/YApi管理文档测试难度陡增单元测试不够了还要写集成测试、契约测试测一个功能可能要启动好几个服务运维复杂度指数级上升几十个服务配置管理、监控、告警、日志收集全是挑战需要一整套微服务治理平台重复劳动每个服务都要有类似的工具类、配置多语言场景下Java的common-jar没法给Go用所以不要为了微服务而微服务。团队小、业务简单的时候单体可能是更好的选择。五、微服务设计四原则单一职责原则一个服务只做一件事把它做好。服务边界要清晰不要把不相关的功能塞进来。服务自治原则每个服务可以独立开发、测试、构建、部署、运行对其他服务最小化依赖。轻量级通信原则服务间调用要跨语言、跨平台REST、gRPC、AMQP都是好选择不要用太重的协议。粒度适中原则没有标准答案根据团队和业务情况调整。拆太细了调用链太长拆太粗了又回到单体。随着业务演进逐步拆分不要上来就追求完美。我的经验一开始宁粗勿细粗了后面好拆拆细了再合就麻烦了。六、微服务生态全景微服务不只是把代码拆开就完事了它需要一整套基础设施支撑┌─────────────────────────────────────────────────────────┐ │ 客户端/前端 │ └─────────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────────┐ │ 服务网关 Gateway │ │ 路由转发、鉴权、限流、灰度发布、A/B测试 │ └─────────────────────────────────────────────────────────┘ │ ┌──────────┬──────────┬──────────┬──────────┬──────────┐ │ 用户服务 │ 商品服务 │ 订单服务 │ 支付服务 │ 搜索服务 │ └──────────┴──────────┴──────────┴──────────┴──────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ 注册中心 │ 配置中心 │ 熔断限流 │ 链路追踪 │ 监控告警 │ └─────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ 消息队列 │ 分布式事务 │ CI/CD │ 容器编排 │ └─────────────────────────────────────────────────────────┘核心组件清单组件作用常见选型服务注册发现服务地址登记与查询Nacos、Eureka、Consul、Zookeeper负载均衡请求分发到多个实例Ribbon、LoadBalancer、Nginx服务网关统一入口、鉴权、路由SpringCloud Gateway、Zuul、Kong配置中心集中管理配置、热更新Nacos、Apollo、Spring Cloud Config熔断限流防止服务雪崩、保护系统Sentinel、Hystrix、Resilience4j远程调用服务间HTTP/RPC调用OpenFeign、Dubbo、RestTemplate链路追踪排查分布式调用问题SleuthZipkin、SkyWalking、Jaeger消息队列异步解耦、削峰填谷RocketMQ、Kafka、RabbitMQ分布式事务跨服务数据一致性Seata、本地消息表、Saga监控告警指标监控、日志聚合PrometheusGrafana、Admin、ELK七、SpringCloud是什么聊完了微服务概念我们终于可以进入正题了。SpringCloud是Spring官方推出的微服务治理框架集合它不是一个具体的框架而是一系列框架的有机组合利用Spring Boot的开发便利性简化了分布式系统基础设施的开发。简单说SpringBoot帮你快速构建单个服务SpringCloud帮你治理一堆服务。7.1 SpringCloud vs Dubbo这是面试经典题直接给对比表对比维度SpringCloudDubbo背景Netflix/Alibaba/Spring社区阿里开源后捐给Apache通信方式HTTP RESTFeign/RestTemplate自有RPC协议TCP长连接性能略低HTTPJSON较高二进制序列化长连接功能完整度全家桶覆盖微服务各方面主要专注服务调用和治理生态丰富与Spring无缝集成相对独立需要自己整合其他组件学习成本稍高组件多较低适用场景快速迭代的互联网业务、多语言高性能、对延迟敏感的内部系统现在更多是两者结合用SpringCloud Alibaba生态里面包含Dubbo作为RPC选项。7.2 SpringCloud版本说明SpringCloud的版本命名比较有意思它不用数字版本号而是用伦敦地铁站名按字母顺序命名Angel最早版本BrixtonCamdenDalstonEdgwareFinchleyGreenwichHoxtonSpringBoot 2.2.x/2.3.x我们这个系列用这个版本Ilford后来改名为2020.0.x开始日历化版本从2020年开始SpringCloud改用了日历版本号格式为YYYY.RELEASE比如2020.0.xIlford2021.0.xJubilee2022.0.xKilburn2023.0.xLeyton2024.0.x 及更新版本版本对应关系很重要乱配版本会出各种奇奇怪怪的问题SpringCloud版本SpringBoot版本备注Hoxton.SR32.2.x本系列使用Netflix组件还在2020.0.x2.4.x移除大部分Netflix组件2021.0.x2.6.x-2022.0.x3.0.x支持SpringBoot 3JDK17最低2023.0.x3.2.x- 新手建议不要上来就追最新版本先从Hoxton SpringBoot 2.2.x把组件原理搞懂再升级新版本也不迟。7.3 SpringCloud的朝代更替SpringCloud发展到现在经历了几个阶段第一代SpringCloud Netflix2015-2020核心组件Eureka、Ribbon、Hystrix、Zuul 1.x、Feign、Archaius问题Netflix在2018年底宣布这些项目进入维护模式不再开发新功能Hystrix更早就停止了开发Zuul 2.x一直跳票第二代SpringCloud Alibaba2018至今国内主流核心组件Nacos注册配置、Sentinel熔断限流、Seata分布式事务额外组件RocketMQ、Dubbo、OSS等优点国内社区活跃、中文文档好、功能更强、经过阿里大流量验证现在国内互联网公司Java微服务基本都是SpringCloud Alibaba那一套第三代SpringCloud官方原生2020至今用SpringCloud LoadBalancer替代Ribbon用SpringCloud Gateway替代Zuul用Spring Cloud Circuit Breaker统一熔断抽象支持Resilience4J等配置中心可以用Spring Cloud Consul或第三方八、SpringCloud Alibaba核心组件既然国内主流是Alibaba这套我们有必要先了解下它的核心组件后续会有专门文章详细讲组件作用替代Netflix的谁Nacos服务注册发现 配置中心Eureka ConfigSentinel流量控制、熔断降级、系统保护HystrixSeata分布式事务解决方案无对应RocketMQ分布式消息队列无对应Dubbo高性能RPC通信Feign可选替代SpringCloud Stream消息驱动抽象层-另外还有一些阿里云商业组件ACM、OSS、SchedulerX、SMS等个人学习可以不用管。九、本系列学习路线这个系列我们会从Netflix经典组件讲起再过渡到Alibaba主流方案最后做面试题汇总。打好基础再学新东西才稳。学习顺序建议1. 微服务基础概念这篇 2. Eureka 注册中心 → 理解服务注册发现原理 3. RestTemplate Ribbon → 服务调用与负载均衡 4. OpenFeign → 声明式调用 5. Hystrix → 熔断降级理解原理现在多用Sentinel 6. Zuul/Gateway → 微服务网关 7. Config → 配置中心理解思路现在多用Nacos 8. Sleuth Zipkin → 链路追踪 9. SpringBoot Admin → 监控 10. Nacos、Sentinel、Seata重点面试高频 11. 面试题汇总十、高频面试题1. 什么是微服务优缺点是什么参考答案见上文第四部分重点答出独立部署、低耦合、技术栈自由以及分布式复杂性、事务、运维等缺点。2. 微服务架构有哪些核心组件注册中心、配置中心、网关、负载均衡、熔断限流、远程调用、链路追踪、消息队列、监控等结合表格回答。3. SpringCloud和Dubbo有什么区别从通信协议HTTP vs RPC、性能、功能完整度、生态等角度对比现在可以说两者不是替代关系Dubbo可以整合到SpringCloud中使用。4. SpringCloud和SpringBoot是什么关系SpringBoot专注快速构建单个应用SpringCloud专注治理分布式服务SpringCloud基于SpringBoot构建。5. 什么是CAP定理什么是BASE理论CAP一致性、可用性、分区容错性分布式系统只能同时满足两个BASE是对AP的扩展基本可用、软状态、最终一致性微服务分布式事务常用。6. 蓝绿部署和灰度发布有什么区别蓝绿部署准备两套相同环境新版本部署在绿环境测试OK后流量一次性切过去蓝环境留作回滚灰度发布金丝雀发布先切一小部分流量到新版本观察没问题再逐步放大直到全量核心区别蓝绿是一次性切换灰度是渐进式迁移7. 服务拆分会遇到什么问题怎么解决分布式事务Seata/最终一致性、服务发现Nacos、网关Gateway、链路追踪Sleuth/SkyWalking、运维复杂度Docker/K8s/CI/CD。总结这篇文章我们讲了架构从单体→SOA→微服务的演进过程微服务的特性、优缺点和设计原则微服务生态的核心组件SpringCloud是什么、版本怎么选Netflix和Alibaba两朝换代本系列学习路线微服务不是银弹不要为了拆而拆。但作为Java后端工程师掌握SpringCloud生态是必备技能无论是日常开发还是跳槽面试都用得上。下一篇我们开始动手搭建第一个Eureka注册中心并把服务注册上去。本系列代码会同步更新到GitHub欢迎Star关注。如果文章对你有帮助点个赞和关注就是对我最大的鼓励下一篇【SpringCloud系列02】Eureka注册中心单机与高可用集群搭建实战 从单体到微服务：架构演进与SpringCloud全景图
【SpringCloud系列01】从单体到微服务架构演进与SpringCloud全景图个人主页夏天拐跑了西瓜专栏传送门《大模型应用开发》、《Spring 生态全家桶体系化实战》学习方向Java 后端AI‑Agent 大模型应用开发爱好者⭐人生格言路虽远行则将至本文是SpringCloud系列第一篇带你搞懂微服务是什么、为什么要用微服务以及SpringCloud全家桶都有哪些组件。文末附高频面试题。一、为什么需要微服务作为Java开发者相信你或多或少都遇到过这样的场景项目刚上线时功能简单一个war包打天下部署快、改起来爽业务迭代半年后模块越来越多代码几十万行改一行代码心惊胆战团队从3个人扩到10个人大家都在同一个工程里提交代码冲突不断大促期间想给订单模块加机器结果只能整个应用一起扩容浪费资源某个边缘功能出了OOM整个系统跟着挂如果你也遇到过以上任何一个问题说明项目已经到了该考虑微服务的时候。这篇文章不着急写代码先从架构演进的历史聊起搞清楚微服务的来龙去脉。二、架构演进的三个阶段软件架构不是银弹而是随着业务规模逐步演化的。从互联网发展至今后端架构大致经历了三个阶段2.1 单体架构Monolithic什么是单体架构所有功能模块打包在一个工程里最终生成一个jar或war包部署运行。比如一个电商项目用户、商品、订单、支付、后台管理全写在一个项目里。我早年参与过一个网约车项目最开始乘客端、司机端、订单、消息、地图全在一个工程里启动一次要3分钟改个小功能也要全量部署。单体架构的优点开发简单IDE跑起来就完事测试方便本地启动就能调部署容易一个包扔到Tomcat就行适合项目初期快速试错、MVP验证单体架构的痛点重点面试常问痛点具体表现复杂性高代码量从几万涨到几十万行模块边界模糊新人上手要几周技术债务“不坏不修”老代码没人敢动人员流动后更是雪上加霜部署困难改一行文案也要全量打包部署上线窗口越缩越长形成恶性循环可靠性差一个小功能OOM整个进程挂掉所有功能都不能用扩展受限订单模块需要扩容但只能整个应用一起加机器资源浪费阻碍创新想把Spring MVC换成WebFlux几十万行代码改不起想试试Go写某个高性能模块门都没有一句话总结小项目用单体真香大项目用单体要命。2.2 面向服务架构SOA为了解决单体的问题业界提出了SOAService-Oriented Architecture面向服务架构。SOA的核心思想是把系统拆分成多个服务服务之间通过网络调用用服务编排来实现业务流程。SOA通常会引入ESB企业服务总线来做服务之间的通信和转换常见的ESB有WebService、Dubbo早期版本等。但SOA有个问题它更多是传统企业级的架构思路ESB本身很重服务拆分粒度也比较粗很多时候拆完发现还是个大单体。可以说SOA提出了很好的理念但落地成本高没有在互联网公司大规模流行开来。2.3 微服务架构Microservices微服务是SOA思想的一种更轻量、更彻底的实践。微服务架构 80%的SOA服务思想 100%的组件化架构思想Martin Fowler在2014年发表的《Microservices》一文中给微服务下了这样的定义大意微服务是一种架构风格将单个应用程序开发为一组小型、独立的服务每个服务运行在自己的进程中服务间通过轻量级机制通常是HTTP REST API通信。这些服务围绕业务能力构建通过自动化部署机制独立部署可以用不同的编程语言编写使用不同的数据存储技术。打个通俗的比方单体架构像一个大锅饭所有人吃一锅菜咸淡没法调微服务像自助餐每个菜独立盛盘想吃啥拿啥凉了单独换网上还有个很形象的分封制类比服从天子命令 → 接受注册中心统一管理镇守疆土 → 各自负责一块业务随从作战 → 服务之间相互调用交纳贡献 → 共同分担系统流量三、微服务的核心特性一个真正的微服务架构应该具备以下特点服务独立进程每个服务跑在自己的JVM/容器里互不影响围绕业务拆分按领域模型或业务能力拆分不是按技术层拆分轻量级通信服务间用HTTP/REST、gRPC、消息队列等通信不绑定语言独立部署每个服务可以单独上线不依赖其他服务发布节奏技术栈自由Java写业务、Go写网关、Python写数据分析各取所长数据去中心化每个服务管理自己的数据库不共享数据库自动化运维服务多了必须靠自动化CI/CD、容器化是标配四、微服务的优缺点4.1 优点独立部署低耦合改订单服务不影响用户服务上线风险小易于开发维护每个服务代码量少业务聚焦新人上手快启动速度快一个服务可能就几千行代码启动几秒钟按需伸缩大促时只给订单、商品服务加实例省成本技术栈灵活可以根据场景选最合适的技术比如用AI推荐服务用Python容错性好一个服务挂了不会拖垮整个系统配合熔断降级团队分工明确两个披萨团队6-10人负责一个服务职责清晰代码复用基础服务可以通过接口被多个上层服务复用4.2 缺点没有银弹微服务不是免费的午餐它解决了单体的问题但也引入了新的复杂度分布式系统复杂性网络是不可靠的延迟、丢包、分区服务调用链变长排查问题困难需要处理超时、重试、幂等等问题分布式事务难题每个服务有自己的数据库跨服务事务不能用本地事务解决方案2PC、TCC、本地消息表、Saga、最大努力通知业界主流是柔性事务 最终一致性BASE理论面试题什么是BASE理论Basically Available基本可用故障时允许部分功能不可用保证核心功能Soft state软状态允许数据存在中间状态Eventually consistent最终一致性一段时间后数据达到一致不需要实时一致接口调整成本高改一个服务的接口所有调用方都要跟着改需要做好API版本管理推荐用Swagger/YApi管理文档测试难度陡增单元测试不够了还要写集成测试、契约测试测一个功能可能要启动好几个服务运维复杂度指数级上升几十个服务配置管理、监控、告警、日志收集全是挑战需要一整套微服务治理平台重复劳动每个服务都要有类似的工具类、配置多语言场景下Java的common-jar没法给Go用所以不要为了微服务而微服务。团队小、业务简单的时候单体可能是更好的选择。五、微服务设计四原则单一职责原则一个服务只做一件事把它做好。服务边界要清晰不要把不相关的功能塞进来。服务自治原则每个服务可以独立开发、测试、构建、部署、运行对其他服务最小化依赖。轻量级通信原则服务间调用要跨语言、跨平台REST、gRPC、AMQP都是好选择不要用太重的协议。粒度适中原则没有标准答案根据团队和业务情况调整。拆太细了调用链太长拆太粗了又回到单体。随着业务演进逐步拆分不要上来就追求完美。我的经验一开始宁粗勿细粗了后面好拆拆细了再合就麻烦了。六、微服务生态全景微服务不只是把代码拆开就完事了它需要一整套基础设施支撑┌─────────────────────────────────────────────────────────┐ │ 客户端/前端 │ └─────────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────────┐ │ 服务网关 Gateway │ │ 路由转发、鉴权、限流、灰度发布、A/B测试 │ └─────────────────────────────────────────────────────────┘ │ ┌──────────┬──────────┬──────────┬──────────┬──────────┐ │ 用户服务 │ 商品服务 │ 订单服务 │ 支付服务 │ 搜索服务 │ └──────────┴──────────┴──────────┴──────────┴──────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ 注册中心 │ 配置中心 │ 熔断限流 │ 链路追踪 │ 监控告警 │ └─────────────────────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────┐ │ 消息队列 │ 分布式事务 │ CI/CD │ 容器编排 │ └─────────────────────────────────────────────────────────┘核心组件清单组件作用常见选型服务注册发现服务地址登记与查询Nacos、Eureka、Consul、Zookeeper负载均衡请求分发到多个实例Ribbon、LoadBalancer、Nginx服务网关统一入口、鉴权、路由SpringCloud Gateway、Zuul、Kong配置中心集中管理配置、热更新Nacos、Apollo、Spring Cloud Config熔断限流防止服务雪崩、保护系统Sentinel、Hystrix、Resilience4j远程调用服务间HTTP/RPC调用OpenFeign、Dubbo、RestTemplate链路追踪排查分布式调用问题SleuthZipkin、SkyWalking、Jaeger消息队列异步解耦、削峰填谷RocketMQ、Kafka、RabbitMQ分布式事务跨服务数据一致性Seata、本地消息表、Saga监控告警指标监控、日志聚合PrometheusGrafana、Admin、ELK七、SpringCloud是什么聊完了微服务概念我们终于可以进入正题了。SpringCloud是Spring官方推出的微服务治理框架集合它不是一个具体的框架而是一系列框架的有机组合利用Spring Boot的开发便利性简化了分布式系统基础设施的开发。简单说SpringBoot帮你快速构建单个服务SpringCloud帮你治理一堆服务。7.1 SpringCloud vs Dubbo这是面试经典题直接给对比表对比维度SpringCloudDubbo背景Netflix/Alibaba/Spring社区阿里开源后捐给Apache通信方式HTTP RESTFeign/RestTemplate自有RPC协议TCP长连接性能略低HTTPJSON较高二进制序列化长连接功能完整度全家桶覆盖微服务各方面主要专注服务调用和治理生态丰富与Spring无缝集成相对独立需要自己整合其他组件学习成本稍高组件多较低适用场景快速迭代的互联网业务、多语言高性能、对延迟敏感的内部系统现在更多是两者结合用SpringCloud Alibaba生态里面包含Dubbo作为RPC选项。7.2 SpringCloud版本说明SpringCloud的版本命名比较有意思它不用数字版本号而是用伦敦地铁站名按字母顺序命名Angel最早版本BrixtonCamdenDalstonEdgwareFinchleyGreenwichHoxtonSpringBoot 2.2.x/2.3.x我们这个系列用这个版本Ilford后来改名为2020.0.x开始日历化版本从2020年开始SpringCloud改用了日历版本号格式为YYYY.RELEASE比如2020.0.xIlford2021.0.xJubilee2022.0.xKilburn2023.0.xLeyton2024.0.x 及更新版本版本对应关系很重要乱配版本会出各种奇奇怪怪的问题SpringCloud版本SpringBoot版本备注Hoxton.SR32.2.x本系列使用Netflix组件还在2020.0.x2.4.x移除大部分Netflix组件2021.0.x2.6.x-2022.0.x3.0.x支持SpringBoot 3JDK17最低2023.0.x3.2.x- 新手建议不要上来就追最新版本先从Hoxton SpringBoot 2.2.x把组件原理搞懂再升级新版本也不迟。7.3 SpringCloud的朝代更替SpringCloud发展到现在经历了几个阶段第一代SpringCloud Netflix2015-2020核心组件Eureka、Ribbon、Hystrix、Zuul 1.x、Feign、Archaius问题Netflix在2018年底宣布这些项目进入维护模式不再开发新功能Hystrix更早就停止了开发Zuul 2.x一直跳票第二代SpringCloud Alibaba2018至今国内主流核心组件Nacos注册配置、Sentinel熔断限流、Seata分布式事务额外组件RocketMQ、Dubbo、OSS等优点国内社区活跃、中文文档好、功能更强、经过阿里大流量验证现在国内互联网公司Java微服务基本都是SpringCloud Alibaba那一套第三代SpringCloud官方原生2020至今用SpringCloud LoadBalancer替代Ribbon用SpringCloud Gateway替代Zuul用Spring Cloud Circuit Breaker统一熔断抽象支持Resilience4J等配置中心可以用Spring Cloud Consul或第三方八、SpringCloud Alibaba核心组件既然国内主流是Alibaba这套我们有必要先了解下它的核心组件后续会有专门文章详细讲组件作用替代Netflix的谁Nacos服务注册发现 配置中心Eureka ConfigSentinel流量控制、熔断降级、系统保护HystrixSeata分布式事务解决方案无对应RocketMQ分布式消息队列无对应Dubbo高性能RPC通信Feign可选替代SpringCloud Stream消息驱动抽象层-另外还有一些阿里云商业组件ACM、OSS、SchedulerX、SMS等个人学习可以不用管。九、本系列学习路线这个系列我们会从Netflix经典组件讲起再过渡到Alibaba主流方案最后做面试题汇总。打好基础再学新东西才稳。学习顺序建议1. 微服务基础概念这篇 2. Eureka 注册中心 → 理解服务注册发现原理 3. RestTemplate Ribbon → 服务调用与负载均衡 4. OpenFeign → 声明式调用 5. Hystrix → 熔断降级理解原理现在多用Sentinel 6. Zuul/Gateway → 微服务网关 7. Config → 配置中心理解思路现在多用Nacos 8. Sleuth Zipkin → 链路追踪 9. SpringBoot Admin → 监控 10. Nacos、Sentinel、Seata重点面试高频 11. 面试题汇总十、高频面试题1. 什么是微服务优缺点是什么参考答案见上文第四部分重点答出独立部署、低耦合、技术栈自由以及分布式复杂性、事务、运维等缺点。2. 微服务架构有哪些核心组件注册中心、配置中心、网关、负载均衡、熔断限流、远程调用、链路追踪、消息队列、监控等结合表格回答。3. SpringCloud和Dubbo有什么区别从通信协议HTTP vs RPC、性能、功能完整度、生态等角度对比现在可以说两者不是替代关系Dubbo可以整合到SpringCloud中使用。4. SpringCloud和SpringBoot是什么关系SpringBoot专注快速构建单个应用SpringCloud专注治理分布式服务SpringCloud基于SpringBoot构建。5. 什么是CAP定理什么是BASE理论CAP一致性、可用性、分区容错性分布式系统只能同时满足两个BASE是对AP的扩展基本可用、软状态、最终一致性微服务分布式事务常用。6. 蓝绿部署和灰度发布有什么区别蓝绿部署准备两套相同环境新版本部署在绿环境测试OK后流量一次性切过去蓝环境留作回滚灰度发布金丝雀发布先切一小部分流量到新版本观察没问题再逐步放大直到全量核心区别蓝绿是一次性切换灰度是渐进式迁移7. 服务拆分会遇到什么问题怎么解决分布式事务Seata/最终一致性、服务发现Nacos、网关Gateway、链路追踪Sleuth/SkyWalking、运维复杂度Docker/K8s/CI/CD。总结这篇文章我们讲了架构从单体→SOA→微服务的演进过程微服务的特性、优缺点和设计原则微服务生态的核心组件SpringCloud是什么、版本怎么选Netflix和Alibaba两朝换代本系列学习路线微服务不是银弹不要为了拆而拆。但作为Java后端工程师掌握SpringCloud生态是必备技能无论是日常开发还是跳槽面试都用得上。下一篇我们开始动手搭建第一个Eureka注册中心并把服务注册上去。本系列代码会同步更新到GitHub欢迎Star关注。如果文章对你有帮助点个赞和关注就是对我最大的鼓励下一篇【SpringCloud系列02】Eureka注册中心单机与高可用集群搭建实战