架构设计的五大维度
架构设计需要从五个核心维度来考量系统的能力：
- 扩展性：系统如何应对业务增长
- 高性能：系统如何快速响应请求
- 高可用：系统如何保持持续可用
- 高安全：系统如何保障数据安全
- 可伸缩性：系统如何灵活扩缩容
扩展性：水平扩展与垂直扩展
当业务量增长时，单台服务器的资源总有上限。扩展架构解决的就是"系统如何应对增长"的问题。扩展分为两个方向：垂直扩展和水平扩展。
垂直扩展（Scale Up）
垂直扩展是指提升单台服务器的硬件配置——增加CPU核心数、扩大内存容量、使用更快的SSD硬盘、提升网络带宽。
优点：
- 实施简单，不需要修改架构
- 不需要处理分布式系统的复杂性
- 数据一致性问题不存在
缺点：
- 存在硬件上限（摩尔定律的物理限制）
- 成本增长是非线性的（高端硬件价格指数级增长）
- 单点故障风险依然存在
水平扩展（Scale Out）
水平扩展是指增加服务器的数量，通过负载均衡将请求分发到多台服务器上。
优点：
- 理论上可以无限扩展
- 成本可控（用普通服务器替代高端服务器）
- 单台服务器故障不影响整体服务
- 可以根据负载动态调整服务器数量
缺点：
- 需要处理分布式系统的复杂性（数据一致性、服务发现、负载均衡）
- 需要修改应用架构来支持水平扩展
- 运维复杂度显著增加
扩展方式对比
| 维度 | 垂直扩展 | 水平扩展 |
|---|---|---|
| 扩展方式 | 升级硬件配置 | 增加服务器数量 |
| 实施难度 | 低 | 高 |
| 扩展上限 | 有物理上限 | 理论上无上限 |
| 成本趋势 | 非线性增长（越高端越贵） | 线性增长 |
| 单点故障 | 有风险 | 无（服务冗余） |
| 适用场景 | 早期项目、小规模系统 | 中大型项目、高并发系统 |
| 数据一致性 | 无需额外处理 | 需要分布式方案 |
实际应用中的扩展策略
数据库扩展：
- 垂直扩展：升级数据库服务器的CPU、内存、SSD
- 水平扩展：读写分离（主从复制）、分库分表、使用数据库中间件
应用服务扩展：
- 垂直扩展：升级应用服务器的配置
- 水平扩展：增加应用服务器实例，配合负载均衡（Nginx、HAProxy、云厂商负载均衡）
缓存扩展：
- 垂直扩展：增加Redis服务器内存
- 水平扩展：Redis集群（分片 + 副本）
最佳实践：在项目初期采用垂直扩展（成本低、复杂度低），当垂直扩展达到瓶颈或成本不划算时，转向水平扩展。两者不是互斥的，而是互补的。
集群架构与分布式架构
水平扩展的实现通常采用集群架构或分布式架构，两者有关联但侧重点不同。
集群架构
集群是水平扩展最直接的实现方式，将多台服务器组合在一起，对外提供统一的服务。集群架构通常分为三类：
应用集群：多个服务器共同提供应用服务，一台故障时其他服务器接管工作，保证服务连续性。
- Unix: IBM PowerHA（自动检测故障并切换到备用服务器）
- Linux: Red Hat Cluster Suite（开源高可用集群解决方案）
中间件集群：多个中间件实例共同提供服务。
- Oracle WebLogic：企业级Java EE应用服务器集群
- IBM WebSphere：企业级Java EE应用服务器集群
数据集群：多个数据库服务器共享数据存储，提高可用性和处理能力。
- Oracle RAC：多个数据库服务器共享一个数据库
- DB2 pureScale：扩展数据库处理能力，满足大规模事务处理
- 磁盘RAID：通过数据分布和冗余机制提高磁盘I/O性能和可靠性
分布式架构
分布式架构在集群的基础上更进一步，将系统按功能或业务拆分为独立的子系统，部署在不同的服务器上。
应用层分布式：
- Docker Swarm：Docker原生的集群管理和编排工具
- Kubernetes：开源容器编排平台，自动化部署、扩展和管理容器化应用
- Apache Mesos：开源集群管理器，提供资源隔离和共享
中间件层分布式：
- Apache Kafka：流处理平台，处理和分析实时数据流
- RabbitMQ：消息队列服务器，实现应用间异步通信
- Redis Cluster：Redis分布式解决方案，提供高可用性和数据分片
数据层分布式：
- Apache Cassandra：分布式数据库，高可用性，无单点故障
- Google Cloud Spanner：全球分布式关系数据库
- Amazon DynamoDB：托管NoSQL数据库服务，无缝可扩展
分布式一致性问题
在分布式系统中，如何在多个节点之间达成一致的状态是一个核心问题。常见的分布式一致性算法：
| 算法 | 特点 |
|---|---|
| Paxos | 通过投票机制达成一致性，过程较复杂，适用于非同步和部分故障环境 |
| Raft | 为替代Paxos而设计，提供相同安全性但更容易理解和实现 |
| Zab | ZooKeeper使用的原子广播协议，用于复制状态保证所有服务器状态一致 |
| 2PC（两阶段提交） | 原子性协议，分准备和提交两阶段，协调者故障时可能阻塞 |
| 3PC（三阶段提交） | 在2PC基础上增加预提交阶段，避免协调者故障导致的系统阻塞 |
| Multi-Paxos | Paxos的变种，引入领导者节点优化性能，减少消息数量 |
↑