知识卡片
Rackspace三代架构演变
内容
Rackspace为支持技术人员查询邮件日志，先后构建了三代功能相同但架构完全不同的系统：本地脚本grep查询、中央关系数据库、分布式文件系统+Hadoop并行索引。三代系统证明了架构与功能正交——同样的查询功能可以用完全不同的结构实现，选择哪种取决于团队愿意在可修改性、可伸缩性、延迟之间做何种取舍，而不是功能需求本身决定架构。
结构图：
flowchart LR
V1["版本1：本地日志文件<br/>SSH+grep逐台查询<br/>仅工程师可用，随规模增长开销明显"] --> V2["版本2：中央数据库<br/>日志汇总入关系库，Web界面查询<br/>单机数据库成瓶颈，模糊查询被禁用"]
V2 --> V3["版本3：索引簇<br/>Hadoop分布式存储+并行索引<br/>可伸缩性大幅提升，但查询延迟约15分钟"]
参考来源
- 位置：《恰如其分的软件架构》第1章《概述》1.2-1.3节《软件架构的三个案例》《反思》（源文件：_epub-src/OEBPS/text00006.html, text00007.html）
- 结论依据：原文详述三代系统的具体实现方式及各自遇到的瓶颈，并在1.3节明确总结"它们的架构与功能是完全独立的"，且质量属性此消彼长（可伸缩性提升以延迟和易用性为代价）。
- 原始内容：Rackspace管理着许多托管邮件服务器……前后构建了三代系统，用于处理客户查询……它们的架构与功能是完全独立的。这意味着我们在构建系统时，应该选择最符合当前需求的架构，并在该架构的框架下实现功能。