5-MongoDB实战演练
本项目基于SpringBoot与MongoDB实现头条文章评论功能，涵盖增删改查、按文章ID查询评论及点赞功能。采用SpringDataMongoDB简化数据操作，通过MongoRepository和MongoTemplate提升开发效率与执行性能，支持分页查询与局部字段更新。
生产环境发布管理
本文介绍大型团队如何通过自动化部署平台实现多环境（dev/test/pre/prod）高效发布与运维。涵盖各环境职责、基于Jenkins+K8S的CI/CD流程、分支管理、一键发布及Skywalking日志链路追踪，提升发布效率与故障排查能力。
发布模式
蓝绿部署通过两套并行系统（绿色在线、蓝色待发布）实现零停机发布与快速回滚，适用于内聚性强的系统。金丝雀发布则逐步替换旧版本，适合大规模集群。A/B测试用于对比多个已上线版本的效果，关注转化率等业务指标，三者各有适用场景。
为什么需要单元测试(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业务。
