Guide

Appearance

如何设计一个可扩展的架构 ​

你有没有想过：

  • 为什么微信能支持 10 亿用户同时在线？
  • 为什么淘宝在双十一能扛住 54 万订单/秒？
  • 为什么你的系统一到大促就崩？

这些差距的背后，是架构扩展性的差异。

今天，我们来深入探讨如何设计一个可扩展的架构。

一、什么是可扩展性？ ​

1.1 扩展性的定义 ​

┌─────────────────────────────────────────────────────────┐
│                    扩展性的定义                              │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  可扩展性（Scalability）                                 │
│                                                         │
│  水平扩展（Scale Out）                                   │
│  ├─ 增加更多服务器                                      │
│  ├─ 适用于用户量增长                                  │
│  └─ "多开几个窗口"                                    │
│                                                         │
│  垂直扩展（Scale Up）                                   │
│  ├─ 增加单台服务器配置                                │
│  ├─ 适用于性能优化                                    │
│  └─ "把窗口开大一点"                                  │
│                                                         │
│  架构扩展                                              │
│  ├─ 系统架构能否适应业务变化                          │
│  ├─ 新功能能否快速上线                                │
│  └─ 系统瓶颈能否快速定位和解决                        │
│                                                         │
└─────────────────────────────────────────────────────────┘

1.2 扩展性的误区 ​

误区一：「买最贵的服务器就能解决问题」
- 硬件有上限，而业务增长无上限
- 垂直扩展有天花板

误区二：「系统不需要扩展，先用简单架构」
- 技术债务会越积越多
- 重构成本往往比重写还高

误区三：「扩展就是加服务器」
- 架构设计才是根本
- 错误的架构，加再多服务器也没用

二、扩展性原则 ​

2.1 无状态设计 ​

java
/**
 * 无状态 vs 有状态
 */
public class StatelessVsStateful {
    
    /**
     * 有状态的问题
     * 
     * 用户请求必须路由到特定服务器
     * 扩展困难，单点故障
     */
    public static class StatefulService {
        // 用户会话存储在本地内存
        private Map<String, UserSession> sessions = new HashMap<>();
        
        public UserSession getSession(String userId) {
            return sessions.get(userId);
        }
    }
    
    /**
     * 无状态的好处
     * 
     * 任何服务器都能处理请求
     * 轻松扩展，故障自动恢复
     */
    public static class StatelessService {
        
        public Response handleRequest(Request request) {
            // 从外部获取用户状态（Redis/数据库）
            UserSession session = redis.get("session:" + request.getUserId());
            
            // 纯函数式处理
            return process(request, session);
        }
    }
}

2.2 服务拆分 ​

java
/**
 * 单体 vs 微服务
 */
public class MonolithVsMicroservices {
    
    /**
     * 单体架构的问题
     */
    public static class Monolith {
        // 一个巨大的应用
        // ├── UserService（用户服务）
        // ├── OrderService（订单服务）
        // ├── ProductService（商品服务）
        // └── PaymentService（支付服务）
        
        // 问题：
        // - 所有代码耦合在一起
        // - 一个模块出问题，影响整个系统
        // - 技术选型不灵活
        // - 扩展困难
    }
    
    /**
     * 微服务架构
     */
    public static class Microservices {
        // 用户服务 - 独立部署，独立扩展
        // 订单服务 - 独立部署，独立扩展
        // 商品服务 - 独立部署，独立扩展
        // 支付服务 - 独立部署，独立扩展
        
        // 服务间通过 API/RPC 通信
    }
}

2.3 异步处理 ​

java
/**
 * 同步 vs 异步
 */
public class SyncVsAsync {
    
    /**
     * 同步处理的问题
     */
    public static class SyncProcessing {
        public OrderResult createOrder(Order order) {
            // 1. 验证用户（同步）
            validateUser(order.getUserId());
            
            // 2. 验证库存（同步）
            validateStock(order.getItems());
            
            // 3. 创建订单（同步）
            createOrderRecord(order);
            
            // 4. 扣减库存（同步）
            deductStock(order.getItems());
            
            // 5. 发送通知（同步）
            sendNotification(order);
            
            // 所有步骤必须按顺序执行
            // 总耗时 = sum(每个步骤耗时)
            return new OrderResult();
        }
    }
    
    /**
     * 异步处理的好处
     */
    public static class AsyncProcessing {
        public OrderResult createOrder(Order order) {
            // 1. 创建订单（核心步骤，同步）
            createOrderRecord(order);
            
            // 2. 发布事件（非核心步骤，异步）
            mq.publish("order:created", order);
            
            // 其他步骤异步执行
            // 总耗时 = max(核心步骤耗时)
            return new OrderResult();
        }
    }
}

