一、架构演进：单体→集群→分布式→微服务（课程开篇核心理论）

1. 单体架构（All In One）

定义：所有业务模块（用户、商品、订单、支付）全部打包为一个 Jar/War，共用数据库、一台服务器部署。 优点：开发简单、部署一键、本地方法调用无网络开销，适合小型系统（图书管理、简易后台）。 三大致命痛点

1. 服务器压力过载：用户量上涨，单机器 CPU / 内存打满，直接无法访问；
2. 代码高度耦合：业务迭代叠加，代码臃肿，改一行代码就要全量打包发布；
3. 单点雪崩：任意模块 Bug（如支付报错）会导致整个应用宕机。

2. 两种扩容方案：横向集群 / 纵向分布式

1. 横向扩容（集群） 多台服务器完整部署同一个单体项目，每台机器拥有全部业务能力，通过负载均衡分流。 类比餐馆：多厨师，每个人都能独立完成洗菜、炒菜全套流程，做同一件事，可互相替补。 核心特点：多节点功能完全一致、可相互替代。
2. 纵向拆分（分布式 / 垂直架构） 按业务边界拆分系统，不同模块部署在不同服务器，各司其职，通过网络接口通信。 类比餐馆：专人配菜、专人炒菜，分工不同，无法互相替代。 核心特点：节点职责不同，必须协作完成完整业务。

3. 集群 & 分布式关系（必考点）

1. 分布式节点内部可以是集群：比如商品服务部署 3 台机器，分布式大框架下，商品模块自身做集群扩容；
2. 行业习惯：日常开发中统称分布式架构，不会严格区分垂直 / 集群概念。

4. 微服务架构

定义：分布式架构的精细化升级版，拆分粒度更小，单一服务只负责单一能力，独立数据库、独立团队、独立部署。

• 分布式：只要拆分系统就算（拆成 2 个模块都叫分布式）；
• 微服务：极致细分，一个服务仅对外提供少量接口（甚至 1 个接口），专业化分工。 岗位类比
• 分布式：公司只拆分技术、行政两大块；
• 微服务：技术拆前端、后端、算法，行政拆人事、财务、运营，细分到底。

微服务优缺点

✅ 优势

1. 故障隔离：订单服务崩，商品、用户不受影响；
2. 按需弹性扩容：订单流量高就只扩容订单实例，不用全系统扩容；
3. 技术栈自由：每个服务可选用适配语言（算法 Python、底层 C++、业务 Java）；
4. 团队并行开发，互不干扰。 ❌ 核心挑战（Spring Cloud 所有组件就是为解决这些问题）
5. 服务依赖复杂，改一个服务要评估所有调用方；
6. 运维成本暴涨：多服务编译、部署、监控；
7. 网络不可靠：远程调用存在延迟、超时、失败；
8. 需要统一服务治理：注册发现、负载均衡、链路监控、熔断限流。

5. 架构选型核心原则：没有最好，只有最合适

小型内部系统、低并发直接用单体； 预估中长期高并发、多团队协作，直接微服务； 创业初期可先单体，业务扩张后平滑拆分。

二、Spring Cloud 整体定位与两大技术体系

1. Spring Cloud 核心定义

分布式微服务一站式解决方案，不是独立框架，而是一套规范，整合业界成熟开源组件，基于 Spring Boot 快速开发微服务，统一解决分布式所有共性问题（注册、调用、均衡、熔断、配置等）。

2. 两大主流实现体系

（1）Spring Cloud Netflix（第一代，已淘汰）

代表组件：Eureka、Ribbon、Feign、Hystrix、Zuul 关键事件：2018 Netflix 宣布核心组件停止新版本迭代，仅修复严重 Bug，2020 版本后 Spring Cloud 官方移除大部分组件，仅保留 Eureka 做短期兼容。 缺点：停止维护，长期项目存在安全、性能隐患。

（2）Spring Cloud Alibaba（国内主流第二代方案）

阿里基于 Spring Cloud 规范自研全套组件，持续高速迭代，国内大厂通用： 核心组件：Nacos（注册中心 + 配置中心）、Sentinel（熔断限流）、Dubbo RPC、Gateway、Seata 分布式事务。 优势：双合一（注册 + 配置）、功能更全、中文文档、国内社区活跃。

（3）Spring Cloud 官方原生组件（替代 Netflix）

Netflix 停更后 Spring 官方自研替代： 负载均衡：Spring Cloud LoadBalancer（替代 Ribbon） 网关：Spring Cloud Gateway（替代 Zuul） 熔断：Resilience4j 配置：Spring Cloud Config

3. 版本配套规范（课程环境：SpringBoot3.1.6 + SpringCloud 2022.0.3 + JDK17）

• JDK 选型：JDK17、21 为长期支持 LTS 版本，JDK9/10/16 短期版本无长期维护；JDK21 发布时间短，生产验证不足，课程选用成熟 JDK17。
• Spring Cloud 版本必须和 Spring Boot 严格匹配，不可随意混搭。

三、开发环境搭建（Windows / Ubuntu / CentOS）

1. JDK17 安装

