微服务入门

微服务不是某个框架，而是一种架构风格。这篇脱离具体项目，讲清楚三件事：微服务是什么、拆分后带来哪些问题、每个问题用什么技术解决。

一、从单体到微服务

1. 单体架构

所有功能（用户、订单、商品、支付...）打包进一个应用、一个进程：

┌────────────────────────────┐
│  用户模块  订单模块  支付模块  │
│        一个 jar 包           │
│      一个进程 一套数据库       │
└────────────────────────────┘

• 优点：开发简单、部署一个包就行、没有网络调用开销，小项目最合适
• 缺点（业务大了之后暴露）：
  • 任何小改动都要整个应用重新发布，牵一发动全身
  • 一个模块出故障（内存泄漏、OOM），整个应用全挂
  • 只想给订单模块扩容做不到，只能整个应用复制多份，资源浪费
  • 团队多了都在一个代码库里改，互相冲突

2. 微服务架构

按业务边界把应用拆成一组小服务，每个服务：

• 独立开发、独立部署、独立进程
• 独立数据库（服务间不直接查对方的库，只能通过接口调）
• 可独立选择技术栈、独立扩容

┌────────┐   ┌────────┐   ┌────────┐
│ 用户服务 │←→ │ 订单服务 │←→ │ 支付服务 │
│ 库: user │   │ 库:order│   │ 库: pay │
└────────┘   └────────┘   └────────┘
     ↑ 每个服务独立部署，服务间通过 HTTP/RPC 调用

「微」指的是服务的粒度小、职责单一——一个服务只干一件事（比如只管订单）。

二、优缺点对比

	单体	微服务
开发/调试	简单，本地就能跑全流程	复杂，要拉起一堆依赖服务
部署	一个包	N 个服务，需要容器化+自动化
故障影响	一挂全挂	可以隔离到单个服务
扩容	只能整体复制	按需扩容热点服务
技术栈	全局统一	每个服务可自选
分布式问题	无	有一堆（见下节）

⚠️ 微服务是用「分布式的复杂度」换「扩展性和隔离性」。小项目老老实实用单体，不要为了微服务而微服务。

三、拆分带来的问题 → 对应技术（重点）

微服务学习路线其实就是一条「问题驱动」的路线，每个组件解决拆分后的一个痛点：

解决什么问题	组件	Java 常用技术
服务拆成 N 份，调用方怎么找到对方地址	注册中心	Nacos
几十个服务的配置怎么统一管理、动态修改	配置中心	Nacos
服务之间怎么发起调用	远程调用	OpenFeign + LoadBalancer
所有请求怎么统一入口、鉴权、路由到各服务	网关	Spring Cloud Gateway
下游服务卡死时怎么自保，别把故障扩散	熔断限流	Sentinel
服务间怎么异步解耦、削峰	消息队列	RabbitMQ / RocketMQ / Kafka
一次业务跨多个服务、多个库，怎么保证一致性	分布式事务	Seata
一个请求穿过多个服务，出错怎么快速定位	链路追踪	SkyWalking / Micrometer
N 个服务怎么独立部署、弹性伸缩	容器化	Docker + K8s

核心组件展开讲：

1. 注册中心 —— 解决「找得到人」

服务启动时把自己注册上去，调用方按服务名（而不是写死的 IP）拉取实例列表：

订单服务启动 → 注册到 Nacos："我叫 order-service，地址 192.168.1.10:8081"
用户服务调用 → 问 Nacos："order-service 在哪？" → 拿到地址发起调用
订单服务下线/宕机 → Nacos 心跳检测 → 自动剔除

2. 远程调用 —— 解决「怎么调」

用 OpenFeign 声明接口，像调本地方法一样调远程服务，底层把方法调用翻译成 HTTP 请求（所以它是构建在 HTTP 客户端之上的）。

3. 网关 —— 解决「统一入口」

所有外部请求先进网关，由它统一做鉴权、限流、路由转发，微服务本身不直接暴露给外界。

4. 熔断限流 —— 解决「故障不扩散」

下游服务响应超时时，调用方主动熔断（快速失败而不是干等），并给出兜底方案，防止一个服务卡死拖垮整条调用链上的所有服务——这是单体时代不存在的新问题。

四、Java 微服务技术选型

• Spring Cloud Netflix：最早的主流方案（Eureka、Ribbon、Hystrix、Zuul），已停止维护、陆续淘汰，老文章/老视频里常见，不要再学
• Spring Cloud Alibaba：现在国内事实标准，核心是四件套——Nacos + OpenFeign + Gateway + Sentinel
• Dubbo：阿里开源的 RPC 框架，性能比 HTTP 调用好，常和 Spring Cloud Alibaba 混用（Dubbo 负责服务间调用）

五、什么时候该拆微服务

满足的条件越多，越值得拆：

1. 单个应用代码量大到没人能完整理解
2. 不同模块的流量差异巨大（如商品页 QPS 10 万，后台管理 QPS 10）
3. 多个团队协作冲突频繁
4. 对可用性隔离有硬需求（核心支付链路不能被边缘功能拖挂）

一条经验：先单体 + 模块化（按包分好业务边界），等痛了再拆。边界分清楚了，单体拆微服务只是把包挪出去。

六、学习路线建议

1. 先把单体项目写扎实（HTTP、MySQL、Redis、消息队列这些在哪都要用）
2. 手写一个 Nacos + OpenFeign + Gateway + Sentinel 的最小 demo（两个服务互调，走网关），微服务就算入门
3. 再补分布式场景：分布式事务（Seata）、链路追踪、Docker/K8s 部署
4. 进阶：服务拆分粒度、分布式一致性理论（CAP/Paxos/Raft）

学习顺序上，跟着「问题驱动」走最顺：注册中心 → 远程调用 → 网关 → 熔断，正好就是四大件的顺序。