三、扩展性架构设计 ​

3.1 分层架构 ​

┌─────────────────────────────────────────────────────────┐
│                    分层架构                                  │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  网关层（Gateway）                                       │
│  ├─ 路由转发                                           │
│  ├─ 限流熔断                                           │
│  └─ 安全认证                                           │
│                                                         │
│  应用层（Application）                                   │
│  ├─ 业务逻辑                                           │
│  ├─ 事务控制                                           │
│  └─ 组合服务                                           │
│                                                         │
│  服务层（Service）                                       │
│  ├─ 核心业务逻辑                                       │
│  ├─ 领域模型                                           │
│  └─ 数据访问                                           │
│                                                         │
│  数据层（Data）                                         │
│  ├─ 数据库                                             │
│  ├─ 缓存                                               │
│  └─ 消息队列                                           │
│                                                         │
└─────────────────────────────────────────────────────────┘

3.2 CQRS 架构 ​

java
/**
 * CQRS（命令查询职责分离）
 */
public class CQRSArchitecture {
    
    /**
     * 命令端（写）
     */
    public static class CommandSide {
        
        public void placeOrder(Order order) {
            // 1. 验证订单
            validateOrder(order);
            
            // 2. 扣减库存
            deductStock(order);
            
            // 3. 保存订单
            orderRepository.save(order);
            
            // 4. 发送事件
            eventPublisher.publish(new OrderPlacedEvent(order));
        }
    }
    
    /**
     * 查询端（读）
     */
    public static class QuerySide {
        
        public OrderView getOrderView(Long orderId) {
            // 从物化视图读取
            return orderViewRepository.findById(orderId);
        }
        
        public List<OrderView> searchOrders(String keyword) {
            // 从 Elasticsearch 搜索
            return elasticsearch.search(keyword);
        }
    }
    
    /**
     * 数据同步
     */
    @KafkaListener(topics = "order:events")
    public void handleOrderEvent(OrderEvent event) {
        if (event instanceof OrderPlacedEvent) {
            // 更新物化视图
            updateOrderView((OrderPlacedEvent) event);
        }
    }
}

3.3 事件驱动架构 ​

java
/**
 * 事件驱动架构
 */
public class EventDrivenArchitecture {
    
    /**
     * 事件总线
     */
    public static class EventBus {
        
        public void publish(DomainEvent event) {
            // 发布到消息队列
            mq.publish(event.getTopic(), event);
        }
    }
    
    /**
     * 事件处理器
     */
    public static class EventHandlers {
        
        @KafkaListener(topics = "order:placed")
        public void handleOrderPlaced(OrderPlacedEvent event) {
            // 发货服务：创建发货单
            deliveryService.createDelivery(event.getOrderId());
        }
        
        @KafkaListener(topics = "order:paid")
        public void handleOrderPaid(OrderPaidEvent event) {
            // 库存服务：确认库存扣减
            stockService.confirmDeduction(event.getOrderId());
        }
        
        @KafkaListener(topics = "order:completed")
        public void handleOrderCompleted(OrderCompletedEvent event) {
            // 积分服务：增加用户积分
            pointsService.addPoints(event.getUserId(), event.getAmount());
        }
    }
}

四、扩展性评估 ​

4.1 扩展性指标 ​

扩展性评估维度：

1. 用户量扩展
   - 当前用户量 → 10 倍用户量 → 100 倍用户量
   - 需要改多少代码？

2. 数据量扩展
   - 当前数据量 → 10 倍数据量 → 100 倍数据量
   - 数据库能否支撑？

3. 功能扩展
   - 新增功能需要修改多少模块？
   - 新增一个类似功能需要多久？

4. 团队扩展
   - 多少人可以并行开发？
   - 团队从 10 人扩展到 100 人容易吗？

4.2 扩展性测试 ​

java
/**
 * 扩展性测试
 */
public class ScalabilityTest {
    
    /**
     * 负载测试
     */
    public static class LoadTest {
        
        public LoadTestResult test(int users) {
            // 模拟不同用户量
            // 测试 TPS、响应时间、资源使用率
            
            return new LoadTestResult(
                tps: measureTPS(users),
                latency: measureLatency(users),
                cpu: measureCPU(),
                memory: measureMemory(),
                db: measureDB()
            );
        }
        
        public void analyzeResults() {
            // 分析瓶颈
            // 找出系统上限
            // 给出扩容建议
        }
    }
    
    /**
     * 压力测试
     */
    public static class StressTest {
        