1. Windows：下载 exe 安装包，配置JAVA_HOME、Path 环境变量，java -version验证；
2. Ubuntu：apt一键安装 OpenJDK（免费商用）；
3. CentOS：wget 下载 Linux 压缩包手动配置环境变量； 区分：Oracle JDK 商用收费，OpenJDK 开源免费，学习 / 生产推荐 OpenJDK。

2. MySQL 安装与安全初始化

1. Ubuntu：apt 安装，执行mysql_secure_installation做安全加固：
   • 开启强密码策略、删除匿名用户、禁用 root 远程登录、删除 test 测试库；
2. CentOS：下载 rpm 包，读取日志获取初始密码，登录后重置 root 密码；
3. 业务库规划（课程电商案例）
   • cloud_order：订单库，存储 order 订单表；
   • cloud_product：商品库，存储 product 商品表； 微服务规范：一服务一独立数据库，数据隔离。

四、Maven 父子多模块工程搭建（课程标准项目结构）

1. 父子工程作用

• 父工程（pom 打包）：统一管理依赖版本，通过dependencyManagement声明所有组件版本，子模块引用依赖无需写版本号，统一管控避免版本冲突；
• 子模块（jar 打包）：订单服务 order-service、商品 product-service、Eureka 注册中心 eureka-server，独立可运行微服务。

2. 核心标签区分

1. <dependencies>：直接引入依赖，所有子模块自动继承；
2. <dependencyManagement>：仅声明版本，子模块需要时手动引入，不会强制加载，工程轻量化。

3. 基础业务模块实现（订单 / 商品服务）

三层架构：Controller → Service → Mapper + 实体 Model

1. 商品服务（9090 端口）：根据商品 ID 查询商品信息；
2. 订单服务（8080 端口）：根据订单 ID 查订单，需要远程调用商品服务获取商品详情。

五、基础远程调用：RestTemplate（无注册中心硬编码痛点）

1. RestTemplate

Spring 封装的同步 HTTP 客户端，简化 Restful 接口调用。

使用步骤

1. 新建配置类，@Bean注入 RestTemplate 对象（第三方工具类无法用五大注解）；
2. 业务 Service 中@Autowired注入，拼接 IP + 端口硬编码调用商品接口；

2. 硬编码致命缺陷

1. 商品服务 IP / 端口变更，必须修改代码、重新打包部署；
2. 多实例部署时，无法自动分流，请求永远打在同一台机器；
3. 接口地址手写极易出错，无统一服务管理；

3. RESTful API 设计规范与优缺点

规范：HTTP 方法区分操作（GET 查、POST 增、PUT 改、DELETE 删），URL 仅标识资源。 缺点：URL 看不出操作行为，调试、团队沟通成本高，企业大多不完全严格遵循。

六、注册中心 Eureka 实战（服务注册与发现）

1. 生活类比：114 查号台

• 服务提供者（商品服务）= 商家，主动把电话（IP + 端口）登记到 114；
• 服务消费者（订单服务）= 用户，调用前先查 114 获取商家地址；
• Eureka Server = 114 平台（注册中心）。

2. 三大核心角色

1. 服务提供者：对外提供接口，启动时注册自身元数据，定时发送心跳保活；
2. 服务消费者：调用其他服务，启动时拉取全量服务列表缓存本地；
3. Eureka Server：存储所有服务注册信息，维护健康状态。

3. 核心概念

1. 服务注册：提供者启动，向 Eureka 上报服务名、IP、端口，定时心跳；
2. 服务发现：消费者启动从 Eureka 拉取所有在线服务实例，本地缓存；

4. CAP 理论（分布式基石）

分布式网络故障不可避免，分区容错 P 必须满足，只能在一致性 C、可用性 A 二选一：

• C（强一致性）：所有节点数据实时完全同步，查询结果无旧数据；
• A（高可用）：任何请求都能得到响应，允许短暂数据不一致；

1. Eureka：AP 架构，优先保证可用性，网络故障仍可正常调用（仅可能读到旧实例列表）；
2. Zookeeper：CP 架构，优先强一致性，网络分区时集群不可用；
3. Nacos：混合模式，服务发现 AP、配置管理 CP。

5. Eureka 单机搭建四步

1. 新建 eureka-server 子模块，引入spring-cloud-starter-netflix-eureka-server依赖；
2. 配置文件：设置端口 10010，关闭自身注册、关闭拉取实例；
3. 启动类添加@EnableEurekaServer开启注册中心；
4. 启动后访问localhost:10010可视化控制台查看注册服务。

6. 客户端接入（商品 / 订单服务）

1. 引入eureka-client依赖；
2. yml 配置：指定 Eureka 地址、设置spring.application.name服务名（全局唯一标识）；
3. 启动类添加@EnableDiscoveryClient开启注册发现；
4. 改造远程调用：通过DiscoveryClient从注册中心拉取服务实例，替代硬编码 IP。

7. Eureka VS Zookeeper 对比

表格

维度	Eureka	Zookeeper
CAP	AP（高可用优先）	CP（强一致优先）
集群节点	对等节点，无主从	分 Leader/Follower，Leader 宕机需重新选举，期间不可用
适用场景	微服务注册中心	分布式锁、协调服务，不适合高可用服务发现
维护状态	Netflix 停更，仅遗留项目使用	持续维护

