在互联网系统规模不断扩张的背景下，后端服务往往从单体演进到可水平扩展的分布式架构。微服务架构能够通过服务拆分、松耦合治理和水平扩展，为复杂业务提供高可用和高性能支撑。本文结合作者在桂林一家跨境电商 ERP 平台的落地实践，分享基于 Node.js + TypeScript 的微服务架构设计、消息队列异步化和服务扩展经验，为 Web 系统演进提供有价值的参考。
一、为什么选择 TypeScript + Node.js 做微服务
在桂林 ERP 平台中，核心要求包括：
-
商品、订单、物流高度并发
-
需要数十个服务独立扩容
-
消息队列支持异步、削峰、解耦
-
降低业务团队协作和维护成本
选择 Node.js + TypeScript 的原因：
-
TS 具备类型系统，稳定业务逻辑
-
Node.js I/O 并发高，适合服务端 API
-
庞大生态库支持各类业务需求
-
集成 Docker、K8s 部署轻量高效
在压测中，相同业务逻辑下：
-
单服务 QPS：2~6 万
-
延迟 P95：< 30ms
-
CPU 使用率可控
能够满足高并发跨境电商服务的稳定运行。
二、微服务拆分策略
ERP 涉及 SKU、库存、订单、物流、结算和用户中心等复杂业务，因此采取如下拆分原则：
-
以业务边界为服务边界
-
避免服务粒度过细
-
单服务可独立扩容与回滚
-
禁止跨服务直接访问数据库
最终形成如下服务体系：
-
user-service：用户中心
-
sku-service：商品档案与属性
-
stock-service：库存中心
-
order-service：订单生成与路由
-
tracking-service：物流跟踪
-
settlement-service：结算与账单
所有服务之间不直接调用数据库，通过通讯协议交互，保证边界清晰。
三、通讯方式：REST + MQ + GRPC
不同场景选择不同通讯：
| 场景 | 推荐方式 |
|---|---|
| 同步查询 | REST / gRPC |
| 高吞吐变更、异步处理 | Kafka / RabbitMQ |
| 秒级聚合推送 | Redis Stream |
| 批量任务处理 | MQ + Worker Pool |
在桂林项目中，核心链路如下：
Web → order-service order-service → MQ → stock-service stock-service → DB + cache
通过异步化处理，使高峰期请求不会挤爆库存模块。
四、消息队列落地
系统采用 RabbitMQ + Kafka 混合部署：
-
RabbitMQ：订单流、库存变更、延时重试
-
Kafka：大吞吐库存流水分析、报表生成
示例：TypeScript 发送消息
import amqp from "amqplib"; async function sendMessage(queue: string, data: any) { const conn = await amqp.connect("amqp://localhost"); const channel = await conn.createChannel(); await channel.assertQueue(queue); channel.sendToQueue(queue, Buffer.from(JSON.stringify(data))); }
消费示例：
channel.consume(queue, msg => { const payload = JSON.parse(msg.content.toString()); processOrder(payload); channel.ack(msg); });
通过 ACK 机制保证消息：
-
不丢失
-
不重复
-
可重试
五、服务高可用：熔断与限流
高峰流量可能导致：
-
服务响应变慢
-
依赖级联雪崩
-
API 端无法稳定服务
因此服务端加入：
1. 熔断机制
使用 opossum 限制继续压垮已过载服务：
import CircuitBreaker from "opossum"; const breaker = new CircuitBreaker(requestFunction, { timeout: 3000, errorThresholdPercentage: 60, resetTimeout: 5000 });
60% 失败率触发熔断，等待 5 秒后尝试恢复。
2. 限流
使用 token bucket / Leaky Bucket 分配 QPS，保证整体质量。
六、接口网关与统一治理
所有客户端调用统一进入：
-
API Gateway
-
校验 Token
-
分发服务路由
-
记录全链路日志
并支持：
-
灰度发布
-
Canary 测试
-
自定义 A/B 场景
确保系统更新不中断业务连续性。
七、缓存与数据库架构
ERP 数据量大，需要冷热数据分级：
Redis
-
SKU 热门信息
-
库存实时数字
-
订单状态缓存
MySQL
-
货品、交易原始信息
-
财务结算与账单计算
性能优化手段：
-
Redis + MySQL 双写一致性策略
-
库存使用 CAS 减少冲突
-
写操作落库，读尽量走缓存
最终数据库压力降低超过 70%。
八、微服务部署与自动化
系统部署基于：
-
Docker 镜像构建
-
Kubernetes 调度
-
HPA 自动扩容
-
Prometheus 指标监控
-
Loki 聚合日志
高峰期：
-
流量监控触发自动扩容
-
order-service 从 6 副本自动提升到 20
-
峰值过后自动回收
无需人工参与。
九、生产落地经验总结
结合桂林跨境 ERP 平台上线经验：
-
微服务不是越小越好，而是业务边界清晰最重要
-
MQ 是系统稳定运行的核心，不可缺席
-
缓存必须作为第一层性能防线
-
流量高峰必须具有弹性扩容能力
-
日志、监控、链路追踪要比编码更重要
最终系统达到：
-
单服务 QPS 2~6 万
-
峰值订单处理 400 万/小时
-
集群可自动扩缩容
-
故障恢复具备分钟级响应能力