服务治理

nginx 不再是"服务器"了，它是你家微服务的门卫 第 1 步：目标——搞懂 nginx 在微服务里到底干嘛 先说个某开发者的真实转变。以前写单体应用，nginx 的活就是：把静态资源甩给浏览器，把动态请求转发给 Tomcat。配置嘛，抄一份改改就能跑。 后来上了微服务，Spring Cloud Gateway 成了统一入口，nginx 的位置就尴尬了——它既不用管静态资源，也不直接碰业务，但它卡在所有流量的最前面。 浏览器 ↓ nginx ← 我们这篇的主角：流量大门 ↓ Spring Cloud Gateway ← 路由/鉴权/限流 ↓ 微服务 A 微服务 B 微服务 C nginx 在这条链路上的职责变成了： 职责 说明 TLS 终结 HTTPS 证书在 nginx 上解掉，网关不用管证书 流量分发 把请求转发给 gateway（可能不止一个实例） 连接管理 复用客户端连接，减少网关压力 基础防护 隐藏版本号、限流、挡扫描器 日志入口 记录所有进站请求（网关日志不覆盖 nginx 这一层） 📌 关键认知：nginx 挂 = 整个系统挂。它前面没有别的挡箭牌，所以 nginx 的配置质量直接决定入口的稳定性。这也是为什么值得花一篇的篇幅讲清楚。 这篇的目标很实在：让你（或让 AI 代你）改 nginx 配置时，知道哪些是命门、哪些是锦上添花，别把入口配成瓶颈。 第 2 步：前置条件——先弄懂 nginx 的"体力"从哪来 动手配之前，必须理解 nginx 的工作模型。它跟 Tomcat 那种"一连接一线程"完全不同： ...

又见编码问题：mvn test 报 MalformedInputException，IDE 却好好的 某开发者最近在项目中遇到一个奇怪的现象：mvn test 跑 Spring Boot 集成测试时，应用上下文启动失败，控制台抛出一串 MalformedInputException: Input length = 1。但同样的代码，在 IDE 里直接点"运行"按钮，启动得丝般顺滑。 这看起来像是 Nacos 配置中心的问题——因为错误信息里提到了 nacos:mall-auth-api-dev.yaml 配置文件找不到。但用 curl 请求 Nacos API，配置明明存在，内容也是合法的 YAML。 到底是哪里出了问题？ 问题复现 执行命令： mvn test -pl mall-auth 控制台输出类似： *************************** APPLICATION FAILED TO START *************************** Description: Config data resource 'NacosConfigDataResource{...}' via location 'nacos:mall-auth-api-dev.yaml' does not exist 但此刻如果打开浏览器访问 Nacos 控制台，或者用 curl 直接拉取： curl "http://localhost:8848/nacos/v1/cs/configs?dataId=..." 配置内容完整返回，HTTP 状态码 200。所以配置是存在的，但 Nacos 客户端在 Spring Boot 中读取失败了。 翻到堆栈深处，真正的异常是： Caused by: org.yaml.snakeyaml.error.YAMLException: java.nio.charset.MalformedInputException: Input length = 1 at com.alibaba.cloud.nacos.parser.NacosDataParserHandler.parseNacosData(...) at com.alibaba.cloud.nacos.configdata.NacosConfigDataLoader.pullConfig(...) Caused by: java.nio.charset.MalformedInputException: Input length = 1 at java.base/java.nio.charset.CoderResult.throwException(...) at java.base/sun.nio.cs.StreamDecoder.implRead(...) 这就清楚了——不是配置"不存在"，而是配置内容解析时遇到了字符编码问题。SnakeYAML 在读取 YAML 时，接收到了一个无法解码的字节序列。 ...

被一个社区镜像折磨的 24 小时 目标说明 这篇博客的目标很朴素：让读者用 10 分钟把 Sentinel Dashboard 跑起来，而不是花一整天跟一个社区镜像死磕。 某开发者在搭建微服务治理平台时，需要部署 Sentinel Dashboard 作为流量治理控制台。本以为 docker run 一把梭，结果被 bladex/sentinel-dashboard:1.8.6 这个社区镜像折腾了整整一天——端口改不掉、环境变量传了等于没传、配置文件挂载不生效、启动就崩溃、浏览器打开 401……踩了个遍。 本文将完整记录这 7 个坑的根因、排查过程和最终解决方案。所有配置已在 Debian 13 + Docker 26+ 下验证通过。 📌 前置知识：需要了解基本 Docker 操作和 Spring Boot 配置文件概念。 前置条件 项目 要求 操作系统 Linux（本文基于 Debian 13 WSL2） Docker 26+ Docker Compose v2+ 目标端口 9903（按需调整） 验证命令： docker --version # Docker version 26.x.x docker compose version # Docker Compose version v2.x.x 环境搭建 创建一个部署目录，后续所有文件都在此目录下操作： mkdir -p ~/dev-env/sentinel && cd ~/dev-env/sentinel 先简单拉个镜像试试水： ...