七、客户端负载均衡 Spring Cloud LoadBalancer

1. 负载均衡定义

多服务实例之间合理分发请求，分摊压力，避免单实例过载； 分类：

1. 服务端 LB（Nginx）：独立中间件统一分流，所有请求先经过 Nginx；
2. 客户端 LB（LoadBalancer/Ribbon）：消费端本地实现均衡逻辑，无需中间件，Spring Cloud 默认方案。

2. 多实例场景问题

商品服务启动 9090/9091/9092 三个实例，原始 DiscoveryClient 代码固定取列表第一个实例，流量无法分摊，资源浪费。

3. LoadBalancer 使用方案

1. RestTemplate 配置类添加@LoadBalanced注解，开启客户端负载均衡；
2. 远程调用 URL 直接写服务名（如 http://product-service），无需 IP 端口；
3. 底层拦截请求，自动从 Eureka 拉取实例列表，执行均衡算法。

4. 内置均衡策略

1. 轮询（默认）：请求依次分配到每一个实例；
2. 随机：随机挑选实例； 支持自定义权重、最小连接数等策略，自定义策略只需实现策略类，通过注解绑定指定服务。

5. 底层原理

LoadBalancer 拦截器拦截 HTTP 请求，截取服务名，从注册中心获取实例清单，执行均衡算法选中实例，拼接真实地址发起调用，自动剔除故障节点。

八、项目 Linux 云服务器部署流程

1. 环境准备：云服务器安装 JDK17、MySQL，执行业务初始化 SQL；
2. 多环境 Profile：dev 本地环境、prod 生产环境，maven 打包指定环境；
3. Maven 打包：父工程统一打包，每个微服务生成 Jar 包；
4. 服务器上传 Jar，后台启动nohup java -jar，输出日志到文件；
5. 安全组开放所有微服务端口（10010、8080、9090、9091、9092）；
6. 访问公网 IP + 端口验证注册中心、接口可用性。

九、下一代注册中心 Nacos（课程拓展）

1. Nacos 优势

1. 二合一：同时提供服务注册发现 + 分布式配置中心，Eureka 仅能做注册；
2. 架构灵活：临时实例 AP（微服务调用）、持久实例 CP（配置）；
3. 阿里持续迭代，国内企业主流，可视化控制台完善，支持权重、灰度、流量管控；
4. 替代 Netflix 全套老旧组件，新项目首选。

2. 行业现状

Eureka 因停更逐步淘汰，国内互联网、传统企业微服务架构统一选用 Spring Cloud Alibaba + Nacos 技术栈。

全课程知识闭环总结

1. 架构演进逻辑：单体有瓶颈 → 横向集群扩容、纵向分布式拆分 → 极致细分得到微服务；
2. 微服务所有痛点 = Spring Cloud 组件解决目标
   • 服务地址硬编码、多实例管理 → Eureka/Nacos 注册发现；
   • 多实例流量分配 → Spring Cloud LoadBalancer 客户端负载均衡；
   • 服务间远程 HTTP 调用 → RestTemplate / OpenFeign；
3. 技术迭代脉络 Spring Cloud Netflix（Eureka/Ribbon，停更淘汰）→ Spring Cloud 官方原生组件 + Spring Cloud Alibaba（Nacos/Sentinel，现代主流）；
4. 核心底层理论：CAP 理论决定注册中心架构选型（AP 高可用 Eureka/Nacos 临时实例 VS CP 强一致 Zookeeper）；
5. 工程标准化：Maven 父子工程统一依赖管理、一服务一库、多环境打包、Linux 云原生部署整套落地流程。

还是不够详细，再给我扩展按照文档内容

Spring Cloud 微服务架构与 Eureka 实战完整详细文档（完全贴合原文逐段扩展细化）

目录

1 课程开篇核心问题引入 2 架构演进全流程：单体→集群→分布式→微服务 3 集群与分布式深度解析 + 生活化案例 4 微服务定义、优缺点、落地选型思路 5 微服务全套痛点梳理（对应 Spring Cloud 解决目标） 6 Spring Cloud 体系详解（Netflix、Alibaba 两大阵营对比） 7 开发环境完整安装指南（Windows/Ubuntu/CentOS JDK17+MySQL） 8 Maven 父子工程搭建完整实操 9 电商案例业务、数据库建表 SQL 完整说明 10 单体服务基础开发（订单 / 商品三层代码实现） 11 RestTemplate 硬编码远程调用实现及缺陷分析 12 RESTful API 规范、优缺点详解 13 服务注册与发现核心思想（114 类比） 14 CAP 理论深度拆解 + 银行、数据库案例 15 主流注册中心对比：Eureka/Zookeeper/Nacos 16 Eureka Server 注册中心完整搭建步骤 17 Eureka Client 服务注册、服务发现完整代码改造 18 客户端负载均衡出现的问题与手写轮询 Demo 19 Spring Cloud LoadBalancer 完整使用、自定义均衡策略 20 项目云服务器打包、部署全流程 21 Eureka 与 Nacos 迭代关系、行业落地现状 22 全章节知识点闭环总结

1 课程开篇核心问题引入

