简历·软件工程项目经验 角色：高级后端开发工程师（曾主导微服务架构重构与高并发业务线开发） 技术栈：Java / Spring Cloud Alibaba / Redis / Kafka / MySQL / Seata / RDBMS / WebSocket
1.核心项目：订单中心微服务治理与双活架构升级 这是公司最复杂的系统，负责处理百万级日活订单的读写，与此同时支撑双机房的高可用切换。在旧版架构下，跨机房写接口延迟高达 3 秒，且存有单点故障。 为了彻底解决痛点，我没有采用市面上现成的框架，而是从0构建了一套基于 Seata 的动态事务解决方案，并接管了核心订单流的改造工作。 起初，针对交易场景，我引入了 Seata 的 AT 模式，专门针对核心订单与库存扣减这种强一致性需求做了深度定制。
那会儿写个事务要写几百行代码，目前只需求几行配置，且赞成动态开关回滚，这对突发流量下的数据一致性保护至关关键。
特别是两次“秒杀”活动那天，订单中心直接扛住了峰值，没有一分钱数据丢失，库存扣减逻辑在每秒 10 万次请求下依然精准，我们团队故此拿到了年度最佳实践奖。 与此同时，为了应对跨机房复制场景，我设计了基于 MySQL XtraDB 的自动复制方案。
那个方案有个特征，就是能让主从数据库在毫秒级搞定数据同步，就连实现了物理层面的负载均衡，直接切掉非活动节点。
那时候咱们团队晚上加班到凌晨两点的新闻里，全是关于系统负载下降的，领导惊喜地问我如何做的，我好办说了下配置思路，他们一下就理解了。 在开发过程中，我也遇到大量难点，比如主从延迟抖动害得写入黄了，我就写了个自研的监控脚本，把延迟数据实时弹出来，大家看到图表就知道哪儿卡住了，立马调整策略，不再靠运气去猜。
2.核心项目：云原生网关与分布式流量管住 这个项目是应对大促流量的“压舱石”，需求处理每秒数万次的请求，且务必保证 99.99% 的可用性。 我的核心任务是搭建一套基于 Sentinel 的流量管住体系。
那时候系统刚上线，流量突增 20 倍，全链路监控图全绿，但订单量上不去，客服突然爆满。我利用 Reactor 模型把 Sentinel 的流量管住逻辑写进去了，配合 Hystrix 做熔断降级。 这个方案有个挺有意思的地方，就是做得贼灵活。
那会儿做限流是硬压，目前能够按业务类型、按商品等级、就连按用户画像来做差异化限流。
比如生鲜订单务必快，奢侈品订单要慢，我们就能通过配置表一键切换策略。上线后，我们将平均响应工夫从 200ms 压缩到了 50ms，P99 延迟也管住在 100ms 以内，大促期间系统一直保持高吞吐状态，就连出现过新的业务场景，都没被系统卡死。 开发这块我也花了挺长工夫，出于之前有过几次上线事故，教训深刻。我就要求所有人务必把代码写在本地，本地跑通才能上线，这种铁律我们落实得贼死。记得有一次上线，别看测试环境没难题，但线上突然有个小 Bug，出于当时大家都在赶进度，哪位也没注意到异常堆栈，害得请求短暂超时。
事后复盘的时候，我特意把代码审计的流程改成了双人复核制，目前只要再出那种低级难题，简直是不可能的。
3.个人技术竞赛与开源贡献 除了正儿八经的项目，我还参与过一些技术社区的 Contributions，这些经历别看不在那几行经历里，但对我的技术视野帮助挺大。 在 2023 年的 DNF 竞赛中，我作为核心贡献者，解决了 Redis 集群下的内存泄漏难题，那个难题把整个集群的内存用量拉高了一倍。我花了整整两个月工夫分析日志，发现是某个特定的 Key 在生命周期管理上出现了 bug，当时大家都认定挺难，但我发现只要改个生命周期策略，内存立马清空了。 我还分享过几篇文章，讲分布式系统中如何设计一个健壮的超时重试机制，文章阅读量破了十万。别看那篇没发在顶刊上，但工夫久了别人都知道了，还说文章里提到的那个模式在别的系统里也被用上了，算是个小小的传播吧。
4.项目总结与个人标签 纵观这几年的工作，最核心的就是“稳定性”和“可观测性”。
那会儿写代码只想着功能，目前想着数据如何保得住，系统如何跑得稳，日志如何读得快。 我的技术标签里，除了常规的 Java 开发，更强调“系统观”和“架构设计本事”。我不喜爱把线头推着做，而是喜爱提前把链路打通，把异常场景都寻思进去。客套话不多，就是实话实说，把坑填了，把路铺平了，不好让人家踩坑。 要是让我用一句话总结，那就是：在复杂系统中，要把小事做到极致，把细节当作真理。