标签频道
可维护性
该标签下的文章、提问与讨论帖。
中间件研发中的工程规范与可维护性实践 一、现象或背景 在一次生产环境的事故复盘中，我们发现一个新服务上线3周后才暴露问题，根因并非代码bug，而是三个默认参数叠加导致的雪崩：连接池maximumPoolSize用默认值10（峰值300QPS
【背景】 做了 5 年中间件研发，最近复盘一起事故：一个新服务上线 3 周才在生产暴露问题，根因不是代码 bug，而是三个"默认值"叠加——连接池 maximumPoolSize 用默认 10（峰值 300 QPS 下必打满）、Kafka
【背景】 最近复盘了两起事故，根因居然一致：我们「信任了中间件的默认值」。 - 一起是 Kafka 消费者停机 8 天重启后静默跳了几百万条（社区已有《offsets.retention 默认 7 天》那篇讲得很透）； - 另一起更隐蔽：H
背景 每次封装一个中间件（MQ 客户端 / 缓存 / RPC / 配置中心），都绕不开同一个问题：这层壳到底该多厚。 打个比方：中间件封装就像给一台发动机装"操作台"。薄操作台，基本就是把油门、挡位原样引出来，司机（业务方）想怎么开怎么开；
背景 做了 3 年中间件，每次给业务方交付客户端（RPC 框架、缓存客户端、MQ producer 这类自研组件），最容易被追问、也最容易在半年后埋雷的一件事就是——中间件抛出来的异常，到底长什么样？ 我见过两种极端：一种是把底层 sock
背景 最近帮几个团队做中间件治理复盘（消息队列、RPC 框架、缓存客户端这类自研组件），翻了一圈配置链路后发现一个反复出现的分裂：同一套中间件，A 团队 90% 参数写在代码仓库的 yaml 里走 GitOps 发布；B 团队几乎全部参数挂
背景 社区里 K8s 侧的「优雅停机」已经讲得很透了——preStop、terminationGracePeriodSeconds、摘流量时序、in-flight 排空，好几篇都在讲「编排层怎么给窗口」。但我最近在一个组里发现，真正翻车的往
一、现象与背景：改一个字段，要翻 47 个文件 先给数字。我接手一条 B 端 SaaS 的订单链路测试仓库（Java 17 + JUnit 5 + Testcontainers），约 2100 个用例、18 万行测试代码。做了一次 "gre
背景：做中间件十年，我发现一个反复出现的分歧——连接池大小、超时时间、重试次数、批量提交大小、队列长度、缓存 TTL……这些参数的默认值，到底该给一个"安全保守"的值，还是给一个"贴近上限"的激进值？这个问题看着小，其实直接决定了一个组件"
文
标题
摘要