1.1 行业两种对立观点拆解

行业存在两种主流观点： 观点 1：Spring Cloud 专门用来解决微服务架构下各类分布式问题； 观点 2：Spring Cloud 只能用于微服务开发，无法在单体、分布式架构中使用。 课程核心目标：理清微服务定义、Spring Cloud 定义、二者依赖关系，判断两种观点对错。

1.2 核心思考问题

1. 软件架构从单体迭代到微服务的过程中，每一代架构分别解决了什么问题？又带来了哪些新问题？
2. Spring Cloud 的核心定位是什么？专门解决分布式、微服务中的哪些通用难题？

1.3 本章学习划分

本章分为两大模块：①认识微服务 ②认识 Spring Cloud。

2 架构演进全流程：单体→集群→分布式→微服务

2.1 单体应用（单体架构）定义

定义：将系统全部业务功能、前端交互、后端逻辑、数据库操作全部封装到一个 Jar/War 包中，仅部署在单台服务器运行，该打包后的完整项目称为单体应用，整体架构称为单体架构。

2.1.1 基础案例

1. 小型系统：图书管理系统、个人博客系统；所有用户操作、文章管理、数据库操作写在同一个项目内，内部调用直接本地方法，无网络开销。
2. 电商单体案例：早期电商把用户、商品、订单、支付、库存、物流全部写在一个项目，统一部署 Web 容器。

2.1.2 单体架构优势

开发简单、本地方法调用无网络损耗、部署仅需打包一次、运维成本极低，适合初创小项目、内部管理系统。

2.2 单体架构三大致命缺陷（超市生活化案例辅助理解）

缺陷 1：并发上涨，服务器负载过高

类比小型超市：开业仅周边 1-2 公里居民，导购充足；名气扩大后 10 公里外顾客涌入，导购人数不变，接待不过来，顾客排队、无法购物。 对应程序：用户流量暴涨，单台服务器 CPU、内存、连接池占满，接口超时、页面无法访问。

缺陷 2 业务迭代导致代码高度耦合，发布成本极高

超市类比：原本只售卖日用品，用户需求增加，陆续新增蔬菜、面食、凉菜，采购、理货、导购流程互相绑定，新增品类所有人流程都要改动。 对应程序：需求持续叠加，代码耦合严重；任意一行代码修改，必须全项目重新编译、打包、上线，发布风险极高。

缺陷 3 局部故障引发整体雪崩

超市类比：收银员辱骂顾客视频网上发酵，整个超市客流暴跌；单一岗位事故，全盘受影响。 对应程序：任意模块（支付、库存）出现异常、死循环、内存泄漏，整个应用直接宕机，所有业务全部不可用。

2.3 单体架构两大扩容解决方案（横向集群、纵向拆分）

2.3.1 横向扩容（集群方案）

适用场景：单服务器性能不足，不拆分业务，复制多台一模一样的服务器，分摊流量。 电商例子：单台服务器承载 1000 用户，总用户 10000，扩容 10 台相同单体项目，每台承载 1000 流量。 核心特点：所有机器业务代码完全一致，每台机器具备系统全部能力，节点之间可互相替换。

2.3.2 纵向拆分（分布式 / 垂直拆分）

适用场景：业务耦合严重，按业务领域切割系统。 电商拆分案例：

1. 用户模块独立部署服务器（负责浏览、登录）
2. 订单模块独立服务器（下单、订单查询）
3. 支付模块独立服务器（付款、退款） 拆分后模块之间不能本地调用，必须通过 HTTP 接口跨机器通信。 核心特点：不同服务器职责完全不同，无法互相替代，多个子系统协作完成完整业务。

2.4 拆分后架构专业名词

1. 横向多副本部署：集群
2. 纵向按业务拆分：分布式 / 垂直架构 行业说明：垂直架构、分布式无严格清晰边界，课程不做严格区分；微服务属于分布式的细分形态。

3 集群与分布式深度解析 + 餐馆生活化案例

3.1 集群定义

将一套完整系统完整部署多台服务器，多节点执行完全相同业务逻辑，通过负载均衡分配请求，节点可互相替补。 餐馆案例：生意火爆，新增多名厨师，所有厨师都能独立完成洗菜、切菜、炒菜全套流程，任意厨师请假，其他人可以顶替。多名厨师构成集群。

3.2 分布式定义

把完整业务拆分为多个不同子系统，分别部署在不同服务器，每个子系统只负责部分工作，依靠网络协作完成全流程。 餐馆案例：拆分岗位，专人配菜、专人炒菜；配菜师只洗菜切配，厨师只炒菜，两者工作不同，无法互相替代，整体后厨属于分布式架构。

3.3 集群 + 混合场景（重点）

分布式架构内的单个业务模块，可以再次做集群扩容。 餐馆完整例子：

1. 分布式拆分：配菜组、炒菜组两大岗位；
2. 配菜组人手不足，新增多名配菜师，多名配菜师构成集群；
3. 炒菜组同步新增多名厨师，厨师构成集群； 整体：分布式大架构，内部子模块使用集群扩容。

3.4 集群与分布式三大核心区别

