按时间回看这些文章和小记。

文章

工程治理体系

后来我慢慢想明白，团队自己觉得难受的地方，未必就是客户最痛的地方。对内部治理来说，先别急着重搭系统，先用企业微信和 CLI 把问题接住、把 SOP 和 checklist 管起来，很多事其实已经够用了。

工程治理 ToB 质量治理 值班体系 需求门禁

工程治理体系

一次刷知乎热榜时冒出来的小疑问，会逼着你先想清楚：热榜到底在排什么，是总量、增速，还是此刻最值得被注意的内容。

架构设计 工程治理 实时计算 推荐系统 排序策略 业务建模

工程治理体系

Pulsar 的 Exclusive、Failover、Shared、Key_Shared 不是四个档位，而是四种不同的业务处理策略。更该区分的，是 Kafka key 主要在决定分区，Pulsar orderingKey 还在决定同一实体由谁消费。

Pulsar Kafka 架构设计 工程治理 消息队列 消费架构

工程治理体系

做一个 Windows AI 剪贴板的过程里，我踩到的最大坑不是代码写不出来，而是产品边界越来越模糊、技术判断来得太早、价值却一直没被说清。

AI开发 工程治理 独立开发 AI项目 产品思考 价值验证

工程治理体系

性能优化很容易把几个不同问题混在一起。更稳的做法，是先分清系统有没有在重复付费，这是用户可感知还是不可感知优化，它在不在高价值路径上，以及这轮改动到底怎么衡量价值。

性能优化 架构设计 工程治理 SRE 可观测性 性能诊断

工程治理体系

AI 的确把写代码这件事变快了，但项目能不能做成，仍然卡在目标收敛、验证节奏、交互主路径和数据库边界这些高判断密度的问题上。

工程治理 架构设计 AI开发 AI项目 产品思考 价值验证

工程治理体系

很多系统后面变重，不是代码突然写坏了，而是为了绕开发版成本，把越来越多业务行为塞进了配置。DSL 真正难的地方，也不是语法，而是解释、约束和治理。

工程治理 架构设计 复杂业务治理 配置治理 DSL 边界管理

工程治理体系

上一篇写的是指标为什么要映射业务结果、辅助定位并进入增量准入。这一篇继续往下看：多租户维度为什么会把 Metrics 自己拖重，告警为什么不能只是把异常一股脑扔给人。

工程治理 SRE 架构设计 可观测性 增量准入 告警治理

工程治理体系

很多系统指标并不少，但它们既照不出业务问题，也带不动处理动作。要补的是结果指标、过程信号、定位维度和准入门禁。

工程治理 SRE 架构设计 可观测性 增量准入 稳定性治理

工程治理体系

这次纠结表面上像 Flink 和 Go 的技术选型，最后把两条路拉开的不是执行效率，而是多租户场景下的成本结构、平台复杂度，以及 AI 时代的交付成本。

Flink Go 架构设计 工程治理 技术选型 价值验证

工程治理体系

资产引擎从安全引擎的业务理念里分出来，但一旦要独立做 Flink 底座，资源申请就先成了前置条件。难点不只是内存和实例数，而是新引擎还没跑出结果，系统却得先替它支付一笔验证成本。

Flink 架构设计 工程治理 ToB 技术选型 价值验证

工程治理体系

当 SaaS、私有化、国际化、行业定制和 feature flag 叠在一起时，同一份代码已经不再对应同一种系统行为。验证越来越重，往往不是测试不努力，而是验证对象变了。更现实的做法，是先把影响面和高风险组合找出来，再用自动化、发布策略和工程治理把风险压住。

工程治理 架构设计 ToB 验证治理 多环境治理 发布治理

工程治理体系

一次租户级灰度需求做到一半，撞上了分布式锁失效。我后来才意识到，真正麻烦的不是灰度本身，而是这类跨微服务需求不该再按单点功能开发去接。

工程观察 架构设计 ToB 需求分析 边界管理