        public StressTestResult stressTest() {
            // 逐步增加负载
            // 找到系统崩溃点
            // 评估系统韧性
            return null;
        }
    }
    
    /**
     * 容量规划
     */
    public static class CapacityPlanning {
        
        public ScaleRecommendation plan(int targetUsers) {
            // 根据目标用户量
            // 估算所需服务器数量
            // 给出扩容方案
            return null;
        }
    }
}

五、常见扩展性问题 ​

5.1 数据库扩展 ​

java
/**
 * 数据库扩展策略
 */
public class DatabaseScaling {
    
    /**
     * 读写分离
     */
    public static class ReadWriteSplitting {
        
        public void handleRead() {
            // 读操作路由到从库
            // 写操作路由到主库
        }
    }
    
    /**
     * 分库分表
     */
    public static class Sharding {
        
        public int calculateShard(String userId) {
            // 根据 userId 哈希到不同分片
            return Math.abs(userId.hashCode() % 8);
        }
    }
    
    /**
     * 冷热分离
     */
    public static class HotColdSeparation {
        
        public void storeData(Object data, boolean isHot) {
            if (isHot) {
                // 热点数据存储到 SSD/内存
                hotStorage.save(data);
            } else {
                // 冷数据归档到低成本存储
                coldStorage.archive(data);
            }
        }
    }
}

5.2 缓存扩展 ​

java
/**
 * 缓存扩展策略
 */
public class CacheScaling {
    
    /**
     * Redis Cluster
     */
    public static class RedisCluster {
        
        public String get(String key) {
            // 计算槽位
            int slot = CRC16(key) % 16384;
            
            // 路由到对应节点
            return nodes.get(slot).get(key);
        }
    }
    
    /**
     * 多级缓存
     */
    public static class MultiLevelCache {
        
        public String get(String key) {
            // L1: 本地缓存（Caffeine）
            String result = l1Cache.get(key);
            if (result != null) {
                return result;
            }
            
            // L2: Redis 缓存
            result = redis.get(key);
            if (result != null) {
                l1Cache.put(key, result);
                return result;
            }
            
            // L3: 数据库
            result = db.get(key);
            redis.put(key, result);
            l1Cache.put(key, result);
            
            return result;
        }
    }
}

六、面试追问方向 ​

问题一：「如何判断系统是否需要重构？」 ​

回答思路：

1. 性能指标恶化
   - 响应时间 P99 持续增长
   - 资源利用率异常

2. 开发效率下降
   - 新功能开发周期变长
   - Bug 修复越来越难

3. 团队协作困难
   - 代码合并冲突频繁
   - 部署频率下降

4. 成本失控
   - 硬件成本增长远超业务增长

问题二：「如何设计一个高扩展性的系统？」 ​

回答思路：

1. 无状态设计
   - 会话存储到 Redis
   - 配置外部化
   - 服务无本地状态

2. 服务拆分
   - 按业务边界拆分
   - 按团队边界拆分
   - 保持服务内聚

3. 异步通信
   - 事件驱动
   - 消息队列解耦

4. 可观测性
   - 完善的监控
   - 日志聚合
   - 链路追踪

问题三：「如何平衡扩展性和复杂度？」 ​

回答思路：

扩展性不是越高越好！

原则：
- 满足当前需求 + 预留扩展空间
- 不要过度设计
- YAGNI（You Aren't Gonna Need It）

权衡：
- 3 个人维护 3 个微服务 → 可以
- 3 个人维护 30 个微服务 → 灾难

建议：
- 早期用单体，成长后再拆分
- 用模块化设计延缓拆分
- 微服务是手段，不是目标

七、总结 ​

┌─────────────────────────────────────────────────────────┐
│                   扩展性设计原则                             │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  设计原则                                              │
│  ├── 无状态设计                                        │
│  ├── 服务拆分                                          │
│  ├── 异步通信                                         │
│  └── 可观测性                                         │
│                                                         │
│  扩展策略                                              │
│  ├── 水平扩展 vs 垂直扩展                             │
│  ├── 读写分离                                         │
│  ├── 分库分表                                         │
│  └── 缓存策略                                         │
│                                                         │
│  评估维度                                              │
│  ├── 用户量扩展                                       │
│  ├── 数据量扩展                                       │
│  ├── 功能扩展                                         │
│  └── 团队扩展                                         │
│                                                         │
└─────────────────────────────────────────────────────────┘

"好的架构不是设计出来的，而是演化出来的。扩展性的本质是：让变化的部分尽可能少，让不变的部分尽可能稳定。"

基于 VitePress 构建

Copyright © 2025-2026 Guide