1. 业务逻辑 集群：多机器做同一件事；分布式：多机器做不同业务。
2. 节点可替代性 集群：节点功能一致，故障可替换；分布式：每个模块职责唯一，节点故障对应业务直接中断。
3. 组合关系 分布式架构普遍内置集群，开发中不会严格区分两个概念，统一称为分布式系统。

4 微服务定义、优缺点、落地选型思路

4.1 分布式拆分遗留问题

简单垂直拆分（粗粒度分布式）存在大量公共代码重复：电商后台、订单、支付系统都需要商品查询逻辑，重复开发，维护成本高。 解决方案：进一步精细化拆分，把公共、可复用业务抽离成独立小型服务，微服务架构诞生。

4.2 微服务标准定义

微服务是粒度更精细的分布式架构：

1. 拆分标准：单一职责，一个服务只完成一类独立业务；
2. 部署特性：独立工程、独立数据库、独立团队、单独上线；
3. 通信方式：服务之间通过 IPC（HTTP/Dubbo）接口通信；
4. 边界说明：没有绝对统一的 “微小” 标准，行业通用判定：单个服务对外接口数量极少（个位数，甚至单接口）。

对比区分

粗分布式：电商整体拆分为前台、后台两大系统； 微服务：拆分为用户、商品、订单、支付、库存、商家 6 个独立服务。

4.3 分布式 VS 微服务核心差异

1. 拆分粒度 分布式：粗粒度，简单切割即可；微服务：极致细粒度，拆至单一能力。
2. 设计侧重 分布式：侧重拆分分摊服务器压力；微服务：侧重业务专业化、解耦复用。
3. 包含关系 微服务一定是分布式架构；分布式不一定是微服务。
4. 衍生问题 微服务拆分更细，服务数量更多，分布式带来的网络、运维、监控问题会成倍放大。

4.4 微服务四大优势

1. 开发维护简单：单个服务代码量小，业务单一，新人上手快，修改功能不会影响其他服务。 类比企业：行政、财务、人事分工明确，每个人只处理自身业务，不用兼顾全公司琐事。
2. 故障隔离（高容错）：单个服务宕机，其余业务正常运行；单体一处报错全系统瘫痪。 类比：行政请假不影响财务、运营正常办公。
3. 弹性按需扩容：访问量高的服务单独增加节点，低流量服务保持少量实例，资源利用率最大化。 电商例子：订单并发极高部署 10 台，商品浏览量中等部署 3 台，后台管理低并发仅 1 台。
4. 技术栈灵活自由：不同服务可根据业务选型，算法服务用 Python、底层中间件用 C++、业务系统统一 Java。

4.5 微服务六大核心挑战（Spring Cloud 全部对应解决）

1. 服务依赖复杂：服务数量多，调用链路错综复杂，修改一个服务要评估全部上游调用方。
2. 运维成本暴涨：数十个服务需要单独编译、打包、部署，运维人员需要掌握多语言、多环境部署。
3. 网络不可靠：服务之间通过网络调用，存在超时、丢包、异常，开发测试难度提升。
4. 全链路监控困难：单体只需监控一个项目；微服务需要追踪整条调用链路，每个服务单独监控指标。
5. 负载均衡刚需：单个服务多实例部署，请求需要自动分配，手动写 IP 无法实现分流。
6. 服务地址管理难题：服务 IP、端口经常变更，硬编码地址需要频繁改代码上线。

4.6 架构落地选型标准（无最优架构，适配业务才最好）

1. 小型内部系统（图书管理、企业 OA）：单体架构，拆分反而增加开发运维成本；
2. 初创业务、短期低并发：初期单体，业务增长后再拆分；
3. 预判长期高并发、多团队协同开发：直接采用微服务架构； 案例：创业公司老板一人包揽讲课、财务、保洁（单体）；业务扩张拆分技术、行政（分布式）；业务爆炸再细分上课、答疑、人事、财务（微服务）。盲目一步到位微服务会造成大量人力浪费。

5 Spring Cloud 体系详解（Netflix、Alibaba 两大阵营对比）

5.1 Spring Cloud 官方定义

分布式微服务一站式开发规范，整合各类成熟开源组件，统一标准化封装，提供微服务全套解决方案；所有第三方组件必须遵循 Spring 规范才能集成。 类比全屋智能平台：平台统一标准，小米、美的各类家电（第三方组件）符合标准即可接入。

5.2 两大主流实现厂商

5.2.1 Spring Cloud Netflix（第一代旧方案）

1. 出品方：Netflix 公司开源 OSS 套件
2. 核心组件：Eureka（注册中心）、Ribbon（负载均衡）、Feign（远程调用）、Hystrix（熔断）、Zuul（网关） 3 历史地位：早年 Spring Cloud 官方默认配套方案，市场大规模落地；
3. 重大变更：2018 年 Netflix 宣布所有核心组件进入仅维护、不再迭代状态，2020 版本后 Spring Cloud 官方移除大部分组件，仅短期兼容 Eureka 1.x；
4. 缺陷：停止更新，新项目长期使用存在安全、性能风险。

5.2 Spring Cloud Alibaba（第二代国内主流方案）