Nacos 配置管理：一套标准化方案如何搞定 9 个微服务 接手了一套 Spring Cloud Alibaba 微服务项目。读完代码后先看了一遍它的配置管理——毕竟 9 个服务各有各的数据库、Redis、Token 密钥，还不用同一套连接机制，这不配置爆炸谁配置爆炸。 检查结果不出所料：有的服务用 bootstrap.yml 连 Nacos，有的用 config.import ，还有的既没 bootstrap.yml 也没 config.import ，全靠本地 application.yml 硬撑着。更离谱的是，9 个服务在 Nacos 上重复配置了 9 遍 Redis、9 遍 JWT 密钥，改一次密码要改 9 个 dataId。 分享一套标准化方案，从 9 个服务的混乱配置中理出了头绪。 bootstrap.yml 还是 config.import？ Spring Cloud Alibaba 项目连接 Nacos 有两种做法。第一种是传统方案，在 bootstrap.yml 中配置 Nacos 参数： `` `yaml bootstrap.yml — 旧方案 spring: cloud: nacos: config: server-addr: ${NACOS_ADDR:localhost:8848} namespace: ${NACOS_NAMESPACE:mall} file-extension: yaml 需要额外引入 `spring-cloud-starter-bootstrap` 依赖才能生效。这是 Spring Cloud 2020 之前的标准做法。 第二种是新方案，直接在 `application.yml` 中通过 `spring.config.import` 指定： `` `yaml # application.yml — 新方案 spring: config: import: nacos:${spring.application.name}.yaml Spring Cloud 2023.x 已默认关闭 bootstrap 上下文，官方推荐使用 config.import 。 ...

拆分微服务，先搞懂这七条法则 BFF 不是新概念，但翻车率极高 当你决定从单体拆微服务，问得最多的问题往往是：“前端到底该调哪个服务？” 见过太多次这种场景——前端对着十几个 API 接口陷入选择困难症：一个商品详情页要调 5 个服务才能拼完整，首页要调 8 个。于是前端自己写了个"聚合层"，但没有服务端治理能力，比单体时代还乱。 BFF（Backend For Frontend，为前端服务的后端） 就是来解决这个的。它不是简单在前面加个代理，而是有明确的拆分法则。 BFF 拆分三法则 按客户端维度切分 不同端消费场景天然不同： 移动端 BFF：接口瘦、响应快、流量敏感，需要数据压缩和裁剪 Web 端 BFF：数据全、可交互多，可能需要 SSE 之类推送能力 小程序/第三方 BFF：安全校验严密，接口格式受平台约束 某团队早期把移动和 Web 共用一个 BFF，结果移动端要的"轻量接口"和 Web 端要的"完整数据"打架，BFF 越写越臃肿，成了一个"新型大单体"。 核心法则：一个端一个 BFF 实例。 代码可以复用，但部署实例要独立，避免互相影响。 BFF 只做编排，不做业务 BFF 层最容易踩的坑是"顺手把业务逻辑也写了"。 它的职责边界非常清晰： 该做的：接口聚合、数据裁剪、字段格式化、请求路由、Token 校验 不该做的：优惠计算、库存扣减、订单校验、风控规则 BFF 是服务员，不是厨师。厨师在后厨（业务服务），服务员只负责拼盘上菜。 关注点分离——BFF 不做跨服务事务 BFF 同时调了订单服务和库存服务，发现库存扣减成功但订单创建失败——这时候 BFF 能回滚吗？不能。BFF 层没有分布式事务能力。 碰到需要事务强一致的场景，BFF 必须把这个"烫手山芋"扔给下游的编排服务（比如用 Saga 模式），别自己在 BFF 层 try-catch 补偿。 flowchart LR subgraph Client["📱 客户端层"] WEB(["Web App"]) APP(["移动 App"]) MINI(["小程序"]) end subgraph BFF["🔀 BFF 层"] WB[Web BFF\n内容聚合+认证] MB[Mobile BFF\n数据裁剪+压缩] XB[三方 BFF\n签名校验+格式转换] end subgraph Biz["⚙️ 业务服务层"] BS[商品服务] CS[购物车服务] OS[订单服务] US[用户服务] PS[支付服务] end subgraph Store["💾 数据层"] DB[(MySQL)] CACHE[(Redis)] ES[(Elasticsearch)] end WEB -->|HTTP| WB APP -->|HTTP| MB MINI -->|HTTP| XB WB -->|RPC| BS & CS & OS & US & PS MB -->|RPC| BS & CS & US XB -->|RPC| OS & PS BS & CS & OS & US & PS --> Store classDef startEnd fill:#701a4c,stroke:#e11d48,stroke-width:2.5px,color:#fce7f3,font-weight:bold; classDef process fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#e5e7eb; classDef data fill:#052e16,stroke:#16a34a,stroke-width:2px,color:#bbf7d0,font-weight:bold; classDef bff fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#bfdbfe,font-weight:bold; class WEB,APP,MINI startEnd; class WB,MB,XB bff; class BS,CS,OS,US,PS process; class DB,CACHE,ES data; 业务能力拆分——最直觉的切法 最简单的拆分方式：按业务功能划分。电商天然就能分成商品、订单、用户、支付、库存这些模块。每个服务对应一个业务域，内部有独立数据库，对外暴露接口。 ...

