Node.js后端服务架构设计：从分层模式到数据库选型的工程决策
一、全栈开发者的后端困境：从"能跑"到"能扛"
前端开发者转全栈，最常犯的错误是把后端当成"给前端提供API的工具"。数据库选型凭直觉，服务分层靠感觉，错误处理用try-catch包一层了事。开发阶段一切正常，上线后问题集中爆发：慢查询拖垮响应时间、数据一致性问题频发、服务扩展时发现代码耦合严重。
后端服务设计的核心，不是选择哪个框架或数据库，而是建立清晰的分层架构和数据流转规则。每一层有明确的职责边界，每个数据操作有可追溯的路径。这不是过度设计，而是避免技术债务累积的必要投入。
二、Node.js后端服务的分层架构与数据流
一个健壮的Node.js后端服务，至少需要四层：路由层、业务层、数据访问层、基础设施层。每层之间通过接口交互，不直接依赖具体实现。
flowchart TB subgraph 路由层 A1[请求校验] A2[认证鉴权] A3[限流控制] end subgraph 业务层 B1[用户服务] B2[内容服务] B3[通知服务] end subgraph 数据访问层 C1[用户Repository] C2[内容Repository] C3[缓存Repository] end subgraph 基础设施层 D1[(PostgreSQL)] D2[(Redis)] D3[(MongoDB)] D4[消息队列] end A1 --> B1 A2 --> B1 A3 --> B1 A1 --> B2 B1 --> C1 B2 --> C2 B3 --> C3 C1 --> D1 C2 --> D1 C2 --> D3 C3 --> D2 B3 --> D4路由层负责请求的入口校验，包括参数验证、身份认证和限流。业务层封装核心逻辑，不关心数据如何存储。数据访问层屏蔽存储细节，业务层只通过Repository接口操作数据。基础设施层管理数据库连接、缓存和消息队列。
三、实战：分层架构与多数据库协作的完整实现
// ============ 基础设施层：数据库连接管理 ============ /** * 数据库连接管理器 * 核心设计：连接池化 + 健康检查 + 优雅关闭 * 为什么需要连接池？每次请求创建连接的开销很大， * 池化后连接可复用，响应时间显著降低 */ class DatabaseManager { private static instance: DatabaseManager; private connections: Map<string, { pool: unknown; health: boolean }> = new Map(); private constructor() {} static getInstance(): DatabaseManager { if (!DatabaseManager.instance) { DatabaseManager.instance = new DatabaseManager(); } return DatabaseManager.instance; } /** * 注册数据库连接 * 支持同时管理多个不同类型的数据库 */ registerConnection(name: string, pool: unknown): void { this.connections.set(name, { pool, health: true }); // 定期健康检查，标记不可用的连接 // 为什么需要健康检查？数据库可能因网络问题断开， // 不检查的话请求会打到已断开的连接上 setInterval(() => this.checkHealth(name), 30000); } getConnection(name: string): unknown { const conn = this.connections.get(name); if (!conn || !conn.health) { throw new Error(`数据库连接 ${name} 不可用`); } return conn.pool; } private async checkHealth(name: string): Promise<void> { const conn = this.connections.get(name); if (!conn) return; try { // 简单的ping检查 const pool = conn.pool as { query: (sql: string) => Promise<unknown> }; await pool.query('SELECT 1'); conn.health = true; } catch { conn.health = false; console.error(`数据库 ${name} 健康检查失败`); } } // 优雅关闭所有连接 async shutdown(): Promise<void> { for (const [name, conn] of this.connections) { try { const pool = conn.pool as { end: () => Promise<void> }; await pool.end(); console.log(`数据库 ${name} 连接已关闭`); } catch (error) { console.error(`数据库 ${name} 关闭失败:`, error); } } } } // ============ 数据访问层：Repository模式 ============ // Repository接口定义 interface UserRepository { findById(id: string): Promise<User | null>; findByEmail(email: string): Promise<User | null>; create(data: CreateUserInput): Promise<User>; update(id: string, data: Partial<User>): Promise<User>; delete(id: string): Promise<void>; } interface User { id: string; email: string; name: string; role: string; createdAt: Date; updatedAt: Date; } interface CreateUserInput { email: string; name: string; password: string; role?: string; } /** * PostgreSQL用户Repository * 为什么用Repository模式而非直接在Service里写SQL？ * Repository封装了存储细节，业务层不需要知道 * 数据存在PostgreSQL还是MongoDB里。 * 未来换数据库，只需实现新的Repository，业务代码不动 */ class PostgresUserRepository implements UserRepository { private pool: unknown; constructor(dbManager: DatabaseManager) { this.pool = dbManager.getConnection('postgres'); } async findById(id: string): Promise<User | null> { const pool = this.pool as { query: (sql: string, params: unknown[]) => Promise<{ rows: User[] }>; }; const result = await pool.query( 'SELECT id, email, name, role, created_at, updated_at FROM users WHERE id = $1', [id] ); return result.rows[0] || null; } async findByEmail(email: string): Promise<User | null> { const pool = this.pool as { query: (sql: string, params: unknown[]) => Promise<{ rows: User[] }>; }; const result = await pool.query( 'SELECT id, email, name, role, created_at, updated_at FROM users WHERE email = $1', [email] ); return result.rows[0] || null; } async create(data: CreateUserInput): Promise<User> { const pool = this.pool as { query: (sql: string, params: unknown[]) => Promise<{ rows: User[] }>; }; // 密码不在Repository层加密，这是业务逻辑 const result = await pool.query( `INSERT INTO users (email, name, password_hash, role) VALUES ($1, $2, $3, $4) RETURNING id, email, name, role, created_at, updated_at`, [data.email, data.name, data.password, data.role || 'user'] ); return result.rows[0]; } async update(id: string, data: Partial<User>): Promise<User> { const pool = this.pool as { query: (sql: string, params: unknown[]) => Promise<{ rows: User[] }>; }; // 动态构建SET子句，只更新传入的字段 const fields: string[] = []; const values: unknown[] = []; let paramIndex = 1; Object.entries(data).forEach(([key, value]) => { if (value !== undefined && key !== 'id') { fields.push(`${this.camelToSnake(key)} = $${paramIndex}`); values.push(value); paramIndex++; } }); if (fields.length === 0) { throw new Error('没有需要更新的字段'); } values.push(id); const result = await pool.query( `UPDATE users SET ${fields.join(', ')}, updated_at = NOW() WHERE id = $${paramIndex} RETURNING id, email, name, role, created_at, updated_at`, values ); if (result.rows.length === 0) { throw new Error(`用户 ${id} 不存在`); } return result.rows[0]; } async delete(id: string): Promise<void> { const pool = this.pool as { query: (sql: string, params: unknown[]) => Promise<{ rowCount: number }>; }; // 软删除：标记deleted_at而非物理删除 // 为什么软删除？数据恢复需求、审计追踪、 // 外键关联的完整性保护 const result = await pool.query( 'UPDATE users SET deleted_at = NOW() WHERE id = $1', [id] ); if (result.rowCount === 0) { throw new Error(`用户 ${id} 不存在`); } } private camelToSnake(str: string): string { return str.replace(/[A-Z]/g, letter => `_${letter.toLowerCase()}` ); } } // ============ 业务层：Service ============ /** * 用户服务 * 核心职责：业务逻辑编排，不关心数据存储细节 */ class UserService { private userRepo: UserRepository; private cacheRepo: CacheRepository; constructor(userRepo: UserRepository, cacheRepo: CacheRepository) { this.userRepo = userRepo; this.cacheRepo = cacheRepo; } /** * 获取用户信息，带缓存 * 为什么缓存放在Service层而非Repository层？ * 缓存是业务决策（哪些数据需要缓存、缓存多久）， * 不是存储细节，应该由Service控制 */ async getUser(id: string): Promise<User> { // 先查缓存 const cached = await this.cacheRepo.get(`user:${id}`); if (cached) return cached as User; // 缓存未命中，查数据库 const user = await this.userRepo.findById(id); if (!user) { throw new Error(`用户 ${id} 不存在`); } // 写入缓存，设置5分钟过期 // 为什么5分钟？用户信息变更频率低，5分钟是合理的折中 await this.cacheRepo.set(`user:${id}`, user, 300); return user; } /** * 创建用户，包含业务校验 */ async createUser(input: CreateUserInput): Promise<User> { // 业务校验：邮箱唯一性 const existing = await this.userRepo.findByEmail(input.email); if (existing) { throw new Error('该邮箱已注册'); } // 密码加密——这是业务逻辑，不属于Repository的职责 const hashedPassword = await this.hashPassword(input.password); const user = await this.userRepo.create({ ...input, password: hashedPassword, }); // 创建成功后清除相关缓存 await this.cacheRepo.delete(`user:list`); return user; } private async hashPassword(password: string): Promise<string> { // 实际项目中使用bcrypt或argon2 const encoder = new TextEncoder(); const data = encoder.encode(password); const hash = await crypto.subtle.digest('SHA-256', data); return Array.from(new Uint8Array(hash)) .map(b => b.toString(16).padStart(2, '0')) .join(''); } } // 缓存Repository接口 interface CacheRepository { get(key: string): Promise<unknown | null>; set(key: string, value: unknown, ttlSeconds?: number): Promise<void>; delete(key: string): Promise<void>; } // ============ 路由层：请求处理 ============ /** * 用户路由处理器 * 职责：参数校验、认证鉴权、响应格式化 * 不包含任何业务逻辑 */ class UserRouter { private userService: UserService; constructor(userService: UserService) { this.userService = userService; } async getUserHandler( req: { params: { id: string }; userId?: string }, res: { json: (data: unknown) => void; status: (code: number) => { json: (data: unknown) => void } } ): Promise<void> { try { // 参数校验 if (!req.params.id) { res.status(400).json({ error: '缺少用户ID' }); return; } const user = await this.userService.getUser(req.params.id); // 响应中移除敏感字段 // 为什么在这里移除而非Service层？因为不同接口 // 返回的字段范围可能不同，这是路由层的决策 const { password: _, ...safeUser } = user as User & { password?: string }; res.json({ data: safeUser }); } catch (error) { const message = error instanceof Error ? error.message : '未知错误'; res.status(404).json({ error: message }); } } }四、数据库选型的决策框架
PostgreSQL vs MySQL。PostgreSQL对复杂查询、JSON字段、全文搜索的支持更好，适合数据模型复杂、查询场景多样的业务。MySQL在简单读写场景下性能更优，运维生态更成熟。新项目默认选PostgreSQL，除非有明确的MySQL优势场景。
关系型 vs 文档型。结构化数据（用户、订单、支付）用关系型数据库，保证事务一致性。半结构化数据（日志、配置、内容）用MongoDB，灵活的Schema减少迁移成本。不要用MongoDB存需要事务的数据，也不要用PostgreSQL存频繁变更Schema的文档。
Redis的定位。Redis是缓存和会话存储，不是主数据库。数据可以丢失、可以重建的才放Redis。用户会话、热门查询缓存、限流计数器是Redis的典型场景。把Redis当主存储用，数据持久化是个定时炸弹。
选型的核心原则。一个项目中的数据库种类不超过三种。每多一种数据库，运维复杂度指数级增长。能用一种数据库解决的，不要引入第二种。数据库选型是减法，不是加法。
五、总结
Node.js后端服务设计的核心，是建立清晰的分层架构。路由层管校验和格式化，业务层管逻辑编排，数据访问层管存储操作，基础设施层管连接和配置。每层职责明确，变更时影响范围可控。
数据库选型不是技术偏好问题，而是业务特征匹配问题。数据模型决定数据库类型，查询模式决定具体产品。一个项目中数据库种类越少越好，能用一种解决的不要用两种。技术应当有温度，温度来自对系统可维护性的长远考量，而非对新技术的好奇。