1. 出品方：阿里中间件团队，完全遵循 Spring Cloud 规范开发；
2. 核心组件：Nacos（注册 + 配置中心）、Dubbo RPC、Sentinel 熔断、Gateway、Seata 分布式事务；
3. 优势：持续高速迭代，中文文档完善，覆盖注册、配置、限流、事务全场景，功能比 Netflix 套件更全面；
4. 行业现状：国内互联网、传统企业主流微服务框架，企业落地量远超 Netflix。

5.3 两大体系核心组件对照表

表格

能力需求	Spring Cloud Netflix（旧）	Spring Cloud 官方原生	Spring Cloud Alibaba（新）
服务注册发现	Eureka	无内置	Nacos
客户端负载均衡	Ribbon	Spring Cloud LoadBalancer	LoadBalancer 兼容
远程调用	Feign	OpenFeign	Dubbo
配置中心	Config	Config	Nacos（注册配置二合一）
熔断限流	Hystrix	Resilience4j	Sentinel
API 网关	Zuul	Spring Cloud Gateway	Spring Cloud Gateway

5.4 版本配套硬性规则

Spring Cloud 版本必须和 Spring Boot 严格对应，课程固定配套： Spring Boot 3.1.6 + Spring Cloud 2022.0.3 + JDK17 禁止随意混搭高低版本，会出现依赖报错、功能失效问题。

6 开发环境完整安装指南（Windows/Ubuntu/CentOS JDK17+MySQL）

6.1 JDK17 选型原因

Oracle JDK 发布策略：9、10、16 等短期版本仅半年维护；长期支持 LTS 版本：8、11、17、21；

1. JDK8：老旧，部分新 Spring Boot 特性不兼容；
2. JDK11：可用，但 17 新特性、性能优化更好；
3. JDK21：2023 年 9 月发布，线上生产验证案例不足；
4. JDK17：2021 发布，经过大量项目验证稳定，课程统一环境。

6.1.1 Windows JDK17 安装步骤

1. 官网下载 Windows exe 安装包；
2. 自定义安装目录（建议非 C 盘）；
3. 配置系统环境变量：JAVA_HOME=JDK 根目录；Path 追加%JAVA_HOME%\bin；
4. CMD 执行java -version，输出版本即安装成功； 区分：Oracle JDK 商用付费，OpenJDK 免费开源，学习生产推荐 OpenJDK。

6.1.2 Ubuntu20.04 OpenJDK 安装

1. 更新软件源：sudo apt update
2. 一键安装 OpenJDK17：sudo apt install openjdk-17-jdk
3. 输入 Y 确认安装，完成后java -version校验； 卸载命令：查询已安装 jdk 包，apt-get remove 对应包。

6.1.3 CentOS JDK17 安装

1. 通过 wget 下载 Linux 压缩包；
2. 解压至自定义目录，手动配置 /etc/profile 环境变量；
3. 终端校验 java 版本。

6.2 MySQL 全平台安装 + 安全加固

6.2.1 Ubuntu MySQL 安装

1. 安装命令：apt install mysql-server
2. 查看服务状态：systemctl status mysql，active running 代表启动；
3. 安全初始化脚本mysql_secure_installation（必做）： ① 开启密码强度校验组件；② 设置强密码等级 2；③ 删除匿名用户；④ 禁止 root 远程登录；⑤ 删除 test 测试库；⑥ 刷新权限生效；
4. 无密码登录 MySQL，执行 SQL 修改 root 账号密码。

6.2 CentOS MySQL 安装

1. 下载 MySQL 官方 rpm 安装包；
2. yum 命令安装，启动服务；
3. 读取日志文件 /var/log/mysql 获取临时 root 密码；
4. 登录重置密码。

6.3 课程数据库设计（微服务一库一库规范）

业务：订单服务、商品服务两个独立微服务，各自独立数据库，实现数据隔离。

6.3.1 库 1：cloud_order（订单库）

表名：t_order 字段：order_id (主键)、user_id、product_id、number (购买数量)、price (分存储)、delete_flag、create_time、update_time；

6.3.2 库 2：cloud_product（商品库）

表名：t_product 字段：product_id (主键)、product_name、price、status、create_time、update_time； 配套初始化插入测试数据，SQL 脚本提供在课程资料，直接在客户端批量执行建库、建表、插入语句。

7 Maven 父子工程搭建完整实操

7.1 父子工程核心作用

1. 父工程（pom 打包）：统一管理所有依赖版本，集中定义 Spring Cloud、MyBatis、MySQL 版本；
2. 子模块（jar 打包）：eureka-server、order-service、product-service 独立可运行微服务；
3. 开发优势：多服务同一窗口管理，无需切换多个 IDEA 窗口。

7.2 父工程 pom 核心标签区分

1. <dependencies>：直接引入依赖，所有子模块自动继承，全部加载；
2. <dependencyManagement>：仅声明版本，不会实际引入依赖；子模块需要该组件时，无需写 version，简化版本维护； 父工程打包方式必须设置<packaging>pom</packaging>，禁止 jar。

7.3 完整搭建步骤

