负责供应链履约核心系统（OMS/WMS/TMS联动）的架构设计与全生命周期迭代，边界覆盖从采购入库到末端配送的全链路流程，支撑日均120万+订单的履约处理与跨仓调拨需求

• 主导设计并落地OMS订单管理系统的微服务重构项目，针对原有单块架构QPS峰值仅800、故障恢复时间长（平均45分钟）的痛点，采用Spring Cloud Alibaba框架拆分出订单中心、履约调度中心、异常处理中心三个核心服务；通过Seata TCC模式解决订单创建与多仓库存扣减的分布式事务问题，将事务成功率从92%提升至99.95%；结合Sentinel的流量控制与熔断降级策略，应对618大促期间3500 QPS的流量洪峰，系统可用性稳定在99.99%以上
• 核心参与库存一致性优化专项，针对多仓库库存同步延迟（原5分钟）导致的超卖问题，引入Redis分布式锁+Canal监听MySQL binlog的方案，实现库存变更的实时同步，将同步延迟压缩至100ms以内；同时设计“预占-确认-释放”的库存闭环机制，通过RocketMQ异步处理预占请求，大促期间超卖率从0.1%降至0.01%，减少客诉成本约30万元/月
• 重点突破订单查询接口性能瓶颈，原接口P99响应时间达800ms、数据库QPS峰值1200，通过重构联合索引（新增order_status、create_time等字段的组合索引12个）、引入Elasticsearch构建订单二级索引（同步延迟≤5秒），将响应时间缩短至150ms以内；叠加Caffeine缓存热点订单（TOP20%订单占比60%），缓存命中率达92%，数据库读QPS下降至400，资源利用率提升40%
• 推动团队技术标准化落地，主导编写《Java后端微服务开发规约》《履约系统接口设计标准》等5份文档，引入SonarQube进行代码质量管控（规则覆盖圈复杂度、重复率等10+维度），将代码重复率从15%降至5%以下；搭建Jenkins+Docker+K8s的CI/CD流水线，实现代码提交到部署的自动化（部署时间从1小时缩短至15分钟），团队交付效率提升50%

负责电商平台订单系统的基础功能迭代与高并发场景优化，边界支撑平台日常订单处理及618/双11等大促活动的稳定性保障

• 参与订单系统的分布式改造，将原有单体应用拆分为订单服务、支付回调服务、物流对接服务，使用Dubbo作为RPC框架实现服务注册与发现；针对拆分后服务间通信延迟（原200ms）问题，优化Dubbo负载均衡策略（从随机改为加权轮询，基于服务实例CPU利用率动态调整权重），将平均响应时间降低20%，服务调用成功率提升至99.9%
• 解决支付回调可靠性问题，针对原有回调失败重试机制（固定间隔3秒）导致的回调超时、数据不一致，设计“指数退避+消息补偿”方案：使用RocketMQ存储回调请求，失败时按1s/2s/4s/8s的间隔重试，超过5次则转入人工工单；同时开发回调日志监控系统（基于ELK栈），实时预警回调异常，将回调成功率从95%提升至99.8%，减少人工排查时间80%
• 支撑大促活动的流量管控，针对双11期间订单系统面临的流量冲击（预估峰值2500 QPS），使用Hystrix实现服务的熔断（错误率超过50%时自动熔断，恢复时间1分钟），结合Guava RateLimiter做接口限流（核心接口每秒最多处理2000个请求），确保活动期间订单成功率保持在99.5%以上，未出现系统宕机
• 优化订单状态流转逻辑，原状态机使用if-else实现（代码冗余度30%），重构为基于Spring State Machine的状态机模型，定义“待支付-已支付-备货中-运输中-已签收”等8个状态及触发事件，代码可读性提升50%，后续状态扩展效率提升70%

协助完成电商平台基础功能开发与维护，边界聚焦订单生成、支付接口对接等核心流程的实现与问题修复

• 参与订单生成模块开发，使用Spring Boot框架实现订单创建接口，整合Redis的雪花算法生成唯一订单号（每秒生成10000+个，无重复），并通过校验码机制确保订单号的有效性；对接支付宝支付接口，处理支付回调逻辑（解析回调参数、更新订单状态、记录支付日志），回调成功率达98%，支撑平台日均10万+订单的支付处理
• 解决订单重复提交问题，前端采用防抖按钮（点击后禁用3秒），后端通过Redis存储Token（生成后5分钟有效），请求时校验Token有效性并删除，将重复提交率从3%降至0.1%以下，减少无效订单对库存的占用
• 优化订单列表查询接口，原接口使用MyBatis的动态SQL查询（未加索引），P99响应时间达500ms；通过添加order_create_time、user_id的联合索引，结合PageHelper分页插件（每页20条），将响应时间缩短至200ms，用户查询体验提升
• 协助排查订单系统BUG，针对“订单支付后未同步物流信息”问题，通过日志追踪（Logback记录接口调用链）发现是MQ消息发送失败未重试，修复后消息投递成功率从90%提升至99.5%，减少物流漏发问题约15%

