文章

反射凭什么认识你的类 某开发者写过这样一段代码，当时觉得平平无奇： Method method = obj.getClass().getDeclaredMethod("secretLogic", String.class); method.setAccessible(true); Object result = method.invoke(obj, "hacked!"); 运行完才反应过来——凭什么？一个 Class 对象拿在手里，连 private 方法都能翻出来调用，连参数签名都一清二楚。JVM 到底在背后存了什么东西，让反射可以"看见"一个类的全部内脏？ 答案就在 HotSpot 的 Klass 模型 里。 📌 前置知识：本文假设读者知道 .class 文件是 javac 编译产物、JVM 基本内存分区（堆、栈、方法区）的常识。如果不清楚方法区和 Metaspace 的关系，后文有图。 全景先览：JVM 中的类在哪 在深入 Klass 之前，先看一张全局地图——一个类从 .class 文件到进入 JVM 运行时，到底经过了哪些区域。 这张图先有一个印象就行——关键记住一点：一个类被加载后，JVM 在 Metaspace 里存了一份"类模板"（InstanceKlass），在 Heap 里放了一个轻量的"Java 镜像"（Class 对象）。 反射读的元信息来自前者，你代码里 getClass() 拿到的是后者。 类模板：HotSpot 眼中的"类" 你写的每一个 Java 类，在 HotSpot 内部都有一个对应的 C++ 对象来描述它——这就是 Klass 模型。 Klass 继承链 Klass ← 所有类的抽象基类 ├── InstanceKlass ← 普通 Java 类（你写的 99% 的类） │ ├── InstanceMirrorKlass ← Class 对象本身（镜子） │ └── InstanceRefKlass ← 引用类型（软/弱/虚引用） ├── ArrayKlass ← 数组类 │ ├── TypeArrayKlass ← 基本类型数组（int[]） │ └── ObjArrayKlass ← 对象数组（String[]） ⚠️ 新手提示：Klass 不是 Class。Klass 是 C++ 层面的数据结构，存在 Metaspace； java.lang.Class 是 Java 层面的对象，存在 Heap。日常说"类模板"通常指 InstanceKlass。 ...