1. IDEA 新建空 Maven 父项目，删除 src 源码文件夹（父工程无业务代码）；
2. 完善父 pom：指定 Spring Boot、Spring Cloud、MyBatis、MySQL 全套版本；
3. 新建子模块 Model： ① eureka-server（注册中心） ② order-service（订单微服务） ③ product-service（商品微服务）
4. 每个子模块自动继承父工程 parent，仅需要业务依赖，不用管理版本；
5. 子模块 pom 引入 spring-boot-maven-plugin 打包插件，支持 jar 包构建。

8 单体基础服务三层代码完整实现

8.1 商品服务 product-service（端口 9090）

8.1.1 项目包结构

com.bit.product

• 启动类：ProductServiceApplication
• controller：ProductController
• service：ProductService
• mapper：ProductMapper
• model：ProductInfo 实体类

8.1.2 application.yml 配置

1. server.port=9090
2. 数据库 cloud_product 连接地址、账号密码
3. MyBatis 配置：映射文件路径、开启 SQL 打印、驼峰自动转换

8.1.3 实体类 ProductInfo

对应数据库字段，使用 Lombok 简化 get/set（父工程统一管理 lombok 依赖，子直接使用）；

8.1.4 Mapper 接口

@Mapper 注解，方法：ProductInfo selectProductById (Integer productId)，对应单商品查询 SQL；

8.1.5 Service 层

@Service，注入 ProductMapper，封装根据 ID 查询商品方法；

8.1.6 Controller 层

@RestController @RequestMapping ("/product") 接口：GET /{productId}，接收路径参数，调用 service 返回商品实体。

8.2 订单服务 order-service（端口 8080）

包结构、三层架构和商品服务完全一致； 数据库 cloud_order，接口：GET /order/{orderId} 查询订单基础信息； 初始版本无远程调用，仅查询本地订单表。

9 RestTemplate 硬编码远程调用实现及缺陷

9.1 业务需求扩展

订单接口不仅要返回订单自身信息，还需要携带对应商品完整名称、价格，订单库仅存 product_id，必须远程调用商品服务接口获取商品数据。

9.2 RestTemplate 使用步骤

1. 新建配置类 BeanConfig，添加 @Configuration；
2. @Bean public RestTemplate restTemplate(){return new RestTemplate();}
3. OrderService 中 @Autowired 注入 RestTemplate；
4. 硬编码 URL 调用：http://127.0.0.1:9090/product/ + productId；
5. 接收 ProductInfo，赋值到 OrderInfo 新增 product 属性，完整返回。

9.3 硬编码四大致命缺陷

1. 商品服务 IP / 端口变更，必须修改代码、重新打包发布；
2. 商品多实例部署时，无法自动负载均衡，流量全部打单台； 3 URL 手写极易拼写错误，无编译校验； 4 服务地址统一管理困难，项目多了维护成本极高。

10 RESTful API 规范、优缺点详解

10.1 REST 概念全称：表现层状态转移

1. 资源：网络中所有数据（商品、订单、图片）都是资源，用唯一 URL 标识；
2. 表现层：资源返回格式 JSON/XML/HTML；
3. 状态转移：通过 HTTP Method（GET/POST/PUT/DELETE）实现增删改查，改变资源状态。

10.2 RESTful 接口标准

1 URL 只标识资源，不携带操作动词； 2 操作行为依靠 HTTP 方法区分： GET 查询、POST 新增、PUT 修改、DELETE 删除；

10.3 RESTful 实际开发缺陷

1 仅看 URL 无法区分操作，调试需要抓包查看请求方式，团队沟通麻烦； 2 浏览器仅原生支持 GET、POST，PUT/DELETE 需要额外处理； 3 复杂业务无法单纯用增删改查概括，强行设计接口增加开发成本； 企业开发大多不完全严格遵守 REST 规范，URL 增加 get/add 动词提升可读性。

11 服务注册与发现核心思想（114 查号台类比）

11.1 生活类比

游客需要查询景区电话，不会逐个询问景区，拨打 114 查号台；

1. 景区（服务提供者）主动登记电话到 114；
2. 游客（服务消费者）查询 114 获取号码再拨号；
3. 114（注册中心）统一维护机构名称 + 联系方式映射。

11.2 微服务对应角色

1 服务提供者：对外提供接口服务（product-service），启动时注册自身 IP、端口、服务名； 2 服务消费者：调用其他服务（order-service），调用前从注册中心拉取服务实例； 3 注册中心：统一存储所有服务注册元数据，提供注册、查询能力。

11.3 两个核心动作

1 服务注册：提供者启动上报信息，定时发送心跳包证明存活； 2 服务发现：消费者启动拉取全部服务列表缓存本地，调用时根据服务名获取地址。

12 CAP 理论深度拆解（分布式底层基石）

12.1 三要素定义

1 C 强一致性：分布式所有节点同一时间查询数据完全相同； 2 A 可用性：任意客户端请求一定收到响应（哪怕旧数据）； 3 P 分区容错：网络断开、节点失联等网络故障，系统仍可对外提供服务；

12.2 核心结论

分布式系统网络故障不可避免，P 分区容错必须保证，因此 C 和 A 只能二选一： 1 CP 架构：放弃可用性，保证数据一致；网络故障系统暂停对外读写（Zookeeper）； 2 AP 架构：放弃实时一致性，保证系统随时可用，允许短暂数据不一致（Eureka/Nacos 临时实例）；

