那次我们拉了十几个业务方关在会议室两天，用事件风暴把微服务边界理清楚了
一场为期两天的事件风暴工作坊，帮助团队解决了微服务拆分的边界难题。核心在于强制统一业务语言，通过梳理领域事件、命令和聚合，从业务事件流中自然推导出服务边界。文章详细记录了建立共识、处理异常流程、将成果转化为代码结构的过程，并分享了落地时的事件版本管理、顺序问题及监控等实战经验。
分类: 后端架构
共 52 篇文章
布隆过滤器防缓存穿透，位数组大小和哈希函数个数不是你拍脑袋定的
布隆过滤器的核心在于位数组大小和哈希函数个数的计算。从误判率公式出发，可根据预期数据量和可接受误判率反推位数组大小，再计算最优哈希函数数量。Guava和RedisBloom等工具可自动完成参数计算，自实现时需注意哈希函数选择与双哈希技巧。线上需预留余量并定期重建，以防数据增长导致误判率飙升。
RocketMQ 事务消息和 RabbitMQ 确认机制，在拆微服务后保证数据一致性上，各自适合什么场景？
RocketMQ 事务消息通过两阶段提交实现消息发送与本地事务的原子性，适合“先发消息后落库”的强一致性场景；RabbitMQ 确认机制配合本地事件表，以“先落库后发消息”实现最终一致性，适合允许秒级延迟的业务。选型取决于业务对实时性和运维复杂度的权衡，且需注意回查逻辑与 Outbox 扫描的实现细节。
我们当年拆微服务，在数据库上踩的最深的一个坑，是从一张订单表开始的
一次深夜数据库故障揭示了微服务拆分中数据库迁移的致命陷阱：过早拆表导致跨库查询崩溃、数据迁移脚本忽略实时变更引发停机、分布式事务在流量高峰时陷入恶性循环。核心教训是：拆分时机优先于方式，应遵循“先服务后数据库”和“先读后写”的迁移策略，用本地事务处理强关联业务，异步消息仅用于真正跨域操作，并通过静态检查杜绝跨库查询。
在 Spring Boot 里把缓存穿透的三种方案压测了一遍，性能差距比想象中大
Spring Boot 防缓存穿透方案对比：布隆过滤器、空值缓存与互斥锁实现及压测。布隆过滤器吞吐量最高达8247 ops/s，延迟仅0.97ms，内存占用小；空值缓存实现简单但内存易膨胀；互斥锁性能最差，不适合穿透场景。组合方案可兼顾性能与零数据库压力。
你的微服务是不是拆过头了？从代码改动频次、独立部署率和认知边界三个维度自检
微服务拆分过度的典型信号是服务数量多但维护者少、改动需跨多个仓库。可从三个维度诊断：代码改动频次，若半年内业务提交少于5次则为“僵尸服务”；独立部署率，若三个月内独立部署占比低于30%则失去微服务核心价值；认知边界，若单人维护超6个服务则粒度过细。三指标全红应合并，合并时需保留提交历史并设置转发层。
分库分表后，非分表键查询走 ES 异构索引还是覆盖索引？把代价摊开算笔账
覆盖索引与ES异构索引是解决非分表键查询的两种妥协方案，选择取决于数据量、查询复杂度和运维能力。覆盖索引成本在数据库侧，随分片数线性增长，易引发连接池瓶颈；ES成本在数据同步一致性和集群维护上。数据量小、查询简单时覆盖索引更优，数据量大、需多条件组合查询时ES优势明显，实际场景常采用混合方案。
切库不停机：一套分库分表灰度方案的设计与踩坑记录
订单系统需在线完成分库分表，方案核心是在新旧库间加入动态路由层，通过配置中心实现按用户ID取模的灰度切流。整体架构分为路由决策、配置管理与数据同步三层，并重点解决了全量同步冲突、切流瞬间双写、同步延迟导致数据不可见以及分片键变更等关键问题。最终历时22天完成切换，实现了零停机与性能大幅提升。
分库分表后，分布式事务怎么选：本地消息表真的过时了吗，Seata 又踩了哪些坑
分布式事务在分库分表后挑战巨大。本地消息表在分库不分服务时依然可控，但分库又分服务后，其延迟与扫表热点问题凸显。Seata AT模式虽代码侵入性低，但运维复杂，存在TC高可用、undo_log膨胀、读未提交隔离导致脏写等深坑。选型需看场景：低QPS、无并发冲突可用AT；高并发或强一致性场景推荐TCC或Saga；异步解耦则用事务消息加本地幂等表最稳。
一次分表键选错，把我们整张表拖垮了
凌晨数据库告警揭示分表键选型错误引发的严重数据热点：以shop_id分片导致头部店铺流量集中，单一分片过载拖垮全表。复盘发现分表键应优先保证数据均匀度而非查询覆盖率，最终选择buyer_id并辅以路由索引表解决非买家维度查询。通过双写与存量回填完成平滑迁移，负载均衡显著改善。总结出分表键选择方法论：均匀度优先、二级索引补位、复合键无效、压测验证。