接口调失败了？重试之前先看看这四种姿势 为什么需要重试 分布式系统里，接口调用失败是常态，不是意外。网络抖动、服务重启、连接池满、Full GC 停摆——这些故障每天都在发生。 但并不是每次失败都值得重试。有些失败重试一下就好了（瞬时故障），有些失败重试一万次也没用（业务异常、参数错误）。区分这两类失败，是设计重试策略的前提： flowchart TD Call(["发起 RPC 调用"]) --> Result{调用结果} Result -->|"成功"| OK([结束]) Result -->|"失败"| Type{失败类型} Type -->|"网络超时\n连接 refused\n503 Service Unavailable"| Retryable["可重试\n瞬时故障"] Type -->|"400 Bad Request\n403 Forbidden\n业务状态异常"| NoRetry(["直接抛出\n重试无意义"]) Retryable --> Idempotent{接口是否幂等} Idempotent -->|"是"| DoRetry(["执行重试"]) Idempotent -->|"否"| Warn["警告\n需人工介入"] Warn --> Check([手动排查]) classDef startEnd fill:#701a4c,stroke:#e11d48,stroke-width:2.5px,color:#fce7f3,font-weight:bold; classDef condition fill:#2a1147,stroke:#a855f7,stroke-width:2px,color:#ede9fe,font-weight:bold; classDef process fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#e5e7eb; classDef reject fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fecaca,font-weight:bold; class Call,OK,NoRetry,DoRetry,Check startEnd; class Result,Type,Idempotent condition; class Warn reject; ⚠️ 新手提示：重试只适用于瞬时故障（transient failure）。如果下游返回 400/403/ 业务校验失败，查日志修代码，别重试。 方案一：手动重试——最简单但也最危险 最直接的方式就是用循环自己搞： ...

在 Gateway 里手写四种限流算法 目标说明 网关是流量的咽喉，限流是网关最重要的能力之一。这篇文章的目标很明确： 理解四种主流限流算法的核心逻辑：固定窗口、滑动窗口、漏桶、令牌桶 每种算法都能写出来并跑通，不只是看概念 集成到 Spring Cloud Gateway 中，作为自定义 GatewayFilter 使用 了解生产级方案：Redis + Lua 分布式限流 读完这篇文章，读者应该能回答：“为什么 Sentinel 选滑动窗口、Gateway 选令牌桶？“以及"如果让你自己写一个限流过滤器，你怎么写？” 前置条件 开始之前，确保环境满足以下条件： 依赖 版本要求 用途 JDK 11+ 运行 Spring Boot 应用 Spring Boot 2.7.x 基础框架 Spring Cloud 2021.0.x Gateway 依赖 Spring Cloud Gateway 3.1.x 网关核心 Redis（可选） 6.0+ 分布式限流 JMeter（可选） 5.5+ 压测验证 验证命令： java -version # 应输出 11 或更高 mvn -version # 确认 Maven 可用 redis-cli ping # 如果做分布式限流，确认 Redis 连通 ⚠️ 新手提示：本文的代码可以在一个独立的 Spring Boot 项目中运行，不需要完整的微服务集群。只要一个 Gateway 项目 + 一个后端服务即可验证。 ...

