Node.js 服务端简历范本

工作经历

交易平台在开票高峰会出现短时流量尖峰。服务端组 8 人，我负责订单查询、支付状态回传和商家管理 BFF，和 Java 交易核心团队协作。

• 订单聚合：用户订单页需要分别请求票品、座位、支付、退款四类服务，旧 BFF 串行调用导致 P95 超过 1.8 秒。按依赖关系并发查询，对非关键的活动信息设置超时降级，接口 P95 降至 620ms；同时明确部分失败时页面该显示什么，避免出现“空订单”
• 支付回调幂等：第三方回调可能重复或乱序，原处理逻辑会多次写订单状态。增加业务幂等键与状态转移校验，将回调原文保存在审计日志；补测“先退款后收到成功回调”等边界，季度内没有再次发生重复发券事故
• 突发流量治理：将购票资格查询的热点结果短缓存，把非关键营销查询隔离到独立连接池，并为队列消费者设置并发上限。大型开票场景下订单查询服务保持可用，峰值 每分钟约 9 万次请求时 P99 未出现持续上升
• 排障工具：给核心链路统一 traceId，串起 BFF、消息消费者和交易服务；把事件循环延迟、堆内存、连接池等待列入看板。一次慢接口从报警到定位由过去约 40 分钟缩到 10 分钟以内

团队提供审批和消息产品，前后端共 10 人，我负责通知中心接口及管理后台。

• 为审批通知设计消息模板和发送队列，把同步邮件发送移出请求链路；接口平均耗时由 700ms 左右降到 140ms，失败通知可追踪和重试
• 将零散的 Express 路由迁到 NestJS 模块，统一参数校验、错误码和权限守卫；迁移按业务域逐个发布，老客户端协议保持兼容
• 和测试一起搭建接口契约测试，覆盖字段增删、分页与权限边界，减少前后端联调阶段的重复返工

项目经历

NestJS / PostgreSQL / Redis / OpenTelemetry

面向商家客服，支持按手机号尾号、订单号和场次查询订单。客服高峰时需要在数秒内答复用户，涉及个人信息必须按权限脱敏。

• 原 SQL 把多个筛选条件写成 OR，索引命中不稳定。按查询入口拆 SQL，建立对应复合索引，并限制时间范围；千万级历史订单表的典型查询由 2 秒以上降至 180ms 左右
• 查询结果按商家与场次短缓存，更新事件触发失效；客服查看用户联系方式需要单独鉴权并留下审计记录
• 用 k6 回放脱敏生产流量，发现连接池容量设置过大反而让数据库排队恶化；按实例数量重新预算连接数，压测 P95 更稳定

Node.js / RabbitMQ / Redis / PostgreSQL

订单状态变更后，要分别发送短信、站内信和邮件；供应商会限流，部分消息允许延迟但不能无声丢失。

• 以业务事件 ID 加渠道作为幂等键，消费者成功后写投递记录，重复消费直接返回；失败按指数退避重试，超过次数进入人工可查看的死信列表
• 给供应商接口加并发和速率限制，返回限流错误时延后而非立即重试。大促期间短信供应商故障持续 20 分钟，恢复后队列在一小时内消化，未造成重复发送
• 运维台展示事件来源、尝试次数和最后错误，客服可按订单号追踪通知状态；通知类工单的平均定位时间从半天缩短到约 15 分钟

NestJS / PostgreSQL / Redis / OpenTelemetry

商家后台的开票和对账页面要调用财务、订单、支付三个系统，页面首屏要请求 9 个接口，经常因为其中一个超时整页报错。

• BFF 按页面聚合接口，非关键数据（统计卡片、提示信息）允许降级为空，关键数据失败才整体报错；首屏请求数从 9 个降到 2 个
• 下游调用统一加超时、熔断和并发限制，财务系统抖动时不再拖垮整个 BFF 进程
• 接入 OpenTelemetry，一次请求在网关、BFF 和下游服务的耗时串成一条链路；对账页 P95 从 1.6 秒降到 600ms 左右