在很多私域直播系统项目中，前期开发看起来进展顺利，但一旦业务复杂起来，就会出现一系列问题：
- 功能修改牵一发而动全身
- 新需求上线周期越来越长
- 系统性能瓶颈难以定位
这些问题，本质都不是“代码写得不好”，而是架构没有做好分层与解耦。
一、为什么私域直播系统必须做分层架构
私域直播系统并不是单一业务，而是多个子系统的组合：
- 直播链路（推流、播放）
- 电商交易（商品、订单、支付）
- 用户体系（登录、标签、权限）
- 互动系统（弹幕、点赞、活动）
如果这些模块直接耦合在一起，后果很明显：
- 修改订单逻辑可能影响直播功能
- 增加互动玩法需要改动多个模块
- 系统扩展几乎不可控
因此，分层的本质，是控制复杂度。
二、典型分层架构设计（实战模型）
一个相对合理的私域直播系统，可以拆为五层：
接入层（API Gateway）
↓
应用层（业务编排）
↓
领域层（核心业务逻辑）
↓
基础设施层（数据库 / 缓存 / 消息队列）
↓
外部服务层（CDN / 流媒体 / 第三方支付）
1. 接入层：统一入口与权限控制
职责：
- API统一入口
- 鉴权、限流
- 请求路由
示例（Node.js + Express）：
// gateway.js
const express = require('express');
const app = express();
app.use(async (req, res, next) => {
const token = req.headers['authorization'];
if (!token) return res.status(401).send('Unauthorized');
// 简化鉴权逻辑
req.user = {
id: 1001 };
next();
});
app.use('/live', require('./routes/live'));
app.use('/order', require('./routes/order'));
app.listen(3000);
2. 应用层：业务流程编排
职责：
- 组织业务流程
- 调用多个领域服务
- 不写具体业务规则
示例（直播下单流程）：
// liveAppService.js
class LiveAppService {
constructor(orderService, liveService) {
this.orderService = orderService;
this.liveService = liveService;
}
async createOrderFromLive(userId, productId) {
const liveStatus = await this.liveService.checkLiveStatus(productId);
if (!liveStatus) throw new Error("直播未开启");
return await this.orderService.createOrder(userId, productId);
}
}
3. 领域层：核心业务逻辑
这是最关键的一层，所有业务规则都应该在这里。
示例（订单领域）：
// orderService.js
class OrderService {
async createOrder(userId, productId) {
const product = await ProductRepo.findById(productId);
if (product.stock <= 0) {
throw new Error("库存不足");
}
const order = {
userId,
productId,
price: product.price,
status: 'INIT'
};
await OrderRepo.save(order);
return order;
}
}
4. 基础设施层：技术能力支撑
包括：
- 数据库（MySQL）
- 缓存（Redis）
- 消息队列（Kafka / RabbitMQ）
比如直播高并发场景下，库存扣减需要用缓存优化：
// stockService.js
const redis = require('./redis');
async function decreaseStock(productId) {
const key = `stock:${
productId}`;
const stock = await redis.decr(key);
if (stock < 0) {
throw new Error("库存已空");
}
}
5. 外部服务层：直播核心能力
这一层通常不自己实现，而是对接：
- 推流服务（RTMP）
- 转码服务
- CDN分发
- 支付接口
示例（推流地址生成）：
function generatePushUrl(streamKey) {
return `rtmp://live.example.com/live/${
streamKey}`;
}
三、模块解耦的核心思路
分层只是基础，真正关键的是“解耦”。
1. 服务解耦：通过接口而不是直接调用
错误方式：
// 直接依赖具体实现（强耦合）
const orderService = new OrderService();
正确方式：
// 依赖抽象
class LiveAppService {
constructor(orderServiceInterface) {
this.orderService = orderServiceInterface;
}
}
2. 事件驱动解耦（推荐）
在直播系统中，很多业务是“异步”的，比如：
- 下单成功 → 发优惠券
- 用户进入直播 → 记录行为
可以用消息队列解耦：
// 发布事件
mq.publish('order.created', {
orderId: 123 });
// 消费事件
mq.subscribe('order.created', (msg) => {
sendCoupon(msg.orderId);
});
这样可以做到：
- 不影响主流程性能
- 各模块独立扩展
3. 数据解耦：避免共享数据库
很多系统的问题在于：
所有模块共用一套数据库
正确做法：
- 订单库、用户库、直播库分离
- 通过接口通信
四、一个典型的解耦后直播下单流程
拆解后流程如下：
用户点击下单
→ 接入层鉴权
→ 应用层编排
→ 订单服务创建订单
→ 发布订单事件
→ 库存服务扣减库存
→ 营销服务发放优惠券
每个模块都可以独立扩展，而不会互相影响。
五、常见错误与优化建议
常见问题
- 把所有逻辑写在Controller层
- 直播与电商逻辑混在一起
- 没有消息机制，全是同步调用
优化建议
- 严格区分“流程”和“规则”
- 核心业务必须下沉到领域层
- 高并发场景必须引入缓存和异步机制
结语
私域直播系统搭建，本质不是把功能拼起来，而是构建一个可持续扩展的系统结构。
分层解决的是结构问题，解耦解决的是演进问题。
如果一开始没有把这两点做好，后面再优化，成本会成倍增加。
真正成熟的系统，往往不是功能最多的，而是改起来最不痛苦的那一个。