负载均衡三剑客 本文是分布式算法科普系列第六篇。前面讲了服务怎么发现、怎么保证一致性、怎么限流、怎么处理事务——现在一个请求终于要发出去了。但目标服务部署了 5 个实例，请求该打到哪一个上面？这就是负载均衡要回答的问题。 一、故事：缓存集群增减机器时的雪崩 1997 年，MIT 的 David Karger 和他的同事们遇到了一个实际问题。当时的 Web 缓存系统（比如 Akamai 这样的 CDN 前身）由几十上百台服务器组成，每台存一部分网页缓存。浏览器请求一个页面时——先算哈希——根据哈希值决定去哪台缓存服务器取数据。 问题出在服务器数量变化的时候。假设有 10 台服务器——用 hash(key) % 10 决定数据落在哪台机器。当一台机器宕机——变成了 9 台——几乎所有 key 的 hash % 9 结果都和之前不一样了——几乎所有缓存同时失效，所有请求打向后端源站，源站瞬间被冲垮。 这就是所谓的“缓存雪崩”——不是因为流量突增，而是因为集群规模变化导致哈希取模结果大面积重映射。Karger 等人在 1997 年的论文《Consistent Hashing and Random Trees》中提出了一致性哈希——当节点增减时，只有少部分数据需要重新分配，而不是全部。 一致性哈希解决的只是负载均衡算法要处理的众多问题之一。在这之前，加权随机和最少活跃已经在各自的场景中发挥作用——它们共同构成了负载均衡算法的核心工具箱。 二、前置：负载均衡到底在均衡什么 在一个典型的微服务调用链中： Consumer → [从注册中心拿到 Provider 列表] → 选一个 Provider → 发请求 ↑ 负载均衡算法在这一步起作用 注册中心（比如 Nacos）返回了服务实例的列表——5 个 IP 加端口。Consumer 要从中挑一个发请求。怎么挑——就是负载均衡算法的事。 不同的挑法对应不同的目标： 目标 对应算法 后端实例配置不同（有的机器性能好、有的差） 加权随机 后端实例忙闲不均（有些正在处理慢请求） 最少活跃 需要同一类请求总是打到同一台机器 一致性哈希 三种算法不是"谁更好"的关系——它们是三种不同的策略，各解决各的问题。 ...

流控算法三件套 本文是分布式算法科普系列第三篇。前两篇讲了服务怎么找到彼此（Distro）和怎么对数据达成一致（Raft）。这一篇换一个角度——找到服务了、数据也一致了，但如果请求来得太快太多，怎么保护系统不被冲垮？ 一、故事：互联网的拥塞崩溃 1986 年 10 月，互联网历史上发生了一次著名的事故——拥塞崩溃（Congestion Collapse）。劳伦斯伯克利实验室和加州大学伯克利分校之间的网络链路，带宽从通常的 32Kbps 骤降到 40bps——没错，不是 40K，是 40，下降了近三个数量级。 原因并不复杂：发送方在拼命重传丢失的数据包，但这些重传又进一步加剧了网络拥堵，导致更多丢包——恶性循环。链路上跑的全是重传包，几乎没有有效数据到达对端。 这次事件促使 Van Jacobson 在 1988 年发表了《Congestion Avoidance and Control》，提出了 TCP 拥塞控制的几个核心算法——慢启动、拥塞避免、快速重传。而 TCP 里的滑动窗口，正是用来控制"同一时刻最多有多少数据在传输途中"的机制。 同一个问题，换个场景照样发生。微服务架构普及后，服务 A 调用服务 B——如果服务 B 处理能力有限，服务 A 还一个劲地往里灌请求，服务 B 的响应会越来越慢，进而拖慢服务 A 的线程池，再拖慢服务 A 的调用方……一路传导，整个系统雪崩。 这就是流控要解决的核心问题：系统处理能力有限，请求来得太猛太快，必须有一个机制把多余的请求挡在外面——宁可拒绝一部分，也不能让整个系统被冲垮。 二、前置：固定窗口的"边界作弊" 在讲滑动窗口之前，先看一眼最简单的限流方案——固定窗口。理解它的缺陷，才能理解为什么需要滑动窗口。 固定窗口的思路很简单：把时间切成一段一段（比如每秒一段），每段内计数，超过阈值就拒绝。 窗口: [0秒 ~ 1秒) → 计数器 = 0 → 请求来了 → 计数器+1 → 计数器≤阈值 → 放行 窗口: [1秒 ~ 2秒) → 计数器归零 → 重新计数 问题出在窗口边界。假设阈值是每秒 100 个请求。有人在 0.95 秒到 1.05 秒之间发了 150 个请求——0.95 到 1 秒 80 个，1 到 1.05 秒 70 个。两个窗口各自的计数器都没超阈值（80 < 100，70 < 100），但实际上在 0.95 ~ 1.05 这 0.1 秒内系统实际承受了 150 个请求。 ...

