一、微服务核心认知入门第一步先懂底层逻辑再碰技术1. 什么是微服务微服务是一种分布式架构风格核心是将一个大型单体应用按业务领域边界拆分成多个小型、自治、可独立部署的服务每个服务聚焦单一业务职责服务之间通过轻量级通信协议HTTP/RPC/ 消息队列协同共同完成完整的业务功能。与之对应的是传统单体架构两者核心差异如下维度单体架构微服务架构代码结构所有业务模块打包在一个工程部署在一个进程按业务拆分为多个独立工程每个服务独立部署在独立进程数据库共享一个数据库每个服务独立数据库数据自治技术栈统一技术栈无法灵活替换每个服务可按需选择不同技术栈部署迭代一处修改全量打包部署风险高单个服务可独立开发、测试、部署迭代效率高扩展能力整体扩容无法针对高负载模块单独扩容可针对高并发服务单独扩容资源利用率高故障影响一处故障整个应用崩溃故障隔离单个服务故障不影响整体核心链路复杂度开发简单分布式复杂度低引入分布式全链路复杂度运维成本高2. 微服务的核心特征单一职责一个服务只负责一个明确的业务领域做到 “高内聚、低耦合”服务自治每个服务拥有独立的开发、测试、部署、运维生命周期不依赖其他服务的部署数据自治每个服务管理自己的数据库禁止跨服务直接访问数据库仅通过接口暴露数据轻量级通信服务间采用与语言、平台无关的通信协议RESTful HTTP、RPC、消息队列去中心化治理避免统一的技术标准强制约束允许团队按需选择技术栈同时避免集中式的服务管控节点提升可用性故障隔离具备完善的容错、熔断、降级能力防止单个服务故障引发全链路雪崩3. 微服务的优缺点 适用场景核心优势高可扩展性可针对高频业务单独扩容精准应对流量峰值迭代效率高多团队可并行开发不同服务互不干扰缩短交付周期技术栈灵活可针对不同服务的特性选择适配的技术如大数据服务用 Python核心交易用 Java故障隔离性强单个服务故障不会导致整个系统瘫痪提升系统可用性可渐进式重构老旧单体系统可逐步拆分迁移到微服务无需一次性全量重构核心劣势分布式系统复杂度陡增引入了网络延迟、数据一致性、服务依赖、链路追踪等一系列分布式问题运维成本大幅提升从管理 1 个单体应用变成管理十几个甚至几十个服务对运维、监控、容器化能力要求极高排障难度大一个业务请求可能跨多个服务问题定位需要全链路追踪能力分布式事务难题跨多个服务 / 数据库的事务一致性是微服务最棘手的问题之一接口兼容与版本管理成本高服务间依赖复杂接口变更需要严格的版本管理避免引发依赖服务故障适用场景 不适用场景✅适用场景中大型团队、业务复杂度高需要多团队并行开发业务模块访问量差异大需要针对性扩容对系统可用性、迭代效率有高要求能接受对应的运维成本业务需要长期迭代架构需要具备灵活的扩展能力❌不适用场景初创团队、小项目业务简单、流量小硬上微服务只会降低开发效率团队缺乏分布式系统、容器化运维的技术积累业务逻辑强耦合无法清晰拆分业务边界4. 微服务核心理论基础康威定律系统设计的边界必然与组织沟通边界保持一致。简单说就是 “团队结构决定系统架构”微服务拆分必须匹配团队的组织架构一个服务最好由一个完整的小团队负责。CAP 定理分布式系统中一致性Consistency、可用性Availability、分区容错性Partition tolerance三者不可兼得最多只能满足两项。微服务架构中网络分区是必然存在的因此只能在 CP 和 AP 之间做取舍核心交易场景优先 CP非核心查询场景优先 AP。BASE 理论CAP 定理的落地实践核心是基本可用Basically Available、软状态Soft State、最终一致性Eventually Consistent。微服务中绝大多数场景不需要强一致性只需要保证数据最终一致即可以此换取系统的高可用性。二、微服务学习前置知识必须先打牢否则寸步难行微服务不是独立的技术而是架构体系必须先掌握以下基础否则直接学习会举步维艰。核心前置必须熟练掌握编程语言 基础框架Java 8 核心语法、Lambda、Stream、并发编程基础Maven/Gradle 依赖管理、多模块项目搭建Spring Boot 2.x/3.x微服务的基石必须熟练掌握自动配置、Starter、AOP、拦截器、全局异常处理、整合 MyBatis/MyBatis-Plus、Redis 等计算机网络基础HTTP/HTTPS 协议、TCP/IP 四层模型、RESTful API 设计规范RPC 基本原理、Socket 网络编程基础数据存储基础MySQL 核心原理、索引、事务、锁机制、分库分表基础Redis 核心数据结构、缓存策略、分布式锁、缓存雪崩 / 击穿 / 穿透解决方案容器化基础Docker 核心操作、镜像 / 容器管理、Dockerfile 编写、镜像仓库使用微服务目前几乎 100% 采用容器化部署Docker 是必备基础可选前置建议掌握提升学习效率Linux 常用命令、服务部署、Shell 脚本基础消息中间件基础RabbitMQ/RocketMQ/KafkaNginx 反向代理、负载均衡配置Git 版本控制、分支管理规范三、微服务核心组件 核心原理重中之重微服务的本质是用一系列组件解决分布式架构带来的各类问题。每个组件都要搞懂解决什么问题→核心原理→主流选型三个核心问题。1. 服务拆分原则微服务的第一步拆不好全是坑服务拆分是微服务最核心的前提拆分不合理后续所有技术都无法弥补架构缺陷。核心拆分原则高内聚低耦合、单一职责、数据自治、避免过度拆分、优先规避分布式事务拆分方法论按业务领域边界拆分核心不是按技术层Controller/Service/Dao拆分而是按业务领域如用户、商品、订单、支付拆分基于 DDD领域驱动设计的限界上下文拆分限界上下文就是业务边界一个限界上下文对应一个微服务遵循康威定律拆分结果匹配团队组织架构避免一个服务由多个团队维护也避免一个团队维护过多服务新手避坑初期优先粗粒度拆分后续再逐步细化不要一上来就拆十几个服务导致复杂度爆炸。2. 服务注册与发现解决的问题微服务实例动态上下线、服务地址动态管理、服务调用的自动寻址问题。如果没有注册中心需要手动维护所有服务的地址无法应对容器化环境下实例 IP 动态变化的场景。核心原理服务注册服务启动时将自己的 IP、端口、服务名等信息上报到注册中心服务续约服务定期向注册中心发送心跳证明自己存活服务下线服务停止时主动注销注册中心也会剔除长时间未发送心跳的实例服务拉取服务消费者从注册中心拉取对应服务的实例列表本地缓存主流选型Nacos国内首选阿里开源同时支持注册中心 配置中心AP/CP 模式可切换国内文档完善社区活跃其他选型EurekaNetflix 开源已停更、Consul、Etcd3. 配置中心解决的问题微服务实例多、环境多配置分散管理难度大配置修改需要重启服务配置无版本管理、无权限控制、无环境隔离。核心原理配置统一存储在配置中心服务启动时拉取对应配置配置变更时配置中心主动推送给服务实现配置动态刷新无需重启服务。主流选型Nacos国内首选和注册中心共用一套集群降低部署成本支持动态刷新、环境隔离、权限控制其他选型Apollo携程开源功能强大、Spring Cloud Config原生组件功能较弱4. 服务通信服务间通信是微服务协同的核心分为同步调用和异步调用两大类适用于不同的业务场景。同步通信适用场景需要实时获取返回结果的业务比如下单前查询商品库存主流实现方式RESTful HTTP基于 HTTP 协议JSON 格式传输跨语言、跨平台简单易用主流实现为OpenFeignSpring Cloud 原生组件可快速实现 HTTP 调用集成负载均衡RPC远程过程调用基于 TCP 协议二进制传输性能更高主流实现为Dubbo阿里开源、gRPCGoogle 开源选型建议对内服务间调用追求性能选 RPC对外暴露接口、跨语言场景选 HTTP RESTful。异步通信适用场景不需要实时结果、解耦服务、流量削峰、异步化处理的场景比如订单支付成功后异步发送短信通知、更新用户积分核心实现基于消息队列MQ实现主流选型为 RocketMQ阿里开源国内主流、RabbitMQ、Kafka核心优势服务解耦、流量削峰、异步提升吞吐量、故障隔离下游服务故障不影响上游核心流程5. 负载均衡解决的问题将请求均匀分发到多个服务实例提升系统吞吐量和可用性避免单个实例压力过大两大类型客户端负载均衡微服务主流负载均衡逻辑在服务消费者端执行消费者本地缓存服务实例列表根据负载均衡策略选择实例发起调用主流实现为Spring Cloud LoadBalancer服务端负载均衡集中式负载均衡请求先经过负载均衡节点再转发到服务实例主流实现为 Nginx、F5核心负载策略轮询、权重轮询、随机、一致性哈希、最小连接数6. 服务容错熔断、降级、限流解决的核心问题分布式系统的雪崩效应—— 单个服务故障导致上游调用服务线程阻塞故障逐级向上扩散最终导致整个集群瘫痪。核心概念熔断当下游服务故障比例达到阈值比如 50% 请求超时熔断器直接打开后续请求不再调用故障服务直接返回降级结果避免故障扩散一段时间后熔断器进入半开状态尝试放行少量请求验证服务是否恢复降级高峰期或系统故障时主动关闭非核心功能比如商品详情页的推荐功能释放服务器资源保障核心功能下单、支付的可用限流限制请求的并发数 / QPS超过阈值的请求直接拒绝防止系统被突发流量打垮主流选型Sentinel国内首选阿里开源轻量级支持熔断、降级、限流、热点参数防护国内文档完善适配 Spring Cloud Alibaba其他选型Resilience4j、HystrixNetflix 开源已停更7. API 网关解决的问题微服务有多个服务实例对外暴露的地址分散无法统一管理认证授权、流量控制、路由规则客户端需要对接多个服务地址对接成本高。核心定位微服务集群的唯一入口所有外部请求先经过网关再转发到对应服务类似 “小区大门”。核心功能路由转发、统一认证授权、流量控制、熔断降级、日志监控、协议转换、跨域处理、IP 黑白名单主流选型Spring Cloud Gateway首选Spring Cloud 官方原生网关基于 WebFlux 非阻塞响应式编程性能高完美适配 Spring Cloud 生态其他选型APISIX、Kong、ZuulNetflix 开源已停更性能差8. 分布式事务解决的问题跨多个服务 / 多个数据库的事务一致性问题。单体架构中一个事务内的多个操作都在一个数据库中本地事务即可保证一致性微服务中下单扣库存、扣余额分属不同服务的不同数据库本地事务无法生效。核心解决方案 适用场景方案核心原理一致性性能适用场景AT 模式Seata两阶段提交自动生成反向回滚 SQL无侵入强一致性高绝大多数非高并发的核心交易场景首选方案TCC手动实现 Try-Confirm-Cancel 三个阶段代码侵入性强强一致性高高并发、短事务的核心交易场景SAGA长事务拆分多个本地事务失败时执行补偿事务最终一致性中长事务、流程复杂的业务场景事务消息基于 MQ 的半消息机制保证本地事务和消息发送的原子性最终一致性高异步化、可接受最终一致性的场景主流选型Seata阿里开源国内主流支持 AT/TCC/SAGA 等多种模式适配 Spring Cloud Alibaba学习成本低。新手避坑优先通过业务设计避免分布式事务而不是一上来就用分布式事务方案。9. 分布式链路追踪解决的问题一个业务请求可能跨多个服务出现超时、报错时无法快速定位是哪个服务出了问题无法排查全链路的性能瓶颈。核心原理为每个请求生成唯一的TraceID请求每经过一个服务生成对应的SpanID通过 TraceID 串联整个调用链路记录每个服务的调用耗时、状态、异常信息最终实现全链路可视化。主流选型SkyWalking国内首选Apache 顶级项目无侵入式埋点支持链路追踪、性能监控、告警功能全面国内社区活跃其他选型Zipkin、Jaeger、Pinpoint10. 配套基础设施日志中心解决服务实例多、日志分散的问题主流方案为 ELK 栈ElasticsearchLogstashKibana、EFK 栈监控告警体系实时监控服务的 CPU、内存、接口响应时间、错误率等指标故障提前预警主流方案为Prometheus Grafana行业标准容器编排大规模微服务集群的部署、调度、运维主流方案为KubernetesK8s四、主流微服务技术栈选型指南目前国内企业主流的微服务技术栈分为三大体系新手优先选择 Spring Cloud Alibaba避免走弯路。1. 首选体系Spring Cloud Alibaba新手入门首选国内企业主流优势组件全、国内文档丰富、社区活跃、长期维护、完美适配国内云环境学习资料多踩坑容易找到解决方案版本建议稳定版资料最多Spring Boot 2.7.x Spring Cloud 2021.0.x Spring Cloud Alibaba 2021.0.1.0核心组件对应关系微服务核心能力对应组件服务注册与发现Nacos配置中心Nacos服务远程调用OpenFeign / Dubbo负载均衡Spring Cloud LoadBalancer熔断降级限流SentinelAPI 网关Spring Cloud Gateway分布式事务Seata分布式链路追踪SkyWalking监控告警Prometheus Grafana日志中心ELK/EFK2. 原生 Spring CloudNetflix 体系不推荐新手入门现状Netflix 开源的核心组件Eureka、Ribbon、Hystrix、Zuul大多已停止维护国内企业使用占比持续下降仅适合了解微服务发展历史维护老旧项目3. 云原生体系Service Mesh服务网格进阶学习核心思想将业务逻辑和网络通信解耦微服务的流量管控、熔断、限流、链路追踪等能力全部下沉到基础设施层通过 Sidecar 代理实现业务代码无侵入主流选型Istio Envoy适用场景大规模微服务集群、多语言技术栈、云原生环境学习建议新手不建议直接上手先把 Spring Cloud 体系搞懂理解微服务的核心问题和解决方案后再学习 Service Mesh五、循序渐进的学习路径 实操计划新手严格按照以下阶段学习避免盲目看视频、堆技术栈做到学一个、会一个、用一个。阶段一筑基阶段2-3 周必须打牢禁止跳步核心目标熟练掌握 Spring Boot搞定所有前置知识学习内容Java 8 新特性Lambda、Stream、Optional、线程池Maven 多模块项目搭建、依赖管理Spring Boot 核心自动配置原理、Starter 开发、AOP、全局异常处理、参数校验、整合 MyBatis-Plus、Redis、Swagger/Knife4jDocker 核心操作、Dockerfile 编写、镜像打包与推送实操任务用 Spring Boot 开发一个单体 CRUD 项目如商品管理系统包含完整的接口规范、异常处理、数据库操作、缓存功能为项目编写 Dockerfile打成镜像并在本地运行阶段二核心组件入门阶段3-4 周逐个攻破核心目标掌握每个核心组件的作用、原理、基础使用理解每个组件解决的问题学习顺序按依赖关系不要乱序微服务基础理论康威定律、CAP/BASE 理论、服务拆分原则Nacos搭建 Nacos 服务实现 2 个服务的注册发现配置集中管理与动态刷新OpenFeign LoadBalancer实现 2 个服务的远程调用验证负载均衡效果Sentinel实现熔断、降级、限流模拟服务故障验证容错效果Spring Cloud Gateway实现路由转发、断言、过滤器、集成 Sentinel 限流Seata搭建 Seata 服务实现 AT 模式的分布式事务模拟下单扣库存的跨服务事务场景SkyWalking搭建 SkyWalking 服务实现微服务全链路追踪查看调用链路与性能指标实操要求每个组件学完必须写对应的 Demo最终整合所有组件搭建一个包含 3-4 个服务的微服务 Demo跑通完整的调用链路阶段三项目实战阶段4-6 周知识体系化的核心核心目标从零到一搭建一个完整的、可落地的微服务项目把所有知识点串联起来形成完整的体系推荐实战项目电商微服务系统业务场景经典覆盖所有微服务核心能力项目拆分示例公共模块common通用工具类、全局异常、通用实体、枚举用户服务user-service用户注册登录、信息管理、权限认证商品服务goods-service商品管理、库存管理订单服务order-service订单创建、订单状态管理支付服务pay-service支付对接、支付状态同步项目必须包含的核心能力基于 Nacos 的服务注册发现与配置管理基于 OpenFeign 的服务间远程调用基于 Gateway 的统一网关入口与认证授权基于 Sentinel 的熔断降级限流基于 Seata 的分布式事务下单扣库存基于 SkyWalking 的全链路追踪基于 Redis 的缓存与分布式锁基于 RocketMQ 的异步解耦支付成功异步通知实操要求规范的多模块 Maven 结构清晰的代码分层每个服务独立数据库禁止跨服务访问数据库编写完整的接口文档、单元测试为每个服务编写 Dockerfile实现容器化部署本地完整运行模拟真实业务场景完成全流程测试阶段四进阶 优化阶段持续学习核心目标解决微服务高阶问题提升系统的高可用、高并发、高性能学习内容DDD 领域驱动设计深入学习 DDD用 DDD 指导服务拆分与代码设计高可用架构设计集群部署、异地多活、故障演练、容灾备份高并发优化缓存优化、分布式锁、异步化、池化技术、数据库分库分表云原生进阶KubernetesK8s、微服务 K8s 编排、CICD 流水线Jenkins/GitLab CIService MeshIstio 核心原理与落地实践微服务安全OAuth2.0/OIDC 统一认证、数据加密、接口防刷、API 安全性能压测JMeter 压测、性能瓶颈定位与优化阶段五面试 落地经验沉淀核心目标应对面试掌握企业级落地最佳实践核心动作整理微服务常见面试题深入理解底层原理而不是只停留在使用层面学习大厂微服务落地最佳实践总结避坑经验持续优化自己的实战项目沉淀到 GitHub形成自己的作品集六、新手常见坑 避坑指南过度拆分新手最容易犯的错误把服务拆得太细导致分布式复杂度指数级上升运维成本爆炸。建议初期粗粒度拆分后续逐步迭代不要一上来就拆十几个服务。为了微服务而微服务小团队、小项目、流量小硬上微服务反而降低开发效率。建议先单体后微服务当单体遇到性能、迭代瓶颈时再逐步拆分。数据不自治多个服务共享一个数据库等于白拆微服务。服务之间通过数据库耦合后续无法独立扩展和迭代。建议每个服务独立数据库服务之间只能通过接口通信。忽略分布式事务跨服务调用不处理事务一致性导致数据错乱。建议优先通过业务设计避免分布式事务必须使用时选择合适的方案不要自己手写。没有容错机制服务调用不做熔断降级一个服务故障导致整个集群雪崩。建议所有跨服务调用必须配置容错规则。缺失监控与链路追踪服务出问题找不到原因排障全靠猜。建议微服务搭建初期就必须把监控、链路追踪、日志中心搭起来。服务依赖混乱服务之间循环依赖调用链路像蜘蛛网。建议梳理清晰的服务依赖拓扑禁止循环依赖核心服务不依赖非核心服务。七、优质学习资源推荐官方文档首选最权威Spring Cloud Alibaba 官方文档https://sca.aliyun.com/docs/2023/overview/what-is-sca/Nacos 官方文档https://nacos.io/zh-cn/docs/what-is-nacos.htmlSentinel 官方文档https://sentinelguard.io/zh-cn/docs/introduction.htmlSeata 官方文档https://seata.io/zh-cn/docs/overview/what-is-seata.htmlSkyWalking 官方文档https://skywalking.apache.org/zh/书籍推荐《微服务设计》马丁・福勒著作微服务领域圣经入门必看理解微服务的核心思想《Spring Cloud Alibaba 微服务原理与实战》国内实战类书籍贴合国内技术栈适合新手《DDD 领域驱动设计精粹》薄而精快速掌握 DDD 核心思想指导服务拆分《凤凰架构》周志明著作深入讲解分布式系统核心原理提升架构深度开源项目参考mallhttps://github.com/macrozheng/mall国内最火的 Spring Cloud 电商微服务项目文档完善适合参考学习RuoYi-Cloudhttps://gitee.com/y_project/RuoYi-Cloud成熟的微服务管理系统脚手架适合快速搭建项目最后给新手的忠告微服务不是银弹它解决了高可用、高扩展的问题同时也带来了分布式系统的巨大复杂度。学习微服务一定要先搞懂 “为什么要这么做”再去学 “怎么实现”不要上来就堆技术栈。微服务是实战性极强的技术光看视频和文档永远学不会必须自己从零到一搭建项目踩坑、解决问题才能真正掌握。
微服务全体系学习笔记（从入门到落地）
发布时间：2026/7/11 4:32:07
一、微服务核心认知入门第一步先懂底层逻辑再碰技术1. 什么是微服务微服务是一种分布式架构风格核心是将一个大型单体应用按业务领域边界拆分成多个小型、自治、可独立部署的服务每个服务聚焦单一业务职责服务之间通过轻量级通信协议HTTP/RPC/ 消息队列协同共同完成完整的业务功能。与之对应的是传统单体架构两者核心差异如下维度单体架构微服务架构代码结构所有业务模块打包在一个工程部署在一个进程按业务拆分为多个独立工程每个服务独立部署在独立进程数据库共享一个数据库每个服务独立数据库数据自治技术栈统一技术栈无法灵活替换每个服务可按需选择不同技术栈部署迭代一处修改全量打包部署风险高单个服务可独立开发、测试、部署迭代效率高扩展能力整体扩容无法针对高负载模块单独扩容可针对高并发服务单独扩容资源利用率高故障影响一处故障整个应用崩溃故障隔离单个服务故障不影响整体核心链路复杂度开发简单分布式复杂度低引入分布式全链路复杂度运维成本高2. 微服务的核心特征单一职责一个服务只负责一个明确的业务领域做到 “高内聚、低耦合”服务自治每个服务拥有独立的开发、测试、部署、运维生命周期不依赖其他服务的部署数据自治每个服务管理自己的数据库禁止跨服务直接访问数据库仅通过接口暴露数据轻量级通信服务间采用与语言、平台无关的通信协议RESTful HTTP、RPC、消息队列去中心化治理避免统一的技术标准强制约束允许团队按需选择技术栈同时避免集中式的服务管控节点提升可用性故障隔离具备完善的容错、熔断、降级能力防止单个服务故障引发全链路雪崩3. 微服务的优缺点 适用场景核心优势高可扩展性可针对高频业务单独扩容精准应对流量峰值迭代效率高多团队可并行开发不同服务互不干扰缩短交付周期技术栈灵活可针对不同服务的特性选择适配的技术如大数据服务用 Python核心交易用 Java故障隔离性强单个服务故障不会导致整个系统瘫痪提升系统可用性可渐进式重构老旧单体系统可逐步拆分迁移到微服务无需一次性全量重构核心劣势分布式系统复杂度陡增引入了网络延迟、数据一致性、服务依赖、链路追踪等一系列分布式问题运维成本大幅提升从管理 1 个单体应用变成管理十几个甚至几十个服务对运维、监控、容器化能力要求极高排障难度大一个业务请求可能跨多个服务问题定位需要全链路追踪能力分布式事务难题跨多个服务 / 数据库的事务一致性是微服务最棘手的问题之一接口兼容与版本管理成本高服务间依赖复杂接口变更需要严格的版本管理避免引发依赖服务故障适用场景 不适用场景✅适用场景中大型团队、业务复杂度高需要多团队并行开发业务模块访问量差异大需要针对性扩容对系统可用性、迭代效率有高要求能接受对应的运维成本业务需要长期迭代架构需要具备灵活的扩展能力❌不适用场景初创团队、小项目业务简单、流量小硬上微服务只会降低开发效率团队缺乏分布式系统、容器化运维的技术积累业务逻辑强耦合无法清晰拆分业务边界4. 微服务核心理论基础康威定律系统设计的边界必然与组织沟通边界保持一致。简单说就是 “团队结构决定系统架构”微服务拆分必须匹配团队的组织架构一个服务最好由一个完整的小团队负责。CAP 定理分布式系统中一致性Consistency、可用性Availability、分区容错性Partition tolerance三者不可兼得最多只能满足两项。微服务架构中网络分区是必然存在的因此只能在 CP 和 AP 之间做取舍核心交易场景优先 CP非核心查询场景优先 AP。BASE 理论CAP 定理的落地实践核心是基本可用Basically Available、软状态Soft State、最终一致性Eventually Consistent。微服务中绝大多数场景不需要强一致性只需要保证数据最终一致即可以此换取系统的高可用性。二、微服务学习前置知识必须先打牢否则寸步难行微服务不是独立的技术而是架构体系必须先掌握以下基础否则直接学习会举步维艰。核心前置必须熟练掌握编程语言 基础框架Java 8 核心语法、Lambda、Stream、并发编程基础Maven/Gradle 依赖管理、多模块项目搭建Spring Boot 2.x/3.x微服务的基石必须熟练掌握自动配置、Starter、AOP、拦截器、全局异常处理、整合 MyBatis/MyBatis-Plus、Redis 等计算机网络基础HTTP/HTTPS 协议、TCP/IP 四层模型、RESTful API 设计规范RPC 基本原理、Socket 网络编程基础数据存储基础MySQL 核心原理、索引、事务、锁机制、分库分表基础Redis 核心数据结构、缓存策略、分布式锁、缓存雪崩 / 击穿 / 穿透解决方案容器化基础Docker 核心操作、镜像 / 容器管理、Dockerfile 编写、镜像仓库使用微服务目前几乎 100% 采用容器化部署Docker 是必备基础可选前置建议掌握提升学习效率Linux 常用命令、服务部署、Shell 脚本基础消息中间件基础RabbitMQ/RocketMQ/KafkaNginx 反向代理、负载均衡配置Git 版本控制、分支管理规范三、微服务核心组件 核心原理重中之重微服务的本质是用一系列组件解决分布式架构带来的各类问题。每个组件都要搞懂解决什么问题→核心原理→主流选型三个核心问题。1. 服务拆分原则微服务的第一步拆不好全是坑服务拆分是微服务最核心的前提拆分不合理后续所有技术都无法弥补架构缺陷。核心拆分原则高内聚低耦合、单一职责、数据自治、避免过度拆分、优先规避分布式事务拆分方法论按业务领域边界拆分核心不是按技术层Controller/Service/Dao拆分而是按业务领域如用户、商品、订单、支付拆分基于 DDD领域驱动设计的限界上下文拆分限界上下文就是业务边界一个限界上下文对应一个微服务遵循康威定律拆分结果匹配团队组织架构避免一个服务由多个团队维护也避免一个团队维护过多服务新手避坑初期优先粗粒度拆分后续再逐步细化不要一上来就拆十几个服务导致复杂度爆炸。2. 服务注册与发现解决的问题微服务实例动态上下线、服务地址动态管理、服务调用的自动寻址问题。如果没有注册中心需要手动维护所有服务的地址无法应对容器化环境下实例 IP 动态变化的场景。核心原理服务注册服务启动时将自己的 IP、端口、服务名等信息上报到注册中心服务续约服务定期向注册中心发送心跳证明自己存活服务下线服务停止时主动注销注册中心也会剔除长时间未发送心跳的实例服务拉取服务消费者从注册中心拉取对应服务的实例列表本地缓存主流选型Nacos国内首选阿里开源同时支持注册中心 配置中心AP/CP 模式可切换国内文档完善社区活跃其他选型EurekaNetflix 开源已停更、Consul、Etcd3. 配置中心解决的问题微服务实例多、环境多配置分散管理难度大配置修改需要重启服务配置无版本管理、无权限控制、无环境隔离。核心原理配置统一存储在配置中心服务启动时拉取对应配置配置变更时配置中心主动推送给服务实现配置动态刷新无需重启服务。主流选型Nacos国内首选和注册中心共用一套集群降低部署成本支持动态刷新、环境隔离、权限控制其他选型Apollo携程开源功能强大、Spring Cloud Config原生组件功能较弱4. 服务通信服务间通信是微服务协同的核心分为同步调用和异步调用两大类适用于不同的业务场景。同步通信适用场景需要实时获取返回结果的业务比如下单前查询商品库存主流实现方式RESTful HTTP基于 HTTP 协议JSON 格式传输跨语言、跨平台简单易用主流实现为OpenFeignSpring Cloud 原生组件可快速实现 HTTP 调用集成负载均衡RPC远程过程调用基于 TCP 协议二进制传输性能更高主流实现为Dubbo阿里开源、gRPCGoogle 开源选型建议对内服务间调用追求性能选 RPC对外暴露接口、跨语言场景选 HTTP RESTful。异步通信适用场景不需要实时结果、解耦服务、流量削峰、异步化处理的场景比如订单支付成功后异步发送短信通知、更新用户积分核心实现基于消息队列MQ实现主流选型为 RocketMQ阿里开源国内主流、RabbitMQ、Kafka核心优势服务解耦、流量削峰、异步提升吞吐量、故障隔离下游服务故障不影响上游核心流程5. 负载均衡解决的问题将请求均匀分发到多个服务实例提升系统吞吐量和可用性避免单个实例压力过大两大类型客户端负载均衡微服务主流负载均衡逻辑在服务消费者端执行消费者本地缓存服务实例列表根据负载均衡策略选择实例发起调用主流实现为Spring Cloud LoadBalancer服务端负载均衡集中式负载均衡请求先经过负载均衡节点再转发到服务实例主流实现为 Nginx、F5核心负载策略轮询、权重轮询、随机、一致性哈希、最小连接数6. 服务容错熔断、降级、限流解决的核心问题分布式系统的雪崩效应—— 单个服务故障导致上游调用服务线程阻塞故障逐级向上扩散最终导致整个集群瘫痪。核心概念熔断当下游服务故障比例达到阈值比如 50% 请求超时熔断器直接打开后续请求不再调用故障服务直接返回降级结果避免故障扩散一段时间后熔断器进入半开状态尝试放行少量请求验证服务是否恢复降级高峰期或系统故障时主动关闭非核心功能比如商品详情页的推荐功能释放服务器资源保障核心功能下单、支付的可用限流限制请求的并发数 / QPS超过阈值的请求直接拒绝防止系统被突发流量打垮主流选型Sentinel国内首选阿里开源轻量级支持熔断、降级、限流、热点参数防护国内文档完善适配 Spring Cloud Alibaba其他选型Resilience4j、HystrixNetflix 开源已停更7. API 网关解决的问题微服务有多个服务实例对外暴露的地址分散无法统一管理认证授权、流量控制、路由规则客户端需要对接多个服务地址对接成本高。核心定位微服务集群的唯一入口所有外部请求先经过网关再转发到对应服务类似 “小区大门”。核心功能路由转发、统一认证授权、流量控制、熔断降级、日志监控、协议转换、跨域处理、IP 黑白名单主流选型Spring Cloud Gateway首选Spring Cloud 官方原生网关基于 WebFlux 非阻塞响应式编程性能高完美适配 Spring Cloud 生态其他选型APISIX、Kong、ZuulNetflix 开源已停更性能差8. 分布式事务解决的问题跨多个服务 / 多个数据库的事务一致性问题。单体架构中一个事务内的多个操作都在一个数据库中本地事务即可保证一致性微服务中下单扣库存、扣余额分属不同服务的不同数据库本地事务无法生效。核心解决方案 适用场景方案核心原理一致性性能适用场景AT 模式Seata两阶段提交自动生成反向回滚 SQL无侵入强一致性高绝大多数非高并发的核心交易场景首选方案TCC手动实现 Try-Confirm-Cancel 三个阶段代码侵入性强强一致性高高并发、短事务的核心交易场景SAGA长事务拆分多个本地事务失败时执行补偿事务最终一致性中长事务、流程复杂的业务场景事务消息基于 MQ 的半消息机制保证本地事务和消息发送的原子性最终一致性高异步化、可接受最终一致性的场景主流选型Seata阿里开源国内主流支持 AT/TCC/SAGA 等多种模式适配 Spring Cloud Alibaba学习成本低。新手避坑优先通过业务设计避免分布式事务而不是一上来就用分布式事务方案。9. 分布式链路追踪解决的问题一个业务请求可能跨多个服务出现超时、报错时无法快速定位是哪个服务出了问题无法排查全链路的性能瓶颈。核心原理为每个请求生成唯一的TraceID请求每经过一个服务生成对应的SpanID通过 TraceID 串联整个调用链路记录每个服务的调用耗时、状态、异常信息最终实现全链路可视化。主流选型SkyWalking国内首选Apache 顶级项目无侵入式埋点支持链路追踪、性能监控、告警功能全面国内社区活跃其他选型Zipkin、Jaeger、Pinpoint10. 配套基础设施日志中心解决服务实例多、日志分散的问题主流方案为 ELK 栈ElasticsearchLogstashKibana、EFK 栈监控告警体系实时监控服务的 CPU、内存、接口响应时间、错误率等指标故障提前预警主流方案为Prometheus Grafana行业标准容器编排大规模微服务集群的部署、调度、运维主流方案为KubernetesK8s四、主流微服务技术栈选型指南目前国内企业主流的微服务技术栈分为三大体系新手优先选择 Spring Cloud Alibaba避免走弯路。1. 首选体系Spring Cloud Alibaba新手入门首选国内企业主流优势组件全、国内文档丰富、社区活跃、长期维护、完美适配国内云环境学习资料多踩坑容易找到解决方案版本建议稳定版资料最多Spring Boot 2.7.x Spring Cloud 2021.0.x Spring Cloud Alibaba 2021.0.1.0核心组件对应关系微服务核心能力对应组件服务注册与发现Nacos配置中心Nacos服务远程调用OpenFeign / Dubbo负载均衡Spring Cloud LoadBalancer熔断降级限流SentinelAPI 网关Spring Cloud Gateway分布式事务Seata分布式链路追踪SkyWalking监控告警Prometheus Grafana日志中心ELK/EFK2. 原生 Spring CloudNetflix 体系不推荐新手入门现状Netflix 开源的核心组件Eureka、Ribbon、Hystrix、Zuul大多已停止维护国内企业使用占比持续下降仅适合了解微服务发展历史维护老旧项目3. 云原生体系Service Mesh服务网格进阶学习核心思想将业务逻辑和网络通信解耦微服务的流量管控、熔断、限流、链路追踪等能力全部下沉到基础设施层通过 Sidecar 代理实现业务代码无侵入主流选型Istio Envoy适用场景大规模微服务集群、多语言技术栈、云原生环境学习建议新手不建议直接上手先把 Spring Cloud 体系搞懂理解微服务的核心问题和解决方案后再学习 Service Mesh五、循序渐进的学习路径 实操计划新手严格按照以下阶段学习避免盲目看视频、堆技术栈做到学一个、会一个、用一个。阶段一筑基阶段2-3 周必须打牢禁止跳步核心目标熟练掌握 Spring Boot搞定所有前置知识学习内容Java 8 新特性Lambda、Stream、Optional、线程池Maven 多模块项目搭建、依赖管理Spring Boot 核心自动配置原理、Starter 开发、AOP、全局异常处理、参数校验、整合 MyBatis-Plus、Redis、Swagger/Knife4jDocker 核心操作、Dockerfile 编写、镜像打包与推送实操任务用 Spring Boot 开发一个单体 CRUD 项目如商品管理系统包含完整的接口规范、异常处理、数据库操作、缓存功能为项目编写 Dockerfile打成镜像并在本地运行阶段二核心组件入门阶段3-4 周逐个攻破核心目标掌握每个核心组件的作用、原理、基础使用理解每个组件解决的问题学习顺序按依赖关系不要乱序微服务基础理论康威定律、CAP/BASE 理论、服务拆分原则Nacos搭建 Nacos 服务实现 2 个服务的注册发现配置集中管理与动态刷新OpenFeign LoadBalancer实现 2 个服务的远程调用验证负载均衡效果Sentinel实现熔断、降级、限流模拟服务故障验证容错效果Spring Cloud Gateway实现路由转发、断言、过滤器、集成 Sentinel 限流Seata搭建 Seata 服务实现 AT 模式的分布式事务模拟下单扣库存的跨服务事务场景SkyWalking搭建 SkyWalking 服务实现微服务全链路追踪查看调用链路与性能指标实操要求每个组件学完必须写对应的 Demo最终整合所有组件搭建一个包含 3-4 个服务的微服务 Demo跑通完整的调用链路阶段三项目实战阶段4-6 周知识体系化的核心核心目标从零到一搭建一个完整的、可落地的微服务项目把所有知识点串联起来形成完整的体系推荐实战项目电商微服务系统业务场景经典覆盖所有微服务核心能力项目拆分示例公共模块common通用工具类、全局异常、通用实体、枚举用户服务user-service用户注册登录、信息管理、权限认证商品服务goods-service商品管理、库存管理订单服务order-service订单创建、订单状态管理支付服务pay-service支付对接、支付状态同步项目必须包含的核心能力基于 Nacos 的服务注册发现与配置管理基于 OpenFeign 的服务间远程调用基于 Gateway 的统一网关入口与认证授权基于 Sentinel 的熔断降级限流基于 Seata 的分布式事务下单扣库存基于 SkyWalking 的全链路追踪基于 Redis 的缓存与分布式锁基于 RocketMQ 的异步解耦支付成功异步通知实操要求规范的多模块 Maven 结构清晰的代码分层每个服务独立数据库禁止跨服务访问数据库编写完整的接口文档、单元测试为每个服务编写 Dockerfile实现容器化部署本地完整运行模拟真实业务场景完成全流程测试阶段四进阶 优化阶段持续学习核心目标解决微服务高阶问题提升系统的高可用、高并发、高性能学习内容DDD 领域驱动设计深入学习 DDD用 DDD 指导服务拆分与代码设计高可用架构设计集群部署、异地多活、故障演练、容灾备份高并发优化缓存优化、分布式锁、异步化、池化技术、数据库分库分表云原生进阶KubernetesK8s、微服务 K8s 编排、CICD 流水线Jenkins/GitLab CIService MeshIstio 核心原理与落地实践微服务安全OAuth2.0/OIDC 统一认证、数据加密、接口防刷、API 安全性能压测JMeter 压测、性能瓶颈定位与优化阶段五面试 落地经验沉淀核心目标应对面试掌握企业级落地最佳实践核心动作整理微服务常见面试题深入理解底层原理而不是只停留在使用层面学习大厂微服务落地最佳实践总结避坑经验持续优化自己的实战项目沉淀到 GitHub形成自己的作品集六、新手常见坑 避坑指南过度拆分新手最容易犯的错误把服务拆得太细导致分布式复杂度指数级上升运维成本爆炸。建议初期粗粒度拆分后续逐步迭代不要一上来就拆十几个服务。为了微服务而微服务小团队、小项目、流量小硬上微服务反而降低开发效率。建议先单体后微服务当单体遇到性能、迭代瓶颈时再逐步拆分。数据不自治多个服务共享一个数据库等于白拆微服务。服务之间通过数据库耦合后续无法独立扩展和迭代。建议每个服务独立数据库服务之间只能通过接口通信。忽略分布式事务跨服务调用不处理事务一致性导致数据错乱。建议优先通过业务设计避免分布式事务必须使用时选择合适的方案不要自己手写。没有容错机制服务调用不做熔断降级一个服务故障导致整个集群雪崩。建议所有跨服务调用必须配置容错规则。缺失监控与链路追踪服务出问题找不到原因排障全靠猜。建议微服务搭建初期就必须把监控、链路追踪、日志中心搭起来。服务依赖混乱服务之间循环依赖调用链路像蜘蛛网。建议梳理清晰的服务依赖拓扑禁止循环依赖核心服务不依赖非核心服务。七、优质学习资源推荐官方文档首选最权威Spring Cloud Alibaba 官方文档https://sca.aliyun.com/docs/2023/overview/what-is-sca/Nacos 官方文档https://nacos.io/zh-cn/docs/what-is-nacos.htmlSentinel 官方文档https://sentinelguard.io/zh-cn/docs/introduction.htmlSeata 官方文档https://seata.io/zh-cn/docs/overview/what-is-seata.htmlSkyWalking 官方文档https://skywalking.apache.org/zh/书籍推荐《微服务设计》马丁・福勒著作微服务领域圣经入门必看理解微服务的核心思想《Spring Cloud Alibaba 微服务原理与实战》国内实战类书籍贴合国内技术栈适合新手《DDD 领域驱动设计精粹》薄而精快速掌握 DDD 核心思想指导服务拆分《凤凰架构》周志明著作深入讲解分布式系统核心原理提升架构深度开源项目参考mallhttps://github.com/macrozheng/mall国内最火的 Spring Cloud 电商微服务项目文档完善适合参考学习RuoYi-Cloudhttps://gitee.com/y_project/RuoYi-Cloud成熟的微服务管理系统脚手架适合快速搭建项目最后给新手的忠告微服务不是银弹它解决了高可用、高扩展的问题同时也带来了分布式系统的巨大复杂度。学习微服务一定要先搞懂 “为什么要这么做”再去学 “怎么实现”不要上来就堆技术栈。微服务是实战性极强的技术光看视频和文档永远学不会必须自己从零到一搭建项目踩坑、解决问题才能真正掌握。
