学校或社会开设的软件设计课程极其不完整，它只谈了系统该做什么，而没有涉及系统不该做什么。系统不应该崩溃、宕机、丢失数据、侵犯隐私、损失金钱、损害公司，或者导致客户流失。 在本书中，我们会探讨为这个混乱、扭曲的真实世界架构、设计和构建软件，特别是构建分布式系统的方法。为应对那些行事疯狂、难以预测的用户，我们要做好准备。软件从发布的那一刻起就会遭受攻击，它需要抵抗台风般的快闪族、Slashdotting，抑或Fark或者Digg 上的链接。我们将仔细研究无法通过测试的软件，找到方法确保软件能经受现实世界的考验。 现今的软件设计就像20世纪90年代早期的汽车设计，完全脱离现实世界。那时候，汽车只是在凉爽舒适的实验室中设计，从模型和CAD系统看，它们都很棒。在几个巨大风扇前，曲线完美的汽车闪闪发光，轰隆着冲破层层气流。这些设计者们生活在这样平静的空间里，进行着优雅、复杂、精巧，但也脆弱、不能让人满意并且最终短命的设计。大多数的软件架构和设计也同样在纯净、与世隔绝的环境中进行。 你想拥有一辆为现实世界设计的汽车，你希望这位设计者懂得：机油要在汽车每行驶3000英里后更换；轮胎胎面磨损至1/16英寸时，性能必须与开始时一样好；在你一手拿着腌肉蛋汉堡，一手打着电话时，你保不齐就会猛踩刹车。 1.1 瞄准正确的目标 大多数软件是为研发实验室或者质量保障（QA）部门的测试人员设计的。设计与构建软件的目标是为了通过测试，比如“必须输入客户的姓和名，中间名可选择输入”。它的目的是为了能在QA的人造场景，而非真实的产品世界中使用。 当系统通过了QA这一关，我就能自信满满地说它已经能够作为产品发布了吗？仅仅通过了QA测试，并不能让我了解，系统在今后的3～10年中是否能稳定工作。它可能是软件中的丰田凯美瑞，连续运行上千个小时；也可能是雪佛兰织女星（该车的前端曾经在公司自己的测试跑道上解体）或者福特平托，会在正常的碰撞测试时发生爆炸。几天或几个星期的QA测试并不能说明未来数年会发生什么。 长久以来，制造业的产品设计者一直在追求“可制造性设计”，这种设计产品的工程方法能够保证低成本、高质量地制造产品。在此之前，产品设计者与制造者自行其是，各自为战。设计部门“隔墙”丢给生产部门的方案，竟然包含了不合格的螺钉、易混淆的零件，以及需要用现成部件定制的零件。质量低劣、制造成本高昂自然是不可避免的。 这听来熟悉吗？今天，软件业也处在这样的状态。我们总是无法按期完成新的系统，因为要不断接听电话，为已经被我们甩掉的上一个未完成项目提供技术支持。我们以为“可制造性设计”就是“为生产而设计”，但其实我们不是为制造者设计软件，而是要将完成的软件交付IT运营部门。我们需要设计出一个个独立的软件系统，以及相互依赖的多个系统所构成的整个生态系统，以此带来低成本和高质量的IT运营。