Distro 协议 本文是分布式算法科普系列第一篇。系列面向完全没接触过分布式的业务开发者，用历史故事开场、比喻辅助理解、不涉及数学证明和代码实现。 一、故事：微服务来了，电话号码本怎么办 早年的单体应用，一个进程内部互相调用，不需要"发现"对方——函数调用就行。微服务架构来了，服务实例的数量和位置开始动态变化：扩容加几台、某台机器宕机撤掉、滚动发布换一批新实例。服务 A 要调用服务 B，必须知道此时此刻服务 B 在哪些 IP 和端口上。 最朴素的想法是——搞一个电话号码本。所有服务启动后把自己的地址登记上去，调用方去电话本里查。这个"电话本"就是注册中心。 但问题来了：电话本自己怎么保证不挂？如果只有一个电话本，挂了所有服务都变瞎子。那就多搞几个电话本，每个存一份完整的地址副本。新问题又来了——服务 A 的地址变了，怎么保证所有电话本上写的都一样？ 用个比方来理解这个场景： 一个小区有三家传达室，每家都有一本住户登记簿。住户搬家了会通知最近的那家传达室更新记录。有人来访时，随便问哪家传达室都能查到住户的门牌号——哪怕其中一家的登记簿还没来得及更新。 这就是 Distro 协议要解决的问题：在一个多节点集群中，如何让写入请求快速得到响应（高可用），同时保证各节点上的数据最终会变得一致（最终一致）。 二、前置：为什么不能又一致又可用 在深入 Distro 之前，需要先理解一个约束——CAP 定理。 📌 前置知识：CAP 定理说的是，在一个分布式系统中，当网络发生分区（Partition，即节点之间网络不通）时，你只能在一致性（Consistency）和可用性（Availability）之间二选一。网络没出问题时，一致性和可用性可以同时满足。 用电话本的比方说：一号传达室和二号传达室之间电话线断了（网络分区）。此时有人去一号传达室改了一个住户的门牌号（写操作）。一号传达室有两个选择： 选一致性（C）：拒绝这个修改请求，因为无法同步给二号传达室。结果：修改失败，但所有传达室的数据保持一致。 选可用性（A）：先接受修改，等电话线恢复后再同步给二号传达室。结果：修改成功，但二号传达室暂时还是旧数据。 注册中心这个场景天然更适合选 AP（可用 + 分区容忍）。原因很现实：返回一个略微过期的实例地址（可能已经下线了），调用方最多重试一次换另一个实例；但注册中心如果拒绝查询，整个调用链直接断了。两害相权取其轻。 Raft 协议选了 CP（后面一篇会讲），Distro 协议选了 AP。这就是它们在同一套 Nacos 系统里分工的原因——服务发现走 Distro（AP），配置中心走 Raft（CP）。 三、Distro 的核心设计 3.1 没有主节点 这是 Distro 和 Raft 最根本的区别。Raft 通过选举产生一个主节点（Leader），所有写操作必须经过主节点——主节点把日志复制给从节点，多数确认后提交。如果主节点挂了，必须重新选举，选举期间集群无法写入。 Distro 没有主节点。集群里每个节点都是平等的。写请求可以打到任意一个节点，该节点立刻返回成功，然后异步把变更同步给其他节点。 用一个比方来理解这个差异： Raft 像公司报销流程——所有报销单必须部门经理（Leader）签字才能入账。经理出差了？等着，等他回来或者换新经理。 Distro 像小组共享文档——任何人改了一段，改了就先保存，其他同事打开文档时看到最新版就行。就算有人离线没同步到，等他上线后会自动补上。 去中心化带来的直接好处：没有主节点，就不存在主节点宕机后的"选举窗口"。任何时候任何节点都能处理读写。 3.2 数据分片与一致性哈希 Distro 虽然每个节点都能独立处理写请求，但为了减少冲突和降低同步开销，它对数据做了分片——每个服务实例的注册信息只由一个"负责节点"来权威维护，其他节点虽然也存了这份数据，但只是副本。 分片机制用了一致性哈希。一致性哈希把存储空间组织成一个首尾相连的环（0 ~ 2^32-1）。每个节点在环上占据一个位置，每条数据根据 Key 的哈希值落在环上的某个点，顺时针方向遇到的第一个节点就是这条数据的负责节点。 ...