标签索引
沿着同一类问题继续读。
从标签快速回到相近主题，把分散的文章重新拼成一条清晰的阅读路径。
# AI开发 (2)
文章 2
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# AI项目 (2)
文章 2
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# API 网关 (4)
文章 4
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# APISIX (4)
文章 4
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# ClickHouse (1)
文章 1
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# DSL (1)
文章 1
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Flink (4)
文章 4
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Go (1)
文章 1
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# I18N (1)
文章 1
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Java (1)
文章 1
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Kafka (1)
文章 1
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Kubernetes (1)
文章 0
-
文章
我现在怎么写一个能长期复用的skill 阅读全文发布于 2026-03-28 -
工程治理体系
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
工程治理体系
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
工程治理体系
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
架构设计
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
架构设计
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
工程治理体系
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 1
-
踩坑
发布于 2026-03-20在 Kubernetes 里，文件描述符往往不在最显眼的资源清单里，但它既会限制进程，也会逐步侵蚀宿主机的公共容量。
# Linux (2)
文章 1
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
小记 1
-
踩坑
发布于 2026-03-20在 Kubernetes 里，文件描述符往往不在最显眼的资源清单里，但它既会限制进程，也会逐步侵蚀宿主机的公共容量。
# MySQL (1)
文章 1
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Pulsar (4)
文章 4
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Redis (1)
文章 1
-
工程治理体系
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# SRE (14)
文章 13
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
工程治理体系
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 1
-
踩坑
发布于 2026-03-20在 Kubernetes 里，文件描述符往往不在最显眼的资源清单里，但它既会限制进程，也会逐步侵蚀宿主机的公共容量。
# SaaS (6)
文章 6
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# Spring (1)
文章 1
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# ToB (10)
文章 10
-
工程治理体系
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
工程治理体系
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# XXL-Job (1)
文章 1
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 上下文治理 (1)
文章 1
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 业务建模 (2)
文章 2
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 事件驱动 (1)
文章 1
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 产品思考 (2)
文章 2
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 价值验证 (4)
文章 4
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 值班体系 (1)
文章 1
-
工程治理体系
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 分布式锁 (2)
文章 2
-
架构设计
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
工程治理体系
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 发布治理 (1)
文章 1
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 变更风险 (1)
文章 1
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 可观测性 (3)
文章 3
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 告警治理 (1)
文章 1
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 国际化 (1)
文章 1
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 增量准入 (2)
文章 2
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 复杂业务治理 (3)
文章 3
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 多环境治理 (2)
文章 2
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 多租户 (6)
文章 6
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 定时任务 (1)
文章 1
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 实时计算 (1)
文章 1
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 容器稳定性 (1)
文章 0
-
文章
我现在怎么写一个能长期复用的skill 阅读全文发布于 2026-03-28 -
工程治理体系
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
工程治理体系
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
工程治理体系
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
架构设计
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
架构设计
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
工程治理体系
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 1
-
踩坑
发布于 2026-03-20在 Kubernetes 里，文件描述符往往不在最显眼的资源清单里，但它既会限制进程，也会逐步侵蚀宿主机的公共容量。
# 工程治理 (35)
文章 35
-
工程治理体系
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
架构设计
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
架构设计
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
工程治理体系
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 工程观察 (1)
文章 1
-
工程治理体系
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 幂等设计 (2)
文章 2
-
架构设计
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
架构设计
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 异常治理 (1)
文章 1
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 性能优化 (5)
文章 5
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 性能诊断 (2)
文章 2
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 扩展机制 (1)
文章 1
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 技术选型 (3)
文章 3
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 排序策略 (1)
文章 1
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 控制面 (3)
文章 3
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 推荐系统 (1)
文章 1
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 插件化 (1)
文章 1
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 故障排查 (3)
文章 3
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 故障隔离 (1)
文章 1
-
工程治理体系
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 数据库 (3)
文章 3
-
架构设计
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 数据治理 (1)
文章 1
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 架构设计 (36)
文章 36
-
工程治理体系
从知乎热榜一个细节，倒推热榜系统在排什么 阅读全文发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
工程治理体系
性能优化不是调参数，先看系统在做什么 阅读全文发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
工程治理体系
AI 时代做项目，最稀缺的还是判断力 阅读全文发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
工程治理体系
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
工程治理体系
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
工程治理体系
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
工程治理体系
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
全球化工程治理
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
工程治理体系
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
工程治理体系
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
多租户采集演进
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
多租户采集演进
我们差点自己做了一套租户调度系统 阅读全文发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
APISIX 多租户网关治理
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
架构设计
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
架构设计
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
工程治理体系
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
工程治理
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
工程治理体系
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 流量治理 (1)
文章 1
-
工程治理体系
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 消息队列 (3)
文章 3
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
工程治理体系
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 消费架构 (2)
文章 2
-
工程治理体系
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
工程治理体系
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 状态机 (3)
文章 3
-
XXL-Job
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
架构设计
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
工程治理体系
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 独立开发 (1)
文章 1
-
工程治理体系
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 稳定性治理 (4)
文章 4
-
工程治理体系
指标做了，然后呢：从补监控到增量准入 阅读全文发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
工程治理体系
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 线上故障 (1)
文章 1
-
工程治理体系
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 质量治理 (1)
文章 1
-
工程治理体系
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 资源隔离 (1)
文章 1
-
多租户采集演进
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 边界管理 (8)
文章 8
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
工程治理体系
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
工程治理体系
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 运维实战 (1)
文章 1
-
SRE 故障实战
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 配置治理 (3)
文章 3
-
工程治理体系
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
工程治理体系
领域稳定性，比接口不挂更难守 阅读全文发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
工程治理体系
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 限流治理 (2)
文章 2
-
APISIX 多租户网关治理
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
APISIX 多租户网关治理
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 需求分析 (4)
文章 4
-
工程治理体系
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
工程治理体系
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
工程治理体系
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
工程治理
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 需求门禁 (1)
文章 1
-
工程治理体系
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。
# 验证治理 (1)
文章 1
-
工程治理体系
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
小记 0
-
小记
发布于 2026-03-28 -
小记
发布于 2026-03-21后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。
-
小记
发布于 2026-03-20一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。
-
小记
发布于 2026-03-14Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。
-
小记
发布于 2026-03-04做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。
-
小记
发布于 2026-02-28性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。
-
小记
发布于 2026-02-25AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。
-
小记
发布于 2026-02-11很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。
-
小记
发布于 2026-01-23上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。
-
小记
发布于 2026-01-16很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。
-
小记
发布于 2025-12-30这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。
-
小记
发布于 2025-12-19资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。
-
小记
发布于 2025-12-11当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。
-
小记
发布于 2025-11-06一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。
-
小记
发布于 2025-10-28让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。
-
小记
发布于 2025-10-16高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。
-
小记
发布于 2025-09-12很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。
-
小记
发布于 2025-07-18国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。
-
小记
发布于 2025-06-10很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。
-
小记
发布于 2025-05-18这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。
-
小记
发布于 2025-03-06很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。
-
小记
发布于 2025-02-12很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。
-
小记
发布于 2025-01-18这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。
-
小记
领域稳定性，比接口不挂更难守 看一眼发布于 2024-11-28一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。
-
小记
发布于 2024-11-21很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。
-
小记
发布于 2024-08-15细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。
-
小记
发布于 2024-04-11不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。
-
小记
我们差点自己做了一套租户调度系统 看一眼发布于 2024-03-14从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。
-
小记
发布于 2023-12-14团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。
-
小记
发布于 2023-12-12一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。
-
小记
发布于 2023-08-15当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。
-
小记
发布于 2023-08-01当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。
-
小记
发布于 2023-07-18把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。
-
小记
发布于 2023-07-11多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。
-
小记
发布于 2023-04-20request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。
-
小记
发布于 2023-04-15很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。
-
小记
发布于 2023-04-13很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。
-
小记
发布于 2022-12-15线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。
-
小记
发布于 2022-11-10我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。
-
小记
发布于 2022-09-20QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。
-
小记
发布于 2022-04-18线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。