补偿：别等炸了才想兜底 某一天凌晨，运维群里弹出一条告警：订单服务返回码全是 500，错误日志里赫然写着 库存扣减失败，事务已提交。排查一圈发现——库存服务超时了，但订单服务的本地事务已经提交，用户钱扣了，货没发出去。 这不是什么玄幻剧情。只要你的系统一次操作涉及两个以上的外部依赖，它就一定会发生。 问题的根儿不在于某个服务挂了，而在于挂了之后没人善后。这就是补偿机制要解决的事。 📌 前置知识：本文假设读者已经知道数据库事务 ACID 的基本概念、分布式系统中"网络不可靠"的前提。如果对分布式事务的 2PC / TCC / Saga 还没概念，建议先翻一下本站的《分布式事务基础》和《TCC + Saga》两篇。 什么是补偿机制 先给个直接的定义： 补偿（Compensation） 是一系列操作，用于撤销一个已经部分执行或完全执行的业务流程，使系统回到业务上可接受的一致状态。 注意两个关键词： 撤销——不是 “取消”，是"对已经产生的副作用进行逆操作"。扣掉的库存加回去，冻结的额度解冻，发的优惠券标记作废。 业务上可接受——补偿之后的状态不一定等于执行之前的状态。比如退款流水里多了一条退款记录，这不是脏数据，这是业务可审计的中间态，本来就是设计的一部分。 补偿 ≠ 回滚（Rollback）。回滚是数据库层的物理操作，依赖 undo log，对业务透明；补偿是业务层的逻辑操作，需要开发者显式编写逆操作代码。 > ⚠️ 新手提示：把补偿理解成 Ctrl+Z 不准确。Ctrl+Z 是"回到上一步"，补偿是"把已经造成的后果消弭掉"——相当于打翻了水杯，Ctrl+Z 是水自动回到杯子里（物理回滚），补偿是拿抹布擦干净桌子然后重新倒一杯（业务补救）。 补偿思维从本地就开始了 很多人觉得补偿是"分布式事务"才碰的东西，其实本地代码里到处都是补偿的影子，只是你没把它当成一个专门的概念。 场景一：文件操作的"撤销三部曲" public void processFile(String srcPath, String destPath) { File backupFile = null; File tempFile = null; try { // 步骤1：创建备份 backupFile = new File(srcPath + ".bak"); Files.copy(Path.of(srcPath), backupFile.toPath(), StandardCopyOption.REPLACE_EXISTING); // 步骤2：处理并写入临时文件 tempFile = new File(destPath + ".tmp"); try (var reader = new BufferedReader(new FileReader(srcPath)); var writer = new BufferedWriter(new FileWriter(tempFile))) { String line; while ((line = reader.readLine()) != null) { writer.write(transform(line)); writer.newLine(); } } // 步骤3：原子替换目标文件 Files.move(tempFile.toPath(), Path.of(destPath), StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE); } catch (Exception e) { // 补偿逻辑：清掉所有中间产物 if (tempFile != null && tempFile.exists()) { tempFile.delete(); // 撤销步骤2 } if (backupFile != null && backupFile.exists()) { try { Files.move(backupFile.toPath(), Path.of(srcPath), StandardCopyOption.REPLACE_EXISTING); // 撤销步骤1 } catch (IOException ex) { log.error("连备份恢复都失败了，手动处理吧...", ex); } } throw new ProcessingException("文件处理失败，已尽力回滚", e); } } 这段代码没什么高深的，但仔细看它的结构——每执行一步，catch 里就有对应的逆操作。这就是补偿机制的最朴素形态： ...

拆分微服务，先搞懂这七条法则 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/ 业务校验失败，查日志修代码，别重试。 方案一：手动重试——最简单但也最危险 最直接的方式就是用循环自己搞： ...

一笔钱在微服务里到底怎么走的 为什么支付是微服务里最难啃的骨头 做业务开发，碰到的最常见代码可能就是 CRUD。增删改查写熟了，觉得微服务也不过如此——直到某天被分配了支付模块。 支付和普通业务有本质区别：普通业务操作的是"信息"，支付操作的是"钱"。写错一行代码，信息可以修，钱出去了就是真金白银的损失。更麻烦的是，支付不是自己一个服务就能搞定的事——要接微信、要接支付宝、可能还要接银联、接 Stripe。每家渠道的接口风格不同，回调机制不同，对账方式也不同。上游还有订单系统在等支付结果，下游有会计系统等着入账。 flowchart LR %% 半暗底色 + 高亮描边：完美适配博客深色/浅色双主题 %% classDef root fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#bfdbfe,font-weight:bold; classDef process fill:#1e1e24,stroke:#6b7280,stroke-width:2px,color:#e5e7eb; classDef highlight fill:#431407,stroke:#ea580c,stroke-width:2px,color:#fed7aa,font-weight:bold; classDef reject fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fecaca,font-weight:bold; RISK1["[钱出去了\n回不来]"] RISK2["[重复支付\n多扣款]"] RISK3["[回调丢失\n订单卡死]"] RISK4["[对账不平\n财务追杀]"] RISK5["[渠道故障\n全站瘫痪]"] CORE["支付系统\n核心矛盾:\n复杂 × 高风险 × 强一致性"] RISK1 --> CORE RISK2 --> CORE RISK3 --> CORE RISK4 --> CORE RISK5 --> CORE class RISK1,RISK2,RISK3,RISK4,RISK5 reject; class CORE highlight; 把这些复杂度拆开来看，一个支付系统本质上要解决五个问题： 怎么收——对接各种支付渠道，屏蔽渠道差异 怎么记——每笔钱的来龙去脉都要有据可查 怎么验——回调确认钱真的到了，不是"用户说付了就算付了" 怎么对——自己的账和渠道的账对得上 怎么退——钱能收就能退，但不能退多了，也不能重复退 下面逐个拆解。 支付系统的"五脏六腑"：模块全景图 在动手写代码之前，先搞清楚一笔钱在系统里要经过哪些模块。 flowchart TD %% 半暗底色 + 高亮描边：完美适配博客深色/浅色双主题 %% 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 root fill:#0f172a,stroke:#3b82f6,stroke-width:2.5px,color:#bfdbfe,font-weight:bold; classDef highlight fill:#431407,stroke:#ea580c,stroke-width:2px,color:#fed7aa,font-weight:bold; subgraph FRONT["接入层"] GATE["[支付网关\n路由/验签/限流/协议转换]"] end subgraph CORE_MOD["核心支付域"] ORDER["[支付订单服务\n订单创建/查询/状态流转]"] CHANNEL["[支付渠道服务\n渠道抽象/路由/适配器]"] CALLBACK["[回调处理服务\n异步通知/幂等/重试]"] REFUND["[退款服务\n退款申请/审核/执行]"] end subgraph BILLING["清算对账域"] RECON["[对账服务\nT+1对账/差异处理/长款短款]"] SETTLE["[结算服务\n分账/手续费/入账]"] end subgraph INFRA["基础设施"] MQ["[消息队列\n异步解耦/重试]"] IDEM["[幂等表\n防重支付/防重回调]"] LGR["[流水表\n不可变审计日志]"] end FRONT --> CORE_MOD CORE_MOD --> BILLING INFRA -.-> CORE_MOD INFRA -.-> BILLING class GATE highlight; class ORDER,CHANNEL,CALLBACK,REFUND process; class RECON,SETTLE data; class MQ,IDEM,LGR process; 每个模块解决一类问题： ...

在 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 项目 + 一个后端服务即可验证。 ...

Go 运行时 vs JVM 运行时 一个 JVM 调优经验丰富的开发者第一次部署 Go 服务，看到监控数据时的反应： 这进程怎么只占 4MB？ -Xmx 在哪设置？GC 日志怎么看？ 接着打开 top ，看到 Go 服务起了几千个 goroutine，内存和 CPU 都低得离谱。而旁边跑了类似流量的 Spring Boot 服务， -Xmx512m 、GC 日志一大堆。 这不是魔法，是 Go runtime 和 JVM 的设计哲学完全不同。本文把两个运行时的核心差异讲清楚。 📌 前置知识：本文假定读者了解 JVM 的基本运行时概念（堆/栈/GC/类加载/JIT）和 Go 的 goroutine 基础知识。Go 版本为 1.22，对比 JVM HotSpot 17/21。 进程内存：4MB vs 512MB 的真相 维度 Go JVM（HotSpot） 最小内存 ~2-4MB ~50-200MB（含堆 + 元空间） 内存控制 自动，GOGC 环境变量 -Xmx / -Xms + 大量 JVM 参数 启动时间 毫秒级（AOT 编译） 秒级（类加载 + 解释执行 + JIT 预热） 部署产物 单一静态二进制（~10-20MB） JAR（需要 JRE/JDK 运行时） 内存占用大头 goroutine 栈 + 堆 + GC 元数据 堆 + 类元数据 + JIT 代码缓存 + 线程栈 两张图看清两个运行时各自的内存里到底装了什么： ...

Go Web 开发：从 Gin 到微服务 一个 Spring Boot 程序员打开 Go 的 Web 项目，看到的是这样的代码： // 这是什么？Controller 在哪？@Autowired 在哪？ func main() { db, _ := sql.Open("mysql", "user:pass@/dbname") repo := NewUserRepo(db) svc := NewUserService(repo) handler := NewUserHandler(svc) r := gin.Default() r.GET("/users/:id", handler.GetUser) r.Run(":8080") } 没有 @Controller 、没有 @Service 、没有 @Autowired 、没有 application.yml 。依赖是一个个手动拼起来的，路由是函数式注册的，连配置文件都得自己选库来读。 习惯 Spring Boot 全家桶的开发者，第一次面对 Go 的 Web 生态，大概有两类困惑： 框架选型：Gin、Echo、Fiber、Iris、go-zero、Kratos……每个都说自己性能好，到底该用哪个？ 组织方式：没有注解驱动的 DI、没有 AOP、没有 Filter 接口——同样的需求在 Go 里怎么写？ 本文用 Spring Boot/Spring Cloud 的对应视角，把 Go Web 开发的技术栈讲清楚。 ...

Go 网络编程 Java 程序员写网络服务，技术栈大概是这样的： // Java —— Netty 写一个 HTTP 服务 EventLoopGroup bossGroup = new NioEventLoopGroup(1); EventLoopGroup workerGroup = new NioEventLoopGroup(); try { ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel ch) { ch.pipeline() .addLast(new HttpServerCodec()) .addLast(new HttpObjectAggregator(65536)) .addLast(new SimpleChannelInboundHandler<FullHttpRequest>() { @Override protected void channelRead0(ChannelHandlerContext ctx, FullHttpRequest req) { // 业务逻辑... } }); } }); b.bind(8080).sync().channel().closeFuture().sync(); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); } 配置 EventLoopGroup、Channel Pipeline、Codec、Handler……对于一个简单的 HTTP 服务，一半代码在处理 Netty 的样板。 ...

Go 并发编程 写了 5 年 Java 并发，你手上的工具大概是这样的： // Java —— 线程池 + Future + BlockingQueue var executor = Executors.newFixedThreadPool(10); var future = executor.submit(() -> { return remoteService.query(); }); try { var result = future.get(5, TimeUnit.SECONDS); } catch (TimeoutException e) { future.cancel(true); } 现在看 Go 的等价写法： // Go —— goroutine + channel + select func queryWithTimeout() { ch := make(chan string, 1) go func() { ch <- remoteService.Query() }() select { case result := <-ch: fmt.Println(result) case <-time.After(5 * time.Second): fmt.Println("超时了") } } 没有 Executor ，没有 Future ，没有 BlockingQueue 。 go 关键字一写，协程就启动了。 chan 一建，数据就在协程间流动。 这是 Go 语言最独特的基因 。 ...