12.3 银行生活化案例

银行统一下调利率，通知下发存在时间差： 强一致性（C）：全部员工收到通知后才接待客户，期间暂停咨询（不可用）； 可用性（A）：员工立刻接待，部分人展示旧利率（数据不一致）； 分区故障：某个网点断网，其他网点正常营业（分区容错 P）。

12.4 数据库主从 CAP 演示

主库写入数据，同步从库网络中断： CP 方案：停止查询，保证数据一致； AP 方案：从库返回旧数据，保证查询可用。

13 主流注册中心功能对比

13.1 Zookeeper

架构：CP，保证强一致性； 缺陷：主节点宕机需要重新选举，选举期间集群不可用；适合分布式锁，不适合微服务注册。

13.2 Eureka

Netflix 开源，AP 架构，优先可用性； 节点对等无主从，网络故障仍可正常查询服务； 缺陷：官方停止迭代，新项目淘汰，存量老项目继续使用。

13.3 Nacos

阿里开源，混合架构：临时实例 AP（微服务调用）、持久实例 CP（配置）； 注册 + 配置中心二合一，功能全面，国内企业首选。

14 Eureka Server 注册中心完整搭建四步

1. 创建 eureka-server 子模块，引入 eureka-server 依赖； 2 编写 application.yml 配置： server.port=10010 eureka.client.fetch-registry=false # 不拉取服务 e.client.register-with-eureka=false # 不注册自身 3 启动类添加 @EnableEurekaServer 开启注册中心； 4 启动后访问localhost:10010可视化控制台查看注册列表。

15 Eureka Client 服务注册 + 服务发现完整改造

15.1 服务提供者（商品服务注册）

1 pom 引入 spring-cloud-starter-netflix-eureka-client； 2 yml 配置 spring.application.name=product-service，填写 eureka 注册地址； 3 启动类添加 @EnableDiscoveryClient； 4 启动项目，刷新 10010 控制台，出现 product-service 代表注册成功。

15.2 服务消费者（订单服务实现服务发现）

1 同样引入 eureka-client 依赖，配置服务名、注册地址； 2 注入 DiscoveryClient 对象； 3 远程调用改造：不再硬编码 IP，通过 discoveryClient.getInstances ("product-service") 获取实例列表； 4 取出实例 getUri () 拼接请求地址，动态调用商品接口； 缺陷：多实例时只会取列表第一个节点，无负载均衡。

16 手写轮询负载均衡 Demo

商品启动 9090、9091、9092 三个实例，DiscoveryClient 每次取列表固定第一个，流量无法分摊；

手写轮询实现思路

1 使用 AtomicInteger 原子计数器，保证并发安全； 2 每次请求计数器自增； 3 计数器对实例集合长度取模，选中对应下标实例；

手写缺陷

1 项目启动时一次性拉取实例，运行中新增 / 下线实例无法感知； 2 无故障实例剔除逻辑，实例宕机仍会分配流量。

17 Spring Cloud LoadBalancer 标准使用、自定义策略

17 官方替代 Ribbon，2020 版本后内置客户端负载均衡

基础使用两步

1 RestTemplate 配置类添加 @LoadBalanced 注解； 2 远程 URL 直接写服务名 http://product-service，无需 IP 端口； 底层拦截器自动解析服务名，从注册中心获取实例，执行均衡策略。

内置两种默认策略

1 轮询：请求依次分配每一台实例（默认）； 2 随机：随机挑选实例；

自定义负载均衡策略

1 新建策略类实现 LoadBalancer 接口，自定义分配逻辑； 2 使用 @LoadBalancerClient 注解绑定该策略到指定服务； 3 注意：策略类不能被全局 @ComponentScan 扫描，避免全局生效。

底层原理

LoadBalancerInterceptor 拦截所有 HTTP 请求，截取服务名称，从注册中心拉取实例清单，执行均衡算法筛选实例，拼接真实地址发起调用。

18 项目 Linux 云服务器打包部署全流程

1 环境前置

1 云服务器安装 JDK17、MySQL，执行业务建库建表 SQL； 2 多环境 Profile 区分 dev 本地、prod 生产，maven 打包指定环境；

打包步骤

父工程执行 mvn clean package，分别打包 eureka、order、product 三个 jar；

服务器操作

1 上传 jar 包至 Linux 自定义文件夹； 2 新建 logs 日志文件夹，nohup 后台启动服务并输出日志文件； 启动示例：nohup java -jar eureka.jar > logs/eureka.log 2>&1 & 3 商品多实例启动：通过 --server.port 指定不同端口； 4 云服务器安全组开放所有端口（10010、8080、9090、9091、9092）； 5 公网 IP 访问注册中心、接口验证服务注册与调用。

19 Eureka 与 Nacos 迭代、行业落地

1 2018 年 Eureka 宣布停止新版本开发，同年阿里开源 Nacos； 2 Nacos 同时提供注册中心 + 分布式配置，一站式解决两大需求； 3 国内互联网、制造业、金融企业全部大规模采用 Spring Cloud Alibaba Nacos； 4 老项目存量 Eureka 可继续维护，新项目直接选用 Nacos。