← 返回思维链目录
微服务架构思维链
看到服务调用失败、配置不一致、链路混乱,顺藤摸瓜找到根因
1. 为什么拆微服务(以及代价)
起点
单体应用越来越臃肿,改一处要整体发布
本质:
微服务拆分是为了
独立部署、独立扩展、职责清晰
。但拆了之后引入了网络调用、数据一致性、运维复杂度等新问题 ——
拆是权衡,不是免费午餐
。
🌊 顺藤摸瓜
① 为什么拆
单体 → 代码臃肿、改一处全量发布、扩展只能整体扩展 →
拆微服务
:独立部署(改 A 不影响 B)、独立扩展(订单服务扩 10 台,用户服务 2 台)、职责清晰(团队各管一块)
独立部署
独立扩展
团队解耦
② 代价
拆了引入新问题:①
网络调用不可靠
(超时/重试);②
数据一致性
(跨服务事务);③
运维复杂
(几十个服务);④
调用链长
(排查难);⑤
分布式事务
网络不可靠
数据一致性
运维复杂
③ 怎么拆
按业务领域拆
(DDD):订单服务、用户服务、商品服务 → 不要按技术拆(不要拆成"DAO 服务""Service 服务")→ 拆太细 = 分布式单体
按业务领域(DDD)
别按技术拆
别拆太细
关键认知:
微服务是
"用复杂度换灵活性"
。小项目别拆(单体够用),团队大了/业务复杂了才拆。拆之前要想清楚能不能承受代价。
2. 服务发现:怎么找到其他服务
起点
订单服务要调用户服务,但用户服务 IP 会变(扩容/重启)
本质:
服务实例 IP 动态变化,不能写死。
服务发现
就是让服务自动注册自己的地址,调用方动态查 —— 注册中心(Nacos/Eureka)就是个"电话簿"。
🌊 顺藤摸瓜
① 注册中心
服务启动 → 向
注册中心
(Nacos/Eureka/Consul)注册自己的 IP:Port → 停止时注销 →
心跳保活
(一段时间没心跳判定下线)
Nacos
Eureka
Consul
心跳保活
② 调用方
调用方先从注册中心查"用户服务在哪" → 拿到 IP 列表 →
负载均衡
选一个调(轮询/随机/权重)→ 客户端负载(Ribbon)或服务端负载(Nginx)
客户端负载 Ribbon
服务端负载 Nginx
轮询/权重
③ CAP 取舍
注册中心也要选 CAP:
Nacos/AP
(可用优先,短暂数据不一致但能注册);
Zookeeper/Consul CP
(一致优先,选举期间不能注册)→ 大多用 AP(注册可用更重要)
Nacos AP
Zookeeper CP
注册可用优先
3. API 网关:统一入口
起点
前端要调 10 个微服务,每个都要鉴权、限流、跨域?
本质:
网关是所有外部请求的
统一入口
。把鉴权、限流、日志、跨域等公共逻辑集中在一处,后端服务只管业务。
🌊 顺藤摸瓜
① 网关职责
①
路由转发
(根据路径转到对应服务);②
统一鉴权
(验 token);③
限流熔断
;④
日志监控
;⑤
跨域处理
;⑥
协议转换
(HTTP→gRPC)
路由转发
统一鉴权
限流熔断
跨域
② 选型
Spring Cloud Gateway
(Java 生态,filter 灵活)/
Nginx
(轻量,适合简单路由)/
Kong
(插件丰富)/
APISIX
(国产,性能好)
Gateway
Nginx
Kong
APISIX
③ 网关不能挂
网关是单一入口 → 挂了全挂 → 必须
集群部署 + 高可用
(多实例 + 负载均衡)→ 这是网关的最大风险
集群部署
高可用
单点风险
4. 链路追踪:请求在哪个服务卡了
起点
一个请求经过 5 个服务,慢了,不知道卡在哪
本质:
链路追踪给每个请求打一个唯一
traceId
,经过每个服务都带上,日志关联起来。这样能看清"请求在哪个服务花了多久"。
🌊 顺藤摸瓜
① 原理
请求进来生成
traceId
→ 调下游时带上 → 每个服务记录自己的耗时(span)→ 串成调用链 → APM(SkyWalking/Zipkin/Jaeger)展示
traceId
span
SkyWalking
Zipkin
② 跨线程丢失
异步线程/线程池里 traceId 会丢(线程切换)→ 需要用
TransmittableThreadLocal
(阿里 TTL)透传 → 或手动传 traceId
跨线程丢失
TTL 透传
5. 配置中心:配置怎么统一管
本质:
几十个服务的配置散在各处,改一个要重新打包部署。
配置中心
集中管理 + 动态推送(改了不用重启)。
🌊 顺藤摸瓜
① 为什么
配置散在本地 → 改要重新部署 →
配置中心
(Nacos/Apollo)集中存 → 动态推送(改了自动生效,不用重启)
Nacos
Apollo
动态推送
② 灰度发布
配置改了先给部分实例生效 → 验证没问题再全量 →
灰度配置
(按 IP/标签)
灰度配置
按标签
总结
问题
本质
方案
单体臃肿
职责不清、全量发布
按业务领域拆微服务(但有代价)
找不到服务
IP 动态变化
注册中心(电话簿)+ 心跳保活
公共逻辑重复
鉴权/限流每个服务都做
API 网关统一入口
不知道卡在哪
跨服务调用难排查
链路追踪 traceId 串联
配置散乱
改配置要重新部署
配置中心集中 + 动态推送
本质:
微服务架构 =
用基础设施复杂度换业务灵活性
。拆得越细,基础设施(注册/网关/追踪/配置)越重要。
拆之前先问:能不能承受这些代价?