为什么需要单元测试(3)
优秀的软件离不开单元测试。它快速、稳定，能精准定位问题，提升调试效率；通过“吃自己狗粮”改善代码可读性与可维护性，降低圈复杂度，促进优质设计与安全重构，是保障代码质量的基石。
从Google线上故障，谈灰度发布的重要性
2025年6月12日，Google Cloud因未灰度发布的配置导致全球服务中断7小时。本文分析故障根因，强调配置灰度发布的重要性，并详解基于Nacos的IP与标签灰度实现方案，助力系统稳定。
OOM排查之路：一次曲折的线上故障复盘
本文记录了一次线上服务因Paimon数据湖与RocksDB集成引发的三次内存溢出（OOM）故障排查全过程。通过MAT、NMT、async-profiler等工具，结合监控分析与专家协作，最终定位到RocksDB通过JNI申请堆外内存未释放的根源问题，并推动架构优化：由应用直写改为Flink统一入湖。分享排查思路与工具使用，为同类技术栈提供借鉴。
为什么要单元测试
单元测试常被视作开发“刹车”，实则加速软件交付。它通过验证代码最小单元的正确性，提前暴露问题，降低修复成本，减少回归缺陷，提升代码质量与维护效率，让系统迭代更稳定、更快捷，真正为长期开发“提速”。（237字）
为什么需要单元测试(2)
长期以来，软件测试依赖人工，繁琐易错。虽演进为自动化测试，但研发与测试分离导致重功能轻质量。谷歌、微软推动“研发即测试”趋势，强调单元测试先行。测试金字塔主张80%单元测试夯实基础，提升代码质量与研发效率，实现可持续交付。
Redis：内存陡增100%深度复盘
一次Redis崩溃事故复盘：大KEY导致带宽占满，内存被缓冲区耗尽，虽有淘汰策略但无法挽救。根本原因非数据膨胀，而是输出/输入缓冲区激增，挤占内存，叠加主线程阻塞，最终引发雪崩。需警惕缓冲区风险，规范使用Redis。
为什么需要单元测试(4)
高质量单元测试虽短期耗时，却显著提升研发效率。它减少调试时间、增强代码变更信心、提升代码自解释性与评审效率，并支持频繁发布，长期看极大提高项目交付速度和质量，尤其适用于生命周期长的To B业务。
为什么需要单元测试(5)
本文剖析单元测试常见反面模式与误区，如“冰激凌筒”“沙漏模式”，揭示重端到端测试、轻单元测试的危害，纠正“用户视角全覆盖即可”“省代码量就是赢”等认知偏差，强调单元测试对代码可维护性与团队协作的关键意义，倡导从进化视角重视单测，提升软件质量与生命力。
微服务保护Sentinel
本课程深入讲解微服务中的雪崩问题及其解决方案，重点介绍阿里开源的流量治理组件Sentinel。内容涵盖Sentinel的部署与整合、限流模式（直接、关联、链路）、流控效果（快速失败、预热、排队等待）、熔断降级、线程隔离及授权规则等核心功能，并结合JMeter压测工具进行实战验证，帮助开发者构建高可用的分布式系统。
17 | 异步 RPC：压榨单机吞吐量
本文深入探讨如何通过异步机制提升RPC框架的单机吞吐量。重点分析影响吞吐量的核心原因——业务逻辑耗时导致CPU利用率低，并提出“异步”为关键解决方案。详细讲解调用端使用Future、服务端支持CompletableFuture实现全链路异步的原理与优势，显著提升系统性能与资源利用率。
