MICROSERVICE · 服务治理 / 分布式
微服务速查
从服务拆分、注册配置、网关调用，到熔断限流降级、分布式事务与可观测演进，微服务治理的要点与套路一张表收齐。
8速查小节
57速查条目
6种事务方案
4种限流算法
📖 速查表
点击展开各小节
🧩 微服务基础
| 主题 | 要点 |
|---|---|
| 拆分原则 | 按业务能力 / DDD 限界上下文拆分，单一职责；对外接口稳定，内部实现自由演进 |
| 服务粒度把握 | 先粗后细，一个小团队能独立维护为宜；拆得过细只会放大分布式复杂度 经验 |
| 康威定律 | 系统结构映射组织的沟通结构；组织与团队先调整，微服务架构才能真正落地 |
| 单体演进信号 | 部署慢、模块边界模糊、团队并行冲突多、局部扩容需求强——出现这些信号再拆，不为了拆而拆 |
| 数据拆分 | 每个服务私有数据库；跨服务禁止直连对方库，一律走 API 或事件 红线 |
📇 注册与配置
| 维度 | Nacos | Eureka |
|---|---|---|
| 一致性模型 | AP / CP 可切换（临时实例 AP，持久实例 Raft） | AP，对等复制，最终一致 |
| 健康检查 | 客户端心跳 + 服务端主动探测 | 客户端心跳续约 |
| 自我保护 | 按保护阈值触发，防止网络抖动误删实例 | 网络分区时保留实例不剔除 |
| 使用建议 | 注册 + 配置一体，国内主流 主流 | 逐步被 Nacos / Consul 取代 |
| 要点 | 说明 |
|---|---|
| 心跳与剔除 | 心跳超时标记不健康，超过阈值剔除；客户端拉取列表有缓存，服务下线存在感知延迟 |
| 配置动态刷新 | @RefreshScope 或长轮询推送变更，改配置不重启 核心能力 |
| 灰度发布 | 配置按命名空间 / 环境 / 集群隔离，新配置先发灰度实例观察再全量 |
| 配置安全 | 敏感配置加密存储（jasypt / KMS），读写权限分级，禁止明文入库 |
| 版本回滚 | 配置变更留历史记录、可一键回滚；改前先看 diff 再发布 推荐 |
🔗 调用与网关
| OpenFeign 配置 | 要点 |
|---|---|
| 超时配置 | connectTimeout / readTimeout 分开设；客户端级配置覆盖全局，务必显式设置 必配 |
| 重试 | 默认 NEVER_RETRY；开启重试必须以接口幂等为前提，非幂等操作禁重试 |
| 日志级别 | BASIC 日常生产使用，排障时临时开 FULL 打印请求响应 |
| 上下文透传 | RequestInterceptor 携带 traceId / Token；异步线程池场景注意上下文丢失 |
| Gateway 概念 | 说明 |
|---|---|
| Route 路由 | 四要素：id + uri + 断言 + 过滤器，网关的基本转发单元 |
| Predicate 断言 | Path / Method / Header / Time 等条件决定请求是否命中路由 |
| Filter 过滤器 | 前置改请求（鉴权 / 限流 / 加头），后置改响应（改写 / 埋点） |
| GlobalFilter | 全局过滤器统一处理鉴权、灰度路由、traceId 注入 |
| 主题 | 要点 |
|---|---|
| 接口幂等手段 | 唯一索引 / 防重 Token / 状态机 / 分布式锁 + 去重表，按场景组合使用 |
| 重试风暴防护 | 指数退避 + 随机抖动 + 重试预算；级联重试会放大流量，必须设上限 雪崩推手 |
| 超时对齐 | 网关 > Feign > 下游逐层递减；上游已超时返回，下游不应继续空跑占资源 |
🛡️ 熔断限流降级
先隔离（舱壁）、再快速失败（超时与熔断）、最后兜底（降级）——三件事凑齐，雪崩才传不进来。
| 概念 | 说明 | 要点 |
|---|---|---|
| 雪崩效应 | 下游变慢导致上游线程堆积，层层传导全链路崩溃 | 超时 + 熔断 + 隔离三件套阻断传导 |
| Sentinel 资源 | 被保护的代码块 / 接口，@SentinelResource 或埋点定义 | 资源命名全局规范统一 |
| Sentinel 规则 | 流控 / 熔断 / 热点参数 / 系统自适应四类规则 | 规则推 Nacos 持久化，避免控制台内存态丢失 |
| 槽位链路 | NodeSelector → ClusterBuilder → Statistic → Flow / Degrade 依次过槽 | 基于滑动窗口统计 QPS 与 RT |
| 降级 Fallback | 返回兜底数据 / 默认值 / 旧逻辑，保核心可用 | 兜底逻辑不能再依赖故障中的下游 注意 |
| 舱壁模式 | 按依赖隔离线程池 / 信号量，一池故障不波及其他调用 | 权衡隔离粒度与线程资源开销 |
| 限流算法 | 思路 | 优缺点 |
|---|---|---|
| 固定窗口计数 | 单位时间计数器，超限拒绝 | 实现最简单；窗口边界处可突刺两倍流量 |
| 滑动窗口 | 细分小格滚动统计求和 | 平滑精确，内存略高；Sentinel 采用 主流 |
| 漏桶 | 请求入桶，恒定速率流出 | 整流能力强；无法应对突发流量 |
| 令牌桶 | 恒速发令牌可预存，取到才放行 | 允许一定突发；Guava RateLimiter 实现 |
💞 分布式事务
没有银弹：先问能否靠合理拆分与最终一致设计避开，再谈选型；能用消息解耦就别上强一致。
| 方案 | 思路 | 适用与要点 |
|---|---|---|
| 2PC / XA | 准备 + 提交两阶段，强一致 | 同步阻塞、协调者单点；数据库 XA 支持下的小规模场景 |
| TCC | Try 预留资源 / Confirm 确认 / Cancel 释放 | 业务侵入大、性能好，金融扣减常用；防空回滚 / 悬挂 / 幂等三件事 注意 |
| Saga | 长事务拆成本地事务链 + 正向 / 补偿服务 | 流程编排，无资源锁定，最终一致；补偿逻辑必须可靠 |
| 本地消息表 | 业务数据与消息同库同事务落库，定时任务扫描投递 | 实现简单可靠，最终一致的经典做法 推荐 |
| 事务消息 | RocketMQ 半消息 + 回查，先落业务再确认投递 | 吞吐好、与业务解耦；依赖 MQ 的事务消息能力 |
| Seata AT | 一阶段代理数据源记 undo log，二阶段异步删除或回滚 | 侵入最小，默认最终一致；注意全局锁与隔离级别表现 |
🔍 可观测与演进
| 主题 | 要点 |
|---|---|
| 链路追踪 | traceId 全链路贯通（HTTP / RPC / MQ 均透传），span 定位各环节耗时与瓶颈 |
| SkyWalking vs Zipkin | SkyWalking：Agent 无侵入 + 拓扑 + 告警，国内主流；Zipkin：轻量，社区生态经典 二选一 |
| 指标与告警 | Micrometer + Prometheus + Grafana；盯住 QPS / RT / 错误率 / 饱和度四类黄金指标 |
| 日志聚合 | ELK / EFK 集中检索与分析；Loki 按标签索引更轻量，配合 Grafana 面板 |
| 服务网格 Istio | Sidecar 接管流量治理，业务无感升级；架构复杂度高，小规模团队勿轻易引入 慎重 |
| 常见坑清单 | 超时缺失、重试无上限、分布式事务滥用、配置漂移、单点强依赖、无灰度直接全量发布 |
🌐 网关统一鉴权链路
微服务鉴权最容易走歪：每个服务各写一遍 token 校验。正确姿势是网关一处验签、全链路信任，下游保持无状态——五个环节串起来看。
| 环节 | 做法 | 要点 |
|---|---|---|
| 1. 登录发 token | 认证服务校验账密 / 验证码，签发 JWT：access 短效（15min）+ refresh 长效（7d） | payload 只放 userId、租户、角色等标识，敏感信息不入 token 安全 |
| 2. 网关全局过滤器验签 | GlobalFilter 统一校验签名、有效期、权限范围，不合法直接 401 拒绝 | 密钥 / 公钥配 Nacos 动态刷新；登录、白名单路径显式放行 |
| 3. 透传用户头 | 验签通过后解析出用户身份，写入 X-User-Id、X-Tenant-Id 等内部头转发下游 | 转发前必须剥离外部传入的同名头，防止伪造身份 易错 |
| 4. 下游无状态 | 下游服务不再解析 token、不存 session，只信任内网头信息，专注业务逻辑 | 前提是网络隔离：内部头只能来自网关入口，外部流量无法直连服务 |
| 5. 注销黑名单 | 注销 / 封禁把 token 或 jti 写入 Redis 黑名单（TTL = token 剩余有效期），网关验签时顺带校验 | JWT 无状态但「踢人」需要状态；黑名单是短效 token 与即时失效的折中 |
📦 拆分实战五问
原则都懂，落地就懵？把「要不要拆」的纠结换成五个可执行的问题，逐个回答就有了行动清单——与上面「微服务基础」的原则互为表里。
| 问题 | 实战答案 | 易错点 |
|---|---|---|
| 什么时候拆？ | 发布排队久、一次改动全量回归、团队并行频繁冲突——用组织与部署痛点衡量，而非技术尝鲜 | 没到痛点就拆，只会把单体内的函数调用升级成分布式故障 反模式 |
| 先拆什么？ | 边界最清晰、变更最频繁的业务域（如订单、库存）：接口少、依赖明确、团队熟悉 | 先拆共享用户库等公共模块，拆完人人依赖它，改动风险不降反升 |
| 数据怎么办？ | 每服务独立库；跨服务查询改走 API 聚合，或事件同步到本服务冗余表（如订单冗余商品快照） | 「库分了、表还互连」的伪拆分：跨库 JOIN 与分布式事务会把两边焊死 |
| 如何灰度？ | 网关按流量比例 / 用户白名单把请求路由到新服务，观察错误率与耗时达标后再放量 | 灰度要带数据双写方案；只切流量不迁数据，回切即丢数据 |
| 如何回滚？ | 保留单体通路：同一接口单体与新服务双实现并存，网关一键切回；至少保留一个版本周期 | 拆完立刻下线单体代码，出问题只能硬修新服务，失去退路 保命 |