电商大促场景下分布式事务一致性优化项目

• 项目背景：电商大促期间，订单、库存、优惠券跨服务的事务一致性问题突出，曾出现超卖、优惠券重复核销等情况，导致客诉率上升15%、单场大促营收损失约800万元；核心目标是解决高并发（峰值10万TPS）下分布式事务的强一致性与高吞吐量矛盾，保障大促期间核心链路99.99%可用性。
• 关键难题：原有TCC事务模式在高并发写场景下存在严重锁竞争——库存扣减的try阶段需锁定整张商品库存表，导致吞吐量骤降40%；同时跨服务的券发放与订单状态一致性校验延迟，偶发“订单成功但券未到账”的问题，影响用户体验。
• 核心行动：① 设计“混合事务模型”：对库存扣减这类高频写操作，替换为“本地消息表+异步补偿”机制——订单服务创建订单时，将库存扣减指令写入本地消息表，通过定时任务+指数退避重试策略异步推送至库存服务，避免长事务锁表；对券发放这类低频关键操作，保留Seata TCC模式保证强一致。② 构建幂等保障体系：基于Redis分布式锁+全局唯一订单ID，拦截重复的库存扣减/券发放请求，解决异步消息重投导致的幂等问题。③ 打造事务监控闭环：用Prometheus+Grafana监控事务成功率、延迟，结合Alertmanager设置阈值预警，自动触发补偿任务（如事务失败时回滚库存、补发优惠券）。
• 项目成果：大促期间订单成功率从99.5%提升至99.99%，库存扣减吞吐量提升300%（从6万TPS到18万TPS），优惠券核销准确率达100%；客诉率下降85%，直接减少年度营收损失约6000万元；该方案被推广至公司全电商平台，成为大促事务处理的基准架构，个人也因此晋升为事务架构方向的核心负责人。

会员服务体系微服务化重构项目

• 项目背景：原有会员系统为单体架构，会员权益、积分、等级等模块高度耦合，新增积分规则需修改整个服务代码，迭代周期长达2周；曾因积分模块BUG导致50万会员积分异常，故障影响范围覆盖全会员体系。核心目标是将单体拆分为“会员核心域、权益域、积分域”3个微服务，提升迭代效率至1周/版本，降低故障影响范围至单个域。
• 关键难题：① 数据一致性：会员等级变更需同步更新权益（如专属折扣）、积分（如等级对应的积分倍数），单体内部调用变为远程调用后，易出现数据不一致；② 服务调用性能：拆分后服务间调用延迟从毫秒级升至几十毫秒，影响会员注册流程的响应时间（从200ms增至500ms）。
• 核心行动：① 用DDD领域驱动设计划定服务边界：会员核心域负责账号、等级管理，权益域负责折扣、专属权益发放，积分域负责积分计算、消耗，明确服务间通过事件驱动的调用关系。② 解决数据一致性问题：用Canal监听会员核心域的MySQL binlog，实时同步等级变更事件至权益域、积分域，保证数据最终一致性；同时设计“回滚钩子”——若权益域同步失败，会员核心域自动回滚等级变更。③ 性能优化：采用Apache Dubbo做RPC框架，配置基于一致性哈希的负载均衡与连接池复用，将服务间调用延迟降至50ms以内；用Sentinel做熔断降级，当积分域故障时，会员注册流程仍可完成，积分后续通过定时任务补发。
• 项目成果：微服务拆分后，迭代周期缩短至1周/版本，故障影响范围缩小80%；会员注册响应时间从500ms降至250ms，注册成功率提升至99.8%；支撑会员数从500万增长至1200万，未发生因架构问题导致的大规模故障；该重构方案成为公司其他业务线微服务拆分的参考模板，个人积累了从单体到微服务的全生命周期落地经验。

• 因痛心于年轻人对历史的疏离，我在B站创立「古人脱口秀」栏目，用职场梗解构历史事件（如《雍正皇帝的KPI保卫战》）。通过设计「颠覆认知-史料佐证-现代共鸣」三幕剧本模板，单期视频最高收获1.7万条弹幕互动。
• 两年间栏目播放量突破180万，作品被多地中学选为教学素材。这段经历磨砺出将学术内容转化为大众语言的能力，也让我理解到真实用户反馈才是创作者的指南针。