XXL-Job

让我一直别扭的，不是“订单超时取消”这件事怎么做，而是美团这类大规模履约系统底层可能怎么表达它。顺着公开资料往下看，再回头对照我们自己用 XXL-Job 的场景，我才慢慢把两类系统真正的分界线想清楚。

XXL-Job Flink 架构设计 定时任务 状态机 业务建模

工程治理体系

高吞吐不是压测图上的一个数字。真正把问题逼出来的，是同一套系统里开始混跑不同业务、不同顺序要求和不同处理耗时。

Pulsar 性能优化 架构设计 工程治理 消息队列 消费架构

工程治理体系

很多团队配了 DLQ，却没有真正建立异常治理能力。死信真正暴露出来的，不是消息失败了，而是某个业务结果还没有兑现；往后该补的也不只是队列，而是一条异常治理链。

工程治理 架构设计 消息队列 事件驱动 SRE 异常治理

全球化工程治理

国际化真正难的不是把文案翻出来，而是让 locale、时区、货币、国家策略这些上下文在存储、契约、运行时和交付里都说同一种话。

国际化 I18N 工程治理 架构设计 上下文治理 多环境治理

工程治理体系

很多团队把 SaaS 理解成部署方式变化，结果系统越做越重，交付成本降不下来。真正要先想清的，是多租户复利、边界管理、商业模型，以及这些判断怎么落到团队日常决策里。

SaaS ToB 架构设计 工程治理 多租户 边界管理

工程治理体系

这件事表面像 ClickHouse 性能不够，真正逼我改链路的却是本地化部署下的 IO 冲突、重复反序列化成本，以及隔离和复用之间绕不过去的取舍。

ClickHouse Flink 性能优化 架构设计 工程治理 技术选型

工程治理体系

很多 ToB 系统后面越做越重，不是代码后来写烂了，而是接需求那一刻的几个判断先错了。复杂度治理要前移，不要等系统已经长歪了再补救。

复杂业务治理 工程治理 架构设计 ToB 需求分析 边界管理

工程治理体系

很多团队一聊熔断，先想到的是失败率阈值和开关配置。但熔断真正解决的，不是“调用失败”本身，而是明知道下游已经不行了，还继续把线程、连接和等待时间往里送。

稳定性治理 架构设计 SRE 故障隔离

SRE 故障实战

这不是单个故障案例，而是一套可以直接照着走的 Linux 线上排查路径：先做 1 分钟体检，再按 CPU、IO、网络、内存分支定位，最后补查 Limits 和 Runtime 这类隐形故障。

故障排查 Linux SRE 性能优化 运维实战 性能诊断

工程治理体系

一次围绕配置归属的架构争论，让我重新理解稳定性：它不只是限流、熔断和可用性，还包括依赖关系是否健康、语义 owner 是否收敛，以及系统后面还能不能改。

工程治理 架构设计 SRE 稳定性治理 边界管理 配置治理

工程治理体系

很多团队谈接口稳定性，第一反应都是限流、熔断、降级。但真正把系统做稳，往往不是上线后补几层运行时保护，而是从需求、依赖关系、重试语义、压测和巡检一路把失控点前移拦住。

工程治理 架构设计 SRE 稳定性治理 需求分析 边界管理

多租户采集演进

细粒度 ACK 能解决消费进度问题，但线程、连接、内存和重试预算仍然会在进程内部继续互相争抢。

架构设计 工程治理 SRE ToB Pulsar 资源隔离

多租户采集演进

不继续做一套租户调度平台之后，真正要回答的是承载面怎么拆：哪些租户先放进共享池，哪些租户必须拉到专属池，MQ 又该接住哪一层。

架构设计 工程治理 ToB SaaS Pulsar 多租户

多租户采集演进

从本地化交付往 SaaS 化走时，我们一度非常接近做出一套自己的租户调度控制面。后来停下，是因为这套东西会把团队带到另一条主线上。

