概述这是整个 SpringCloud 模块的导引篇。它不讲某一个组件的接口怎么调而是先把微服务到底想解决什么、SpringCloud 里的这一堆组件各自负责哪一段、按什么顺序学讲清楚——先有地图再走路后面十几篇才不至于变成一堆互不相干的 API 堆砌。纲要为什么要学微服务求职、企业开发、并发增长、需求快速迭代四条现实理由单体架构在规模上撑不住的三个痛点微服务解决了老问题又引入了哪些新问题服务发现、远程调用、分布式配置、统一入口SpringCloud 知识地图组件按解决什么问题分层串起来SpringCloud 与 SpringBoot 的分工和版本对应关系Hoxton.SR10 ↔ 2.3.9.RELEASE本模块组件与能力对照表贯穿全模块的示例工程 cloud-demo 结构预览学习路径建议哪些必须先动手、哪些可以后置下一篇预告为什么要学微服务把理由拆开看其实就四类前两类关于你后两类关于企业。求职角度Java 后端面试里微服务是必问题。SpringCloud、注册中心、网关、熔断这些词说不上来简历基本进不了下一轮。这不是课程宣传是岗位 JD 里的硬门槛。开发角度企业项目现在极少有纯单体的了中大型系统基本都是拆分后的多服务。进公司第一天就要在服务群里找别人的接口文档不会微服务等于不会干活。这个模块除了讲微服务本身还会讲微服务开发中会踩的各种坑和对应方案——所以学完拿到手的是一整套解决方案不只是几个注解。企业角度一扛并发互联网用户规模摆在那儿一台 Tomcat 撑不住百万级并发靠加机器也不是简单堆叠就能解决得先把系统拆开每个模块独立部署、独立扩容。微服务是应对高并发的前提。企业角度二扛变化业务需求一直在变单体项目所有功能耦合在一起改一个模块要反复评估对其它模块的影响上线一次提心吊胆。拆成服务之后服务间耦合度低改一个服务基本不用管别人迭代效率高这才撑得起敏捷开发。单体架构撑不住的三个痛点先把为什么必须拆说透。单体架构把全部业务打成一个包部署好处是架构简单、部署成本低做学生管理系统这种小项目完全够用。一旦规模上来问题集中爆发在三处痛点具体表现编译部署慢代码量堆到几十万行改一行日志也要全量编译打包一次构建十几分钟起步本地启动动辄几十秒模块边界模糊所有功能写在同一个工程里包结构靠人自觉维护。时间一长订单代码调用户代码、用户代码反向调订单代码形成循环依赖谁也不敢动无法按模块扩容秒杀场景只有下单接口压力大但单体只能整个应用一起扩容跟着被放大的还有根本没人访问的管理后台拆成微服务后一个功能模块一个服务大型企业里成百上千个服务都正常每个服务独立部署并发能力自然上去了。但拆开不是免费的午餐。原来一个方法调用搞定的事现在变成了跨网络的 HTTP 请求紧接着冒出来一串新问题服务地址怎么找IP 和端口写死在代码里服务换机器就全崩有多个实例时调哪一个总不能手动挑某个实例挂了怎么知道请求打过去一直超时才反应过来几十个服务的配置文件散落在各处改一个数据库地址要挨个改用户该从哪个入口进来每个服务都对外暴露端口、各自做鉴权显然不现实部署几十上百台服务器靠人手一个个操作工作量巨大还容易出错微服务的价值不在于拆而在于拆完之后有一套东西来管理这些新问题。SpringCloud 就是这套东西的集合。从问题到技术一张对应表下面这张表是本模块的骨架后面每一章基本都在填其中一行。新问题对应技术定位服务之间怎么调用RestTemplate / Feign发起远程 HTTP 调用Feign 让调用像调本地接口服务地址从哪来、怎么管理调用关系注册中心Eureka / Nacos服务启动时上报自己的地址调用方按服务名拉取实例列表多个实例怎么选Ribbon / Spring Cloud LoadBalancer拿到实例列表后按算法挑一个实现负载均衡某个实例是不是还活着心跳机制实例定期上报状态超时未上报就从列表里剔除一堆配置散落各处配置中心Nacos Config配置集中存放支持热更新改完不用重启服务用户从哪进来、谁来鉴权服务网关Gateway统一入口负责路由、鉴权、限流、跨域某个服务挂了会不会拖垮全链路熔断降级 / 服务保护故障服务快速失败避免级联失败拖垮整条调用链出问题怎么定位分布式日志、链路追踪与系统监控汇总各服务日志、监控每个节点的 CPU/内存/响应耗时上百台机器怎么部署容器化与持续集成Docker、K8s自动化打包成镜像、编排部署替代人工逐台操作表里最后几行的缓存、消息队列、分布式搜索、DevOps 属于更外层的微服务解决方案本模块先建立印象具体技术会在对应专题里展开。SpringCloud 知识地图把上面的技术按调用链串起来就是一个请求从进入系统到落库的完整路径。按路径路由1. 按服务名调用2. 返回可用实例列表3. 负载均衡选一个实例4. 发起真实 HTTP 请求声明式调用下发配置包裹调用用户 / 浏览器服务网关 Gateway统一入口·路由·鉴权·跨域order-service 订单服务注册中心 Eureka / Nacos服务地址不再硬编码Ribbon / LoadBalanceruser-service 用户服务Feign 远程调用user 库order 库配置中心 Nacos Config配置集中管理·热更新服务保护熔断·降级·限流每一层用一句话说清它存在的理由服务拆分与远程调用不拆就没法独立扩容拆了之后方法调用变成网络请求得有人把 HTTP 调用封装成像调本地方法一样。没有它就得手写 HttpClient、自己拼 URL、自己处理 JSON 和异常。注册中心没有它调用方只能把提供方的 IP 和端口写死在配置文件里服务扩缩容、换机器、加实例都要改代码重新发版。有了它服务按名字找地址是动态的。负载均衡没有它一个服务部署了三个实例请求全打到第一个上等于白扩容。有了它请求按算法分散到各实例。配置中心没有它几十个服务的配置散落在各自仓库改一个公共参数要挨个提交、挨个重启。有了它配置集中管理还能在不停机的情况下热更新。服务网关没有它每个微服务都要对外暴露端口、各自实现鉴权逻辑前端还要记住一堆地址。有了它所有流量走一个入口鉴权、限流、跨域这些横切关注点收在一处就像小区门口的保安——先看你是谁、再问你要找谁然后告诉你往哪走。服务保护没有它链路上任何一个服务变慢或挂掉调用方线程会被大量阻塞故障沿着调用链级联扩散最终整个系统雪崩。有了它故障服务被快速熔断请求走降级逻辑损失可控。SpringCloud 与 SpringBoot 的关系这两个名字经常被混在一起分工其实很清楚SpringBoot解决单个服务怎么快速搭起来——自动配置、内嵌 Tomcat、starter 依赖让一个独立服务几分钟就能跑起来。SpringCloud解决多个服务之间怎么协同——它把注册中心、网关、负载均衡这些组件集成起来底层基于 SpringBoot 的自动装配能力实现所以用起来也是加依赖、加注解、写配置。关系是前者是地基后者是地基上盖的楼。这也意味着两者版本必须匹配SpringCloud 的每个大版本都锁定了对应的 SpringBoot 版本区间配错了启动就会报版本不兼容。SpringCloud 版本对应 SpringBoot 版本Hoxton.SR10本模块使用2.3.x示例工程实际用 2.3.9.RELEASEGreenwich2.1.xFinchley2.0.x2020.x 及以后2.4.x 往上命名规则从地名改为年份版本写在哪在父工程的pom.xml里用属性统一声明子模块不写版本号避免各写各的。?xml version1.0 encodingUTF-8?projectxmlnshttp://maven.apache.org/POM/4.0.0xmlns:xsihttp://www.w3.org/2001/XMLSchema-instancexsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsdmodelVersion4.0.0/modelVersiongroupIdcn.itcast.demo/groupIdartifactIdcloud-demo/artifactIdversion1.0/versionpackagingpom/packagingmodulesmoduleuser-service/modulemoduleorder-service/module/modules!-- 父工程直接继承 spring-boot-starter-parent锁定 SpringBoot 版本 --parentgroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-parent/artifactIdversion2.3.9.RELEASE/versionrelativePath//parentpropertiesjava.version1.8/java.versionspring-cloud.versionHoxton.SR10/spring-cloud.versionmysql.version5.1.47/mysql.versionmybatis.version2.1.1/mybatis.version/propertiesdependencyManagementdependencies!-- 用 import 方式引入 SpringCloud 的 BOM子模块即可省略版本号 --dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-dependencies/artifactIdversion${spring-cloud.version}/versiontypepom/typescopeimport/scope/dependencydependencygroupIdmysql/groupIdartifactIdmysql-connector-java/artifactIdversion${mysql.version}/version/dependencydependencygroupIdorg.mybatis.spring.boot/groupIdartifactIdmybatis-spring-boot-starter/artifactIdversion${mybatis.version}/version/dependency/dependencies/dependencyManagement/project有个坑值得先提一句dependencyManagement只是声明版本不会真的引入依赖。子模块必须自己写dependency才会生效很多人第一次配完发现类找不到就是漏了这一步。本模块组件与能力对照表把全模块要动手的组件列出来方便对照后面各章的归属。组件定位解决的问题后续章节RestTemplateSpring 自带的 HTTP 客户端手写远程调用的起点理解调用变成了网络请求服务拆分与远程调用Feign声明式 HTTP 客户端把远程调用写成接口不用手拼 URL 和解析响应Feign 远程调用Eureka注册中心Netflix服务注册与发现地址不再硬编码认识微服务Nacos注册中心 配置中心阿里国内主流方案含集群分级、权重、环境隔离Nacos 注册中心Ribbon客户端负载均衡从实例列表里按算法选一个实例Ribbon 负载均衡Spring Cloud LoadBalancer新一代负载均衡替代进入维护期的 Ribbon版本升级说明Nacos Config配置中心配置集中管理与热更新配置管理Gateway服务网关统一入口、路由转发、鉴权、限流、跨域网关快速入门熔断降级组件服务保护防级联失败与雪崩本模块侧重概念与场景服务保护贯穿全模块的示例工程 cloud-demo这套课程不是每章换一个 demo而是从头到尾围绕同一个工程cloud-demo迭代。刚开始它只有两个服务随着章节推进逐步长出注册中心、网关、Feign 客户端。cloud-demo/ ├── pom.xml # 父工程统一管理 SpringCloud / SpringBoot / MyBatis 版本 ├── user-service/ # 用户微服务端口 8081对外暴露 Restful 接口 │ ├── pom.xml │ └── src/main/ │ ├── java/cn/itcast/user/ │ │ ├── UserApplication.java │ │ ├── mapper/UserMapper.java │ │ ├── pojo/User.java │ │ ├── service/UserService.java │ │ └── web/UserController.java │ └── resources/application.yml ├── order-service/ # 订单微服务端口 8080查询订单时需要调用户服务 │ ├── pom.xml │ └── src/main/ │ ├── java/cn/itcast/order/ │ │ ├── OrderApplication.java │ │ ├── mapper/OrderMapper.java │ │ ├── pojo/{Order.java, User.java} │ │ ├── service/OrderService.java │ │ └── web/OrderController.java │ └── resources/application.yml ├── feign-api/ # 后置章节新增Feign 客户端与公共 pojo 抽成独立模块 │ ├── pom.xml │ └── src/main/java/cn/itcast/feign/{clients,config,pojo}/ ├── eureka-server/ # 后置章节新增注册中心服务端端口 10086 │ ├── pom.xml │ └── src/main/ │ ├── java/cn/itcast/eureka/EurekaApplication.java │ └── resources/application.yml └── gateway/ # 后置章节新增服务网关所有外部请求的统一入口 ├── pom.xml └── src/main/ ├── java/cn/itcast/gateway/GatewayApplication.java └── resources/application.yml拆分遵循三条原则后面写代码时会反复用到不同微服务不重复开发相同业务用户相关的逻辑只放在 user-service数据独立order-service 不能直接查 user 库两张表各归各的服务管需要别人的数据时只能通过对方暴露的 Restful 接口拿第一条远程调用的代码长这样先注册一个RestTemplate到 Spring 容器再在订单服务里用它去请求用户服务packagecn.itcast.order;importorg.mybatis.spring.annotation.MapperScan;importorg.springframework.boot.SpringApplication;importorg.springframework.boot.autoconfigure.SpringBootApplication;importorg.springframework.context.annotation.Bean;importorg.springframework.web.client.RestTemplate;MapperScan(cn.itcast.order.mapper)SpringBootApplicationpublicclassOrderApplication{publicstaticvoidmain(String[]args){SpringApplication.run(OrderApplication.class,args);}/** * 把 RestTemplate 交给 Spring 管理后续直接注入即可发起 HTTP 调用。 * 注意这里地址还是写死的 http://localhost:8081注册中心那一章会把它换成服务名。 */BeanpublicRestTemplaterestTemplate(){returnnewRestTemplate();}}这段代码里localhost:8081就是地址硬编码的活标本。等注册中心上完这里会被替换成http://userservice/user/{id}Ribbon 负责把userservice翻译成真实 IP 和端口。学习路径建议知识点多且杂按企业使用频率 实用性排优先级别按目录顺序硬啃。必须先动手、而且建议边写边理解的三块服务拆分与远程调用。这是所有后续内容的载体先感受单体调用变成 HTTP 请求之后到底多了哪些麻烦超时、序列化、异常处理否则后面每个组件都是在解决不存在的问题。注册中心。理解服务注册、服务拉取、心跳三个动作以及为什么调用方可以只写服务名。Eureka 和 Nacos 都过一遍重点看它们对临时实例、健康检测的处理差异。远程调用与负载均衡的配合。手动起两个 user-service 实例观察请求怎么在两个端口之间轮询这个看得见的效果比背算法名称有用得多。可以后置的配置管理。它是运维友好型能力本地开发感受不深等有了多环境dev/test/prod需求再重点看。服务网关。独立于服务拆分之外晚一点学不影响前面的理解。集群搭建与高可用部署。偏向运维面试偶尔问实际开发中通常有专门的部署平台放最后。熔断降级、分布式事务、分布式日志与链路追踪。这类更贴近原理、使用频率相对低先会用再研究。按这个顺序走基本能做到每学一章手上的 cloud-demo 就真的变复杂一点而不是攒一堆跑不起来的示例代码。下一篇预告下一篇从最基础的地方开始认识微服务与服务架构演变。会讲清楚单体架构、分布式架构、微服务这三者各自的定义和优缺点为什么说微服务是一种经过良好架构设计的分布式架构方案以及 SpringCloud 与 SpringCloudAlibaba 在服务治理上的技术选型差异。这一篇是导引只给地图和路线不展开任何组件的技术细节——具体怎么引依赖、怎么改配置、监控页面上该看到什么都放到对应章节里讲。官方文档Spring Cloud 官网Nacos 官网Spring Cloud Alibaba总结微服务不是把项目拆小这么简单拆分本身只是起点真正的成本在于拆完之后一大堆跨网络、跨进程的新问题。SpringCloud 的价值就在于它把这些问题的解法打成了标准件注册中心管地址、负载均衡管分流、配置中心管参数、网关管入口、熔断管故障隔离。学这一块的关键是先建立问题 → 技术的映射遇到需求时能反应出该用哪个组件而不是先记住一堆注解名字。示例工程 cloud-demo 会从头用到尾建议自己动手跑一遍两个 user-service 实例加一个注册中心比看十遍原理图都直观。版本别配错Hoxton.SR10 配 SpringBoot 2.3.9.RELEASE这是本模块全篇的基准。