2、可扩展系统的架构设计与权衡

可扩展系统的架构设计与权衡

1. 可扩展性与成本

1.1 可扩展性示例

假设我们有一个基于Web的系统，能够以1秒的平均响应时间处理100个并发请求。现在业务要求将系统扩展到能以相同的响应时间处理1000个并发请求。在未做任何更改的情况下进行简单负载测试，结果显示随着请求负载增加，平均响应时间会稳步增长到10秒，显然当前部署配置无法满足需求，系统不具备可扩展性。
经过一些工程努力后，系统能够以指定的响应时间处理1000个并发请求，成功实现了扩展。

1.2 扩展的成本与挑战

扩展系统并非总是容易的，以下是一些可能遇到的情况：
1. 数据库响应问题 ：每秒1000个请求时，数据库响应变慢，需要升级到新机器。
2. Web服务器性能问题 ：Web服务器动态生成大量内容，在负载下响应时间减少，可通过修改代码更高效地生成内容来解决。
3. 数据库热点问题 ：大量请求同时访问和更新相同记录，导致数据库出现热点，需要重新设计数据库架构、重新加载数据，并修改数据访问层代码。
4. Web服务器框架问题 ：所选的Web服务器框架强调开发便捷性而非可扩展性，代码无法扩展以满足负载需求，可能需要完全重写，甚至更换框架或编程语言。

不同的扩展方案所需的资源和成本差异巨大。例如，升级数据库服务器可能需要15小时的工作和每月1000美元的额外云成本；而重写Web应用层可能需要10000小时的开发时间。如果系统在设计时没有考虑可扩展性，后续增加容量的成本和资源可能