架构设计 工程治理 ToB SaaS 多租户 控制面

工程治理体系

团队开始希望由一个人统一收口多环境 values 维护时，我慢慢意识到，真正该讨论的不是谁去改配置，而是高危变更里事实确认、流程推进和结果责任该怎么分开。

工程治理 架构设计 SaaS SRE 配置治理 边界管理

工程治理

一次“资产膨胀”需求最开始看起来很像我们自己的治理问题。可越往下做，我越觉得不对：我们名义上在治理资产，实际上却越来越像在替上游做识别。

工程治理 架构设计 复杂业务治理 ToB 需求分析 边界管理

APISIX 多租户网关治理

当网关规则开始规模化，问题就不再是会不会配 APISIX，而是谁定义策略、谁发布配置、谁审批特例、谁保证回滚审计。本文拆解这套平台化治理的最终收束。

APISIX API 网关 工程治理 架构设计 多租户 控制面

APISIX 多租户网关治理

当限流开始同时受套餐、接口和租户影响，问题已经不再是插件挂哪一层，而是请求进来后该命中哪条规则。本文拆解控制面编译与数据面决策的最终落地方案。

APISIX API 网关 多租户 架构设计 工程治理 限流治理

APISIX 多租户网关治理

把套餐直接写在 Route 上，短期确实省事，但新租户接入、套餐升级和凭证轮换很快会把配置拖乱。真正需要先理顺的，是 Route、Consumer、套餐组和凭证管理各自管什么。

APISIX API 网关 SaaS 多租户 架构设计 控制面

APISIX 多租户网关治理

多租户 API 一旦开始分免费版、付费版和入口防护，限流就不只是某个 Route 上的插件参数问题。真正要先拆开的，是入口层、套餐层和路由职责。

APISIX API 网关 SaaS 架构设计 工程治理 限流治理

架构设计

request_id、唯一键、本地事务、状态机幂等表和 Redis 过程控制各有自己的成立边界。真正先要看清的，不是团队会什么，而是这次业务到底在哪一刻才算真正成立。

架构设计 工程治理 幂等设计 状态机 分布式锁

架构设计

很多数据库幂等问题不在请求是不是又来了一次，而在写操作是不是还建立在一个不稳定的当前状态上。沿着创建、更新、覆盖冲突和删除四类动作，我把自己最常用的几条工程默认值重新收了一遍。

架构设计 工程治理 数据库 幂等设计

工程治理体系

很多分布式流程的问题不在“能不能跑通”，而在旧线程恢复以后，系统最后那份状态还能不能信。沿着一条资产推理链路，我把状态机、看门狗锁和 Fencing Token 各自补的口子重新拆了一遍。

架构设计 工程治理 Redis 状态机 分布式锁

工程治理

线上删除难的不是把 delete 跑起来，而是确认这批数据在业务上是否真的走完生命周期、影响面是不是看全、删错后还能不能低成本收回来。

工程治理 架构设计 数据库 SRE 数据治理 变更风险

工程治理体系

我们有扫描任务，要接第三方扫描器，而且开放接入本身就是这套系统的核心诉求之一。问题不在于今天有几个扫描器，而在于做之前根本不知道未来会来哪些实现。比起继续把变化堆进主流程，我更想给这类代码级扩展一个统一接入边界。

工程治理 架构设计 Java Spring 扩展机制 插件化

工程治理体系

QPS 激增时，真正决定你该怎么救火的，往往不是峰值多少，而是流量到底是一根针还是一堵墙，系统又是在算不过来还是等不过来。

性能优化 故障排查 SRE 工程治理 架构设计 流量治理

工程治理体系

线上 MySQL 死锁最容易被回答成“先 kill 掉卡住事务”。真正更重要的，是先分清单次死锁和系统性阻塞，再按诊断、止血、根因分析和并发治理一路往下做。

MySQL 数据库 线上故障 工程治理 SRE 故障排查