作者：郭欣
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
构建高性能Web站点(修订版)试读：
内容简介本书是畅销修订版，围绕如何构建高性能Web站点，从多个方面、多个角度进行了全面的阐述，几乎涵盖了Web站点性能优化的所有内容，包括数据的网络传输、服务器并发处理能力、动态网页缓存、动态网页静态化、应用层数据缓存、分布式缓存、Web服务器缓存、反向代理缓存、脚本解释速度、页面组件分离、浏览器本地缓存、浏览器并发请求、文件的分发、数据库I/O优化、数据库访问、数据库分布式设计、负载均衡、分布式文件系统、性能监控等。在这些内容中充分抓住本质并结合实践，通过通俗易懂的文字和生动有趣的配图，让读者充分并深入理解高性能架构的真相。同时，本书充分应用跨学科知识和科学分析方法，通过宽泛的视野和独特的角度，将本书的内容展现得更加透彻和富有趣味。未经许可，不得以任何方式复制或抄袭本书之部分或全部内容。版权所有，侵权必究。图书在版编目（CIP）数据构建高性能Web站点/郭欣著. —修订本. —北京：电子工业出版社，2012.6ISBN 978-7-121-17093-5Ⅰ.①构… Ⅱ.①郭… Ⅲ.①网页制作工具－程序设计 Ⅳ.①TP393.092中国版本图书馆CIP数据核字(2012)第102508号责任编辑：李 冰印 刷：北京东光印刷厂装 订：三河市皇庄路通装订厂出版发行：电子工业出版社 北京市海淀区万寿路173信箱 邮编100036开 本：787×980 1/16 印张：26 字数：608千字印 次：2012年6月第1次印刷印 数：3500册 定价：75.00元
凡所购买电子工业出版社图书有缺损问题，请向购买书店调换。若书店售缺，请与本社发行部联系，联系及邮购电话：（010）88254888。
质量投诉请发邮件至zlts@phei.com.cn，盗版侵权举报请发邮件至dbqq@phei.com.cn。
服务热线：（010）88258888。推荐评价PRAISE
本书是作者在Web系统领域多年工作、实践和探索的结晶。本书涉及Web系统优化的各个方面，从浏览器、Cache到Web、数据库和分布式文件系统等；穿插了大量的实际测试数据和很多流行开源软件的使用方法与案例；内容丰富，文字生动，对比形象。对网络系统架构师、运维和开发人员来说，这是很好的参考书；对想了解Web性能并希望动手实践的人员来说，这是由浅入深的学习书籍。——章文嵩博士，LVS作者，Linux内核作者之一
本书深入分析了常见的高性能Web技术的方法和原理，对搭建高性能Web站点具备很强的可操作性。——张松国，腾讯网技术总监
这是一个令人兴奋的领域，这一系列准则和方法在TopN的互联网公司中都有大规模的实践和应用，作者在书中进行了详细而量化的论述。如果你正在为日益庞大的应用而手足无措，那么你唯一要做的就是拥有这本书，并且实践它。——朱鑫，MemcacheDB作者，新浪网研发中心平台部高级工程师
互联网寄托着我们的梦想，它改变了人们的生活，从社交网站到网络游戏，从搜索引擎到电子商务，成功的秘诀在于如何构建高性能Web站点。郭欣在这本书中几乎涵盖了Web性能优化的所有内容，并从多个角度进行了全面的阐述，你可以通过其通俗易懂的文字深入理解高性能站点架构的真相，并开拓视野，从而对性能瓶颈对症下药。本书可谓是高性能站点的必读精作。——沈翔，Google Developer Advocate，加州总部
你很幸运能拿到这本书，更重要的是，你的网站用户也会很幸运。郭欣在这本书里深入而系统地分享了构建高性能网站技术的方方面面。从后台到前台，从网络传输到数据存储，涉及诸多技术原理和实现细节。通俗的语言，亲切的叙述，仿佛作者在耳边轻轻细语，然而又蕴涵着一种技术思想和力量，并且融合了人文思想。——王速瑜，腾讯R&D研发总监，资深技术专家
即便你是征战Web架构设计多年的高手，也能够从本书获得系统化分析Web架构性能和成本优化的完整思路，从而为工作中遇到的一些棘手的技术问题提供部分参考思路。在本书修订版出版之际，再次推荐本书，希望每一位互联网从业技术人员都能够拥有这么一本难得的精品之作，也希望国内能够出现越来越多的精品技术图书。——林水洋，新浪微博产品总监，前新浪博客高级系统架构师
作为一名写了二十年代码的有技术情结的人，深知一本好书给人带来的好处，2009年在得知此书出版后，我第一时间购买并阅读，并且给我的同事每人买了一本，希望他们都看看，得到的反馈都不错，两年过去了，高性能的定义、技术、产品也在改变，希望这本书的修订版能给更多做网站开发的技术人员们带来更多更好的帮助！——高春辉，卓越网创始人，手机之家创始人，ECSHOP软件创始人
国内具备实战指导意义的大型网站开发书籍不多，翻译版本质量又参差不齐。究其原因是我们的行业环境和国外不同，分享和开放还没有形成行业文化，多数从业者是半路出家的，他们疲于应付繁重的日常工作，难有时间和精力著书立说。很久以来一直想总结整理多年的工作经验，看了郭欣的这本书之后感觉很多内容都已经借他之笔完成了。推荐！——李嵩波，德丰杰VC合伙人，前新浪CTO
本书从前端到后台，就Web网站的性能优化深入浅出，娓娓道来，对于从事大容量高并发Web网站开发和架构设计的同行来说，是一本不可多得的好书。——魏震，淘米网CTO
作者在互联网领域实践多年，在搭建高性能Web站点方面有丰富的实战经验。书中几乎涵盖Web性能优化的所有内容，包括带宽、缓存、数据库、文件系统等各个方面，并从多个角度进行了全面的阐述。本书讲解通俗易懂、内容丰富、生动幽默，是Web站点架构师、运维和开发人员的必备佳作。——肖彬，世纪佳缘CTO
作者结合自身的经验和实践，从性能、前后端、编码、DB、监控等多个角度，非常系统地阐述了构建高性能Web站点的各个方面。难能可贵的另一个地方，是在每个不同的方案提出的同时，都附上了测试方法和数据，体现了作者非常严谨的风格。入门者参考此书，可以少走很多弯路；提高者参考此书，可以得到更多交流和思考的灵感。——郝冲，北京快网科技有限公司CTO
要成为一名优秀的Web性能架构师，需要有丰富的实战经历和持续做靠谱的总结，并最终沉淀成系统化的实战经验。如果你是一名刚入行的新人，那么恭喜你，你可以从书中获得过来人的大量实战经历，迅速开阔眼界；如果你是一名有多年经验的“老人”，同样恭喜你，你可以从书中得到更系统化的总结，以及更多的启发。——李琦，腾讯网管平台产品经理
如果你的站点采用开源软件构建，并且你正在为改善性能或准备解决架构扩展性问题而头疼，这本《构建高性能Web站点（修订版）》提供了相当全面的指导和参考信息。当然，越早阅读这本书，并能对书中提倡的一些具体建议进行实践的话，收效就会越大。——冯大辉，丁香园CTO
作为一个大型网站的架构师，性能是最关注的核心问题。本书由浅入深地讲解了Web性能的各方面，对于指导实践具有重要作用。近几年，Web的趋势朝着更实时化和社交化的方向发展，系统功能比已往更丰富，页面元素和复杂性也在持续增加，对网站的性能提出了更高的要求，希望业内同行能够更好地利用本书阐述的高性能网站构建的方法，迎接新的挑战。——杨卫华，新浪微博技术总监
看到此书时，颇有相见恨晚的感觉。作者以他广博的知识面，深入浅出的叙述方法，生动形象的类比案例，严谨负责的实践经验，给人很好的启发和借鉴。我真想说，拥有此书的读者实在是太幸福了！——陈桂新，盛大游戏技术保障中心总监，资深研究员
这本书可以让你从网络传输到缓存、数据库优化、分布式计算等方面去了解构建高性能Web站点所需要关注的每一个地方。书中引用了大量数据来说明每一个示例的实际效果，有理有据，具有很强的实践性。对于想在互联网领域大展身手的人来说，这本书值得你拥有！——潘少宁，“LAMP人”发起人精彩书评荣登China-pub计算机类图书2009年度畅销榜TOP 50！
这是第一本今年我只花一周就读完的技术书籍，并不是因为它简单，而是因为它很吸引我，很多地方讲得非常好，例如，服务器的I/O模型以及缓存使用的各个环节。非常可贵的是作者的很多测试数据是非常真实的，可以更好、定量地去看问题。——yangliang1217
很不错的一本书。由浅入深，不管你是初学还是进阶，都能有所收获。强力推荐给所有做网站的人！——gogobu
很不错的书，讲到了运维的方方面面，很有实际价值！——spark8103
少见的国内作者写出的好书，极力推荐！——stillr
这本书还真帮了我大忙，昨天工作中的问题得不到解决，随手翻了一下桌子上的书，看到有关这方面的讲解，还真解决了。很不错，实用的书。——和平的颜色
目前正在看这本书，此书内容非常不错，包括网站性能优化的方方面面，并且讲得非常细，有理有据，非常适合从事Web开发、测试、运维的相关人员学习！——eweek2@***.***修订版前言PREFACE
从我写出第一个HTML网页到现在，已经过去10年多的时间了，回顾过去的Web开发经历，我曾经尝试过各种不同的技术，与此同时，我和我的团队也犯了很多错误，但我们为此感到自豪。是的，成长是需要不断付出代价的，每次的挫折都会让我更加深刻地看到隐藏在深处的本质，为什么不把这些内容分享出来呢？于是便有了这本书。
10年来，我们见证了互联网有史以来最快速的发展，商业应用层出不穷，业务逻辑不断变复杂，对用户体验的要求也不断提升，随之而来的是应用技术和开发语言的日新月异，开发者永不停息地学习新技术。同样，在Web站点性能方面，我们一直在跟时间赛跑，社交网站和微博客成为大众的主流应用，带来了更加快速、实时的信息传递，更多的站点意识到开放的重要性，数据访问和计算无处不在，每秒数以万次的数据传递和读写正在我们身边进行。
但是，构建Web站点的基础技术几乎多年来从未改变，比如诞生于20世纪80年代的TCP，如今依旧是网络数据传输的主宰者，而HTTP则更与我们息息相关，可是你真的认真学习过它们吗？人们始终在做的事情就是在这些基础技术之上一层一层地封装概念，不断地诞生新的技术。加上商业化产品的市场竞争和炒作，.NET和Java阵营中的概念让我眼花缭乱却又无可奈何。它们已经成为营销用语，有时候过度会让事情变得更加复杂，让开发者迷失方向。
不论你是一名从事Web开发的工程师，还是一名关心Web性能的架构师，都应该更多地关注各种技术和架构的本质。
从哲学意义上讲，对本质的研究属于形而上学的范畴，但是在自然科学中，我们从来不缺乏对本质的探索，因为只有认识事物的本质才能做出正确的决策，并且真正驾驭它们，这是毫无争议的。
也许你曾经被商家的促销活动所打动。是的，我们往往只看到事物的表面现象，而经济学家却看到了事物的本质，这正是他们的高明之处。技术和架构同样如此，你要明白任何收获都是有代价的，天下没有免费的午餐，很多时候，你完全可以用成本经济学的知识来思考技术的合理性，你甚至可以像经济学家一样思考技术问题。
当然，仅仅理解本质是远远不够的，因为在庞大的架构体系中，涉及太多的部件，而影响
整体性能的因素究竟有哪些呢？你也许会感到扑朔迷离，但你必须知道瓶颈所在，并且能够意识到何时需要优化性能或者扩展规模。与此同时，系统化的分析方法至关重要，中医理论对人体的系统思辨能力体现了先哲们的智慧，在站点性能不尽如人意的时候，我们能否“对症下药”？这与你对整个系统能否全面把握有着密切的关系。
另一方面，绝对与相对、变化与平衡，是永恒的大道，在很多时候，你实际上需要考虑的是如何做出权衡，同时，我们也要铭记变化的道理，系统瓶颈不是一成不变的，久经考验的架构师深知这一点。
道可道，非常道。要将所有的架构之道讲出来实属不易，架构就像艺术品一样，往往无法完全复制，但是独立的技术以及分析的思路是可以学习的，作为优秀的开发者或者架构师，心中的架构才是最有价值的。
如果你希望寻找心中的架构，那么，从本书的第1章“绪论”开始吧！
读者群
如果你希望学习如何创建一个Web站点，那么这本书可能并不适合你，但是当你对站点
的性能开始担忧时，欢迎你的归来。
这本书适合以下读者：
编写Web应用程序、关心站点性能，并且希望自己做得更加出色的开发人员
关心性能和可用性的Web架构师
希望构建高性能Web站点的技术负责人
实施Web站点性能优化或者规模扩展的运维人员
与Web性能有关的测试人员
的确，整个技术团队的所有成员都适合阅读这本书。另外，高校学生以及个人网站站长也可以阅读，笔者希望本书可以帮助他们开拓视野。
如何阅读
本书涉及大量的软件和工具，由于篇幅有限，书中并没有对它们的具体使用方法展开详细介绍，你可以通过Google查找相关的在线手册进行自学，同时，在本书的参考文献列表中，也会提供一些相关链接。
本书不想在阐释体系上束缚读者的天分，所有内容的安排更像是引导你身处Web站点的各个角落，与影响性能的各种因素自由碰撞，并且一步步地思考和分析问题。所以，你也
许不会直接找到一个高性能Web站点的完整解决方案，但是，当你认真地依次阅读完本书的所有章节后，你也许会找到你更想要的东西，并从中获益，我衷心希望如此。
如果没有什么特殊的原因，还是建议你能够按照章节顺序，心平气和地通读一遍，因为在内容组织上，本书有太多的连贯性设计，我担心随机阅读会让你的收益大打折扣。
创作过程
说到这次写书的过程，我同样感到很有意义，各种全新的尝试让创作过程充满乐趣，它们同样值得分享。
不同于传统使用Word编写内容，我使用了快捷的Google在线文档，并使用在线表格保存测试数据，它们支持出色的版本管理，并且提供快速的分享和协作功能。当然，最激动人心的莫过于我可以在任何地点通过浏览器继续我的写作过程，甚至当灵感突如其来时打开Google G1手机便可以写上两句。
对于几十万字的篇幅，一气呵成绝对是不可能的，多次迭代必然贯穿整个写作过程，从有灵感到写提纲，再从框架到最终的文字，虽然没有完善的过程管理，但是我时刻都能感觉到敏捷的火花。
为了尽早地获得读者的反馈，我考虑尽早“部署”，于是选择了讨论组和邮件列表的方式，在Google Group上创建了读者讨论组，上传了一些试读章节，收集到了大量的修改意见和想法，这些都是我所需要的，同时也给我带来了鼓励和支持。
整个过程还有很多花絮，这里就不一一介绍了。创作的过程是艰辛的，需要作者的坚持和毅力，虽然创作本身没有捷径，但是我们可以让创作过程更加充满乐趣，让作者和读者更加近距离地接触。
关于修订版
本书第一版于2009年8月出版，当年即获得China-pub 2009年度畅销榜TOP50，在第一版发行期间经历6次印刷。时至2012年，令人欣喜的是，读者朋友们对本书的热情依旧不减，他们一直以来的支持和反馈让这本书的生命力得以延续，也让这本书有幸获得更多的新读者。为了服务更多的读者朋友们，我将读者们的反馈和评价进行整理，并与一些热心读者进行反复探讨，最终对书中内容进行了勘误修订。于是就有了你手中的这本修订版图书。已经购买过本书第1版的读者朋友们，此次不建议再次购买。
虽然没有增加太多新的内容或许令人遗憾，但另一方面，我始终认为书中的内容并不过时，至少大部分内容在2012年甚至未来10年仍有价值，因为这些内容多为设计高性能Web架构的本质，而不是应用层的各种流行技术。希望这本书可以帮助更多的读者朋友们找到心中的架构，我对此充满信心！
联系作者
在本书出版后的任何时间，我都欢迎你提出自己的意见或思想，你可以通过微博联系到我，我的微博地址是：http://weibo.com/guoxin
致谢
感谢我的父母，他们在我读初中的时候送给我第一台电脑（Cyrix 1.66G的兼容机），让我走进了计算机的世界，并且给予我非常多的支持和鼓励，让我毫无顾虑地追逐梦想。
感谢我的妻子Cris，她不仅为我创作了本书的封面，而且在整个写作过程中毫无抱怨地陪伴我，给予我无尽的支持和灵感。
感谢电子工业出版社的策划编辑李冰，她严谨认真的工作态度以及作为出版方的开放态度让我深感敬佩。
感谢为本书撰写推荐和评价的朋友们，他们是王速瑜、章文嵩、张松国、沈翔、朱鑫、肖彬、郝冲、李琦、冯大辉、杨卫华、李嵩波、陈桂新、高春辉、林水洋、魏震、潘少宁。他们在繁忙的工作中抽出时间，阅读了本书的样稿并写下了推荐和评价。特别值得一提的是，章文嵩博士对书中一些内容建议让我受益匪浅。
感谢对本书提出宝贵修改意见的朋友们，他们是蒋琦、丁吉亮、汤文亮、刘健、朱李、周伟强。
感谢在读者讨论组中所有积极阅读、并提出意见的成员。第1章 绪 论
一般而言，人们评估一个Web站点的性能如何，通常先置身于用户的角度，来访问该站点的一系列页面，体验等待时间。
当用户输入页面地址后，浏览器获得了用户希望访问该地址的意图，便向站点服务器发起一系列的请求。注意，这些请求不仅包括对页面的请求，还包括对页面中许许多多组件的请求，比如图片、层叠样式表（CSS）、脚本（JavaScript）、内嵌页面（iframe）等。接下来的一段时间，浏览器等待服务器的响应以及返回的数据。待浏览器获得所有的返回数据后，经过本地的计算和渲染，最终一幅完整的页面才呈现于用户的眼前。1.1 等待的真相
整个过程听起来好像并不复杂，也许你从来都没有考虑过在这段等待的时间里世界都发生了什么变化，也许你早已习惯了利用这段时间东张西望或者品尝零食，或者你根本没有来得及意识到这点，新的网页就已经闪亮登场。恭喜你，你很幸运！但是在这个世界上，幸运儿永远只占少数，大多数人的大脑处理速度已经让他们明显感觉到这段等待时间漫长无比，久经考验的他们可以随时身手敏捷地打开多个浏览器窗口与时间赛跑，并为此筋疲力尽。
另一方面，对于站点经营者来说，让用户等待的时间过长，也许会造成毁灭性的后果。笔者见过很多人为了享用某家特色小吃而在餐馆门口乐此不疲地排着长队，但没有听说有多少用户执著地等待着一个速度缓慢的站点而不去尝试别的站点。
在这段等待的时间里，到底发生了什么？事实上这并不简单，大概经历了以下几部分时间：
数据在网络上传输的时间。
站点服务器处理请求并生成回应数据的时间。
浏览器本地计算和渲染的时间。
数据在网络上传输的时间总的来说包括两部分，即浏览器端主机发出的请求数据经过网络到达服务器的时间，以及服务器的回应数据经过网络回到浏览器端主机的时间。这两部分时间都可以视为某一大小的数据从某主机开始发送，直到另一端主机全部接收所消耗的总
时间，我们称它为响应时间，它的决定因素主要包括发送的数据量和网络带宽。数据量容易计算，但是究竟什么是带宽呢？我们将在后续章节中详细介绍带宽的本质。
站点服务器处理请求并生成回应数据的时间主要消耗在服务器端，包括非常多的环节，我们一般用另一个指标来衡量这部分时间，即每秒处理请求数（也称吞吐率）。注意这里的吞吐率不是指单位时间内处理的数据量，而是请求数。影响服务器吞吐率的因素非常多，比如服务器的并发策略、I/O模型、I/O性能、CPU核数等，当然也包括应用程序本身的逻辑复杂度等。这些将在后续章节中详细介绍。
浏览器本地计算和渲染的时间自然消耗在浏览器端，它依赖的因素包括浏览器采用的并发策略、样式渲染方式、脚本解释器的性能、页面大小、页面组件的数量、页面组件缓存状况、页面组件域名分布以及域名DNS解析等，并且其中一些因素随着各厂商浏览器版本的不同而略有变化。这部分内容在后续章节中也会适当提到。
可见，一个页面包含了若干个请求，每个请求都或多或少地涉及以上这些过程，假如有一处关键环节稍加拖延，整体的速度便可想而知。
现在，如果有用户向你抱怨在打开站点首页的时候等待了很久，你知道究竟慢在哪里了吗？1.2 瓶颈在哪里
相信你一定知道赤壁之战，这是中国历史上一场著名的以少胜多的战役，东吴的任务是击退曹操的进攻，要完成这项任务，可谓“万事俱备，只欠东风”，这时东风便是决胜的瓶颈，所以很多系统论研究专家将其称为“东风效应”，也就是社会心理学里讲的“瓶颈效应”。
之所以称它为瓶颈，是因为尽管东吴做了很多战前准备，包括蒋干中计导致曹操错杀蔡瑁和张允、诸葛亮草船借箭、东吴苦练水军等，但是仅靠这些仍无法获得最终胜利，还需要最后的东南风才能一锤定音，完成火烧曹军战船的计划。不过之前的准备工作都是胜利的子因素，而东南风这个关键因素最终和其他子因素一起相互作用，将整个战斗的杀伤力无限放大。
曹操运气不好，遇上东南风，倒了大霉，曹军战船一片火海，这时候东吴需要派出勇猛的陆军部队登岸攻下曹营，可是东吴向来精通水战，几乎没有强大的陆战部队，只有老将黄盖，这如何与曹操的精英骑兵抗衡呢？这个时候决胜的关键因素变成了刘备的盟军支援，五虎上将各个威猛无比，身怀必杀绝技，此时正是上岸一显身手的好机会，他们不费吹灰之力就将曹军打得落花流水，试想如果没有刘备的支援，赤壁之战胜败可能就扑朔迷离了。可见，系统性能的瓶颈是指影响性能的关键因素，这个关键因素随着系统的运行又会发生不断的变化或迁移，比如，由于站点用户组成结构的多样性和习惯的差异，导致在不同时段系统的瓶颈各不相同，又如，站点在数据存储量或浏览量增长到不同级别时，系统瓶颈也会发生迁移。一旦找到真正影响系统性能的主要因素，也就是性能瓶颈，就要坚决对其进行调整或优化，因为你不得不这么做。
提示：
中医是一门关于生命的哲学，也是中国人智慧的结晶，它的光芒在于独到的思辨能力和系统性的分析方法，它认为世间万物都在不停地变化，并赋予它们阴阳状态，包括天地、季节、天气、心理、生理等，而患者的病理也在随之变化。所以，中医会对同一位患者在不同季节进行不同的诊断，找到不同的病因。
同时，在这些关键因素的背后，也存在很多不能忽略的子因素，构成了性能优化的“长尾效应”，也就是说，如果你对某个子因素背后的问题进行优化，可能会带来性能上的少许提升，也许不被察觉，但是多个子因素的优化结果也许会叠加在一起，带来性能上可观的提升。对于诸多子因素的优化，需要稍加谨慎，花点时间考虑这种优化是否值得，以及是否会带来潜在的副作用，还有其他依赖的非技术因素。
然而，不论是关键因素还是子因素，它们的背后都是影响系统性能的问题所在，问题本身并不涉及关键性，只有在不同的系统和应用场景下，才会显示出其是否关键。
本章其余部分将先列出我们经常遇到的一些问题，并简单介绍我们常用的优化方案，至于这些问题在什么时候是否关键，它们的本质是什么，以及如何调整或优化，在后续章节中将结合具体场景来详细探讨包括这些在内的更多主题，这也是本书贯穿始终的线索。1.3 增加带宽
当Web站点的网页或组件的下载速度变慢时，一些架构师可能想到的最省事的办法就是增加服务器带宽，因为他们认为是服务器带宽不够用了，对于一些以提供下载服务为主的站点来说也许是这样的，但是对于其他服务的站点，你知道站点当前究竟使用了多少带宽吗？这些带宽都用到哪里了呢？如何计算站点现在和可预见未来使用的带宽？带宽增加后下载速度就可以加快吗？使用独享带宽和共享带宽的本质区别是什么？如何节省带宽？还有，你可能会忍无可忍地问，究竟什么是带宽？
对于带宽的概念，如果你没有仔细阅读计算机网络教材中的描述，笔者敢肯定你一定是完全凭借自己的理解来认识它的，因为这个词实在是太有创意了，也实在太容易从字面理解了，但是这些认识从本质上讲完全是错误的，正是基于这种误解，很多人都无法完全解答
上述那一连串问题，导致在所有涉及带宽的问题上，只能依靠经验和猜想。
在后续章节中，我们将通过介绍数据的网络传输原理，彻底揭开带宽的本质，以及数据传输响应时间的依赖因素和计算方法。搞清楚这些一点都不困难，它们是一个优秀架构师必须掌握的基础知识。1.4 减少网页中的HTTP请求
我们知道，Web站点中几乎任何一个网页都包含了多个组件，每个组件都需要下载、计算或渲染，毫无疑问，这些行为都会消耗时间。那么如果可以让网页减少这些行为，应该就可以加快网页的展示速度，这是毫无疑问的，但是往往我们需要在优雅的网页表现和性能之间权衡取舍，这也许是美和快之间的博弈，找到最优的均衡点至关重要，我们为此做了很多尝试和努力：
设计更加简单的网页，使其包含较少的图片和脚本，但是这可能牺牲了美观和用户交互。
将多个图片合并为一个文件，利用CSS背景图片的偏移技术呈现在网页中，避免了多个图片的下载。
合并JavaScript脚本或者CSS样式表。
充分利用HTTP中的浏览器端Cache策略，减少重复下载。
很显然，这些技巧都来自Web网页前端的优化，在后续章节中我们会有所涉及，但是不作为本书的重点来介绍，本书将更加偏重于站点服务器端的性能改善和规模扩展。1.5 加快服务器脚本计算速度
笔者认为，大多数涉及性能问题的站点都会使用各种各样的服务器端脚本语言，比如主流的PHP、Ruby、Python、ASP.NET、JSP等，这些脚本语言用来编写动态内容或者后台运行的小程序，已经成了几乎所有站点的首选。而曾经使用C++编写动态内容的经历也让笔者记忆犹新，除了每天都在感叹C++的严谨和优雅之外，笔者找不到其他任何好处。
我们知道，用这些脚本语言编写的程序文件需要通过相应的脚本解释器进行解释后生成中间代码，然后依托在解释器的运行环境中运行。所以，生成中间代码的这部分时间又成为大家为获取性能提升而瞄准的一个目标，对于一些拥有较强商业支持的脚本语言，比如ASP.NET和JSP，均有内置的优化方案，比如解释器对某个脚本程序第一次解释的时候，将中间代码缓存起来，以供下次直接使用。对于开源类的脚本语言，也有很多第三方组件来提供此类功能，比如PHP的APC组件等。使用这些组件进行脚本优化真的那么有用吗？不同的应用效果是否有所不同呢？在后续章节会详细探讨。1.6 使用动态内容缓存
动态内容技术就像Web开发领域的一场工业革命，它带来了产业升级和Web开发者的地位提升，在过去相当长一段时间里，大家普遍认为一个站点的技术含量主要体现在后台的动态程序上，所以很多工程师都会带着虚荣心警告你：“请叫我后台开发工程师。”事实上，这种概念和偏见已经开始逐渐被历史抛弃，但这不是我们此刻讨论的重点。
自动态内容技术产生后，聪明的工程师们为了减少动态内容的重复计算，想到了截取动态内容的胜利果实，将动态内容的HTML输出结果缓存起来，在随后的一段时间内，当有用户访问时便跳过重复的动态内容计算而直接输出。
在实际应用中，动态内容缓存可能是大家使用得最多的技术，但是并不见得所有的动态内容都适合使用网页缓存，缓存带来的性能提升恰恰与有些动态数据实时交互的需求形成矛盾，这是非常尴尬的，而解决该问题的唯一途径不是技术本身，而是你如何权衡。
另一方面，缓存的实现还涉及了一系列非常现实的问题，即成千上万的缓存文件如何存储？缓存的命中率如何？缓存的过期策略如何设计？在拥有多台Web服务器的分布式站点上应用动态内容缓存需要考虑什么呢？
在后续章节将详细探讨这些问题。1.7 使用数据缓存
动态内容缓存是将数据和表现整体打包，一步到位，但就像快餐店里的组合套餐一样，有时候未必完全合乎我们的口味。当我们意识到在自己的站点中，某些动态内容的计算时间其实主要消耗在一些烦人的特殊数据上，这些数据或者更新过于频繁，或者消耗大量的I/O等待时间，比如，对关系数据库中某字段的频繁更新和读取，这时我们为了提高缓存的灵活性和命中率，以及性能的要求，便开始考虑数据缓存。
更加细粒度的数据缓存避免了过期时大量相关网页的整体更新，比如很多动态内容都包含了一段公用的数据，如果我们将整个页面全部缓存，那么假如这段数据频繁更新导致频繁过期，无疑会使所有的网页都要频繁地重建缓存，这对网页的其他部分内容似乎很不公平。此时如何协调网页缓存和数据缓存呢？是否能够将它们一起使用并各显其能呢？
另外，将数据缓存存储在哪里呢？这需要考虑多方面的因素。速度是一方面，如果无法提供高速的读写访问，那么这部分数据缓存可能不久便成为新的系统瓶颈。另外，数据缓存的共享也至关重要，如同一主机上不同进程间的共享、网络上不同主机间的共享等，一旦设计不当，将对站点未来的规模扩展带来致命的威胁。
在后续章节中也会详细探讨这些问题。1.8 将动态内容静态化
在动态内容缓存技术的实现机制中，虽然避免了可观的重复计算，但是每次还都需要调用动态脚本解释器来判断缓存是否过期以及读取缓存，这似乎有些多余，而且关键是消耗了不少时间。直接让浏览器访问这些动态内容的缓存不是更好吗？在这种情况下，缓存成为直接暴露给前端的HTML网页，而整个缓存控制机制也发生了根本的变化，我们普遍称它为静态化，静态网页独立了，当家做主了，再也不用被脚本解释器呼来唤去。
独立意味着要承担更多的责任，原本动态内容缓存涉及的那些问题，在静态化实践中是否也会出现呢？让我们在后续章节中详细探讨。1.9 更换Web服务器软件
从20世纪末开始影响全球经济的开源软件，不可否认给我们的生活带来了更多丰富的体验和选择，但是更多的选择也代表着更多的结局，不论结局是好是坏，我们都需要为此承担责任。
在Web服务器软件的选择问题上，很多架构师依然很困惑，大量的压力测试对比数据蛊惑着激进的开发者和运维工程师，人们只关注所谓的并发量冠军，却忽视了更加本质性的东西，甚至不了解眼前测试数据的潜在前提。社会总是这样的，象牙塔式的精英教育和残酷的淘汰机制断送了无数人才的未来。而这一次，错误的选择将要付出沉痛的代价。有人拿着所谓的测试数据说Apache已经过时，你相信吗？也许下此结论为时尚早，尽管放弃它的人比比皆是，但是它的成功不是空穴来风，毕竟它已经活了很久了。
另一方面，你正在使用的Web服务器软件也许让你无比自豪，可是你知道那些复杂的参数配置背后的本质吗？你知道为什么它仅仅在处理你的站点请求时如此出色吗？如果让你自己编写Web服务器软件，你可以让它更快一些吗？
我们必须停止盲目的选择，停止对表面现象的崇拜，我们需要学习一些稍显底层的知识来武装自己。在后续章节中，我们将介绍Web服务器在并发策略方面的各种设计及其动机和本质，熟悉这些内容后，相信你可以解释和分析更多你所看到的现象。1.10 页面组件分离
从某种角度看，中学校园里的快慢分班似乎合乎逻辑，虽然不一定合乎情理。快班的学生学习能力强，理解知识快，那么课程安排的节奏可以加快一些；慢班的学生则可以放缓课程安排的节奏，这样既互不影响，学校的升学率又可以得到保证，当然，假设的前提是学生之间互相帮助的效果不大。
在Web站点中，网页和各种各样的组件是否也需要“分班”呢？显然，它们的下载量和对服务器的能力要求不尽相同，如果由同一台物理服务器或者同一种并发策略的Web服务器软件来统一提供服务，那势必造成计算资源的浪费以及并发策略的低效。所以，分离带来的好处是显而易见的，那就是可以根据不同组件的需求，比如下载量、文件大小、对服务器各种资源的需求等，有针对性地采用不同的并发策略，并且提供最佳的物理资源。当然，如果你的站点基本无人问津，而且服务器的各种资源大量闲置，那么自然不存在什么性能问题，也不需要什么组件分离。但是如果你的站点负载已经让你意识到组件分离是大势所趋，那还是趁早动手。
那么，什么组件需要分离？如何分离？幸运的是，这些并不困难，但是其涉及的知识绝对不仅仅是组件分离本身，在后续章节中将会详细探讨。1.11 合理部署服务器
真让人发疯，互联网为什么不是只有一个？你也许会说难道不是只有一个Internet吗？是的，但是Internet所特指的“互联网”是某种文化意义上的名词，同一个世界，同一个梦想，同一个互联网。而本书说的互联网，则是指由某互联网运营商负责搭建的一系列网络节点，它覆盖的地域有大有小，接入这些网络节点的局域网也可以相互通信，同时这些互联网之间也能够通过骨干线路互联互通。
世界上很多国家都有不止一个互联网运营商，中国的互联网运营商想必大家都非常熟悉，当你在家中安装宽带或者需要托管服务器的时候，都面临着运营商选择的问题，包括电信、网通、铁通、移动在内的几大国内运营商让你很头疼。特别是在部署Web站点各类服务器的时候，是否能够找到合理的位置部署服务器至关重要。
我们都知道，在基于IP寻址的互联网中，IP地址相近的主机之间通信，数据经过少数的路由器即可到达，比如，同一局域网内通信或者接入同一个城市交换节点的局域网之间通信，在这种情况下，数据到达时间相对较短。
而如果通信的两端主机位于不同运营商的互联网中，那么数据必须流经两个互联网运营商的顶级交换节点和骨干线路，可想而知，在这个过程中的数据要经过更多次的存储转发，而且各互联网顶级交换节点之间又存在出口带宽的限制，如果互联网之间数据通信量比较大的话，那么这个顶级交换节点也就是“出口”，将会是瓶颈所在，就像连接两座城市之间的高速公路，当大量汽车需要频繁地往返于两座城市时，高速公路出现车流缓慢，那么汽车从一个城市到另一个城市的总时间加长了。
显而易见，我们当然希望Web站点的用户和服务器位于同一个互联网运营商的网络内，但如何实现呢？后续章节会涉及这方面的详细内容。1.12 使用负载均衡
到此为止，我们已经最大程度地发挥了单台Web服务器的处理能力，但是，当它所承受的压力达到极限时，就需要有更多的服务器来分担工作，我们需要想办法将流量合理转移到更多的服务器上。
为此，我们需要通过各种不同的方法来实现Web负载均衡，可能是简单的HTTP重定向，或者是基于DNS的轮询解析，或者通过反向代理服务器来实现负载均衡调度，还可以通过LVS来组建服务器集群，它们有什么区别呢？无论如何，通过这些具体的实现方法，我们更加关心的是能否真正地均衡调度请求，以及是否具备高可用性，还有影响规模扩展的制约因素，这些内容都会在后续章节中详细介绍。1.13 优化数据库
对于使用数据库的Web站点来说，你是否在性能优化时或多或少地忽视了数据库的存在？往往一些性能问题都发生在表现不佳的数据访问层面，这来源于不合理的应用程序数据访问组件设计、不合理的数据库表结构设计以及对于数据库内部构造缺乏深入的了解。毫不夸张地说，也许你之前的优化全都白干了。
Web服务器与数据库服务器的数据通信一般基于标准的TCP，即便它们位于同一台物理主机也是如此。其通信连接的建立和释放涉及代表一段内核高速缓冲区的文件描述符的创建和销毁，这需要不少的时间开销，包括系统调用导致的内核态切换以及某些异步阻塞I/O模型采用的文件描述符队列扫描机制。所以，频繁的数据库连接和释放无疑将导致数据访问等待时间的加长，这段时间浪费得毫无意义。
使用数据库持久连接有效地解决了这一难题，它包括不同程度上的持久化，本质的区别在于持久连接的应用范围和生命周期，比如某个进程内部的全局数据库连接，供进程内所有计算任务共享，在这个进程终止后便被释放；或者在某个动态内容的执行周期内，代码层面的持久连接对象，在动态内容计算结束后便不复存在；还有跨进程的数据库连接池，保存多个持久连接供应用程序重复使用。在这些采用数据库持久连接的应用设计中，同时还要注意保证数据访问的线程安全性。
与此同时，在设计关系数据库的表结构时，你是否合理使用了各种类型的索引呢？要做到这一点，你必须了解索引的有关知识，然而更重要的是如何根据Web站点变幻莫测的数据访问特点来有针对性地设计每个表的索引，这往往也是最有难度的，索引的合理使用对于依赖数据库访问的Web应用至关重要。
另外，你了解数据库存储引擎的特性吗？其实这并不困难，因为所有的主流数据库文档中都有详细介绍，但是究竟你的Web站点应该选择什么存储引擎呢？当然，没有绝对完美的方案，我们在这个世界上要做的唯一的事情就是不断进行取舍，像考虑索引一样去弄清楚存储引擎的本质，是绝对不会让你失望的。
随着时间的推移，你的Web站点可能逐渐被数据库绑架，单台数据库服务器再也无法应付整个站点的需要，这包括存储空间以及查询时间，人们开始抱怨数据库模型的不良设计制约了横向扩展以及负载均衡，这不是我们希望看到的结果。为此，我们将数据散列在多台主机，包括必要的冗余数据，以此来合理地分散数据库的密集访问，数据库扩展便成为我们考虑的方案。1.14 考虑可扩展性
对于前面列举的诸多方案，本书不仅从其对性能影响的角度来深入探讨，还会适当地涉及开发、调试以及可扩展性。对于Web站点的可扩展性讨论已经屡见不鲜了，不论是代码层面的扩展，还是架构层面的扩展，涉及的内容非常多，究竟我们应该从何谈起呢？这是一个值得深思的问题。缺乏良好的可扩展性设计就像慢性自杀或者等待死亡，这甚至比Web站点所能遇到的其他一切困难更让人头疼，因为扩展对我们来说，就像在山穷水尽的时候被指引了一条星光大道，一旦扩展都无法进行，那真是死路一条。
的确，可扩展性并不是性能和速度的概念，它是指当系统负载增大时，通过增加资源来提高性能的能力。高性能往往需要通过这种能力来实现快速扩展，几乎没有多少团队可以在一个星期内通过增加服务器马上让服务能力扩容100倍。另一方面，可扩展性的目的在于适应负载的变化，从扩展的技术实现上来看，又包含了很多对局部性能的思考，以及了解何时需要扩展，这离不开对站点性能的把握。
然而，就像“人的病都是吃出来的”一样，Web站点在成长的道路上不断吸收新的技术，但每一次技术的应用不当都可能引入一定程度上的不可扩展。现实往往是矛盾的，我们不得不使用一些技术来构建Web站点，同时又使用一些技术来提升站点性能，这些技术构成了我们理想架构的一部分，关键在于在这些技术和架构的应用中，我们是否意识到可扩展性，并且能否正确评估可扩展性的需求。
在本书后续的内容中，我们不打算用一个独立的章节来探讨可扩展性问题，而是将其渗透在所有需要考虑可扩展性的章节中，因为这样的组织方式可能更加适合读者阅读。1.15 减少视觉等待
实在不行就给用户一些提示吧！最后笔者只能这么说了，事实上，这不是什么大不了的事情，即使认识到架构的瓶颈并投入大量人力来改善，也不是一天两天就可以完成的，要意识到用户也许只是希望你不要不理他而已。
这部分显然已经超出了本书的讨论范围，它涉及人机交互的相关知识，并且充满着人文情怀，要真正做好它，恐怕要比本书中所有的问题都更有难度和挑战性，这毫不夸张，我们要承认这个现实，因为世界上最难的学问就是研究人，你觉得呢？第2章 数据的网络传输
事实上，围绕本书的一切内容都离不开网络，这是无可置疑的，站点需要通过网络来响应用户的请求，站点内部也需要通过网络来组建分布式环境。那么，你了解数据在网络传输中的一些原理和动机吗？比如存储转发、流量控制、带宽和响应时间等，通常它们看似顺理成章，因为大多数开发者生活在应用层，这些似乎与他们毫无关系，然而一旦当你开始将注意力转向站点性能时，这些基础知识便是你不能不知道的。2.1 分层网络模型
关于网络模型的阐述，许多参考书中都有涉及，普遍采用OSI七层网络模型或TCP四层网络模型展开介绍，所以在这里我们不打算重复罗列这些内容，而是希望探讨网络模型中一些细节的本质和实现，尤其是数据传输比较低层的实现，包括分组交换、流量控制、数据转发等，以便对大家理解本书后续章节有所帮助。
如果你觉得已经非常熟悉网络模型的细节，并且不需要再加深理解，可以直接跳过本节，并在任何需要的时候回到这一章。如果你希望先温习一下所谓的OSI七层网络模型或TCP四层网络模型，可以查阅丰富的在线资料。
我想用另一种描述方式带大家回顾一下网络模型，通过假想的场景来透视网络模型的设计动机以及在理想场景下的实现。为此，故事从一个遥远的星球开始，讲述他们的铁路体系从无到有的过程，请注意，这是一个理想的场景，所以请大家先将脑海中关于现实中铁路系统的认识屏蔽，一个虚幻的铁路系统即将诞生。
这个故事也许看起来比较复杂，或许你可以把它当做小说一样阅读，但一定是推理小说，因为你要动脑筋搞清楚故事中提到的所有角色。请再次注意，一定要把心平静下来，同时，在没有搞清楚故事中某些内容和真实网络模型的对应关系之前，请不要习惯性地对号入座，否则可能会给你的理解带来一些不必要的认知偏差。
发展铁路运输
话说在遥远的星球上，有一座美丽的城市，市民们过着简单而快乐的生活。随着市场经济的蓬勃发展，城市的货物运输需求越来越大，市民们迫切希望能够将货物快速运输到城市
的各个角落。于是市政厅决定修建城市铁路，大力发展铁路运输，并将这个艰巨的任务交给了新设立的铁路公司。
铁路公司对于修建铁路没有任何经验，只是听说地球上有发达的铁路，但了解不多。幸好城市里少数学者去过地球，带回了一些宝贵的资料和照片，于是铁路公司召集星球上的专家和工程师，展开了紧张的研究工作。
凭借着大家的智慧，不久之后，研究工作有了突破性的进展。大家掌握了修建铁路的方法，同时意识到另一个更加重要的问题，那就是在铁路上如何运输货物，这需要设计能够在铁路上行驶的火车。经过一段时间的研究，设计火车的工作并没有难倒大家，科学家们利用本星球的特殊材料，结合之前的铁路，设计出了能够高速行驶的火车。
接下来，大家又遇到了新的问题，如何铺设铁路呢？如何使火车根据运输的需要寻找到正确的目的地呢？如何知道火车是否正确到达目的地呢？如何处理中途遇到故障的火车呢？这一系列的问题立刻让大家意识到，必须要设计出一套强大的铁路运营体系，否则这一切都将只是破铜烂铁。其实在一开始，有一位聪明的工程师就意识到了这个问题，于是他一直在默默地研究，终于在此时拿出了他认为成熟的方案，让我们一起来听听他的想法。
铺设铁路
首先，在城市里修建多个火车站，作为火车的出发地或目的地。每个火车站拥有自己唯一的地址，比如“STATION-23-EF-59-32-AD-B9”，看起来很酷，这是火车唯一能识别的地址格式。
接下来，需要铺设铁路连接这些火车站，有以下两种方法：
铺设一条铁路将所有火车站串联起来，所有火车都行驶在这条铁路上。
在城市中心位置修建一座强大的调度站，所有火车站都与调度站之间铺设铁路相连，任何火车站之间行驶的火车必须经过调度站。
由于第1种方法实施起来比较简单，所以大家一致决定采用它，修建一条铁路连接所有火车站。可以肯定的是，火车只要知道该城市内目的地火车站的地址，就一定会知道如何到达。
预约线路
接着，需要规定如何运输货物。这时候，一位曾经设计了本星球电话网络的专家发言了，他给出了运输货物的方法。当有人需要运输货物的时候，应提前向铁路公司预约线路，也就是需要由铁路公司将运输路线所涉及的所有铁路做好准备，租给这个人来使用。铁路公司准备好之后，只可以由这个人使用此段铁路来运输货物，并且根据占用时间来缴纳一定的费用给铁路公司。当这个人完成所有的运输任务后，告知铁路公司并进行结算，同时铁路公司可以将空闲出来的铁路租给其他人使用。
货物包
工程师提出了反对意见，他认为在某个人租用铁路的这段时间内，不一定一直有火车在运输，也许货物运输有一定的时间间隔，但是该线路以及两边的火车站一直在被此人占用，无法给其他人提供及时的运输服务。尽管铁路公司按照时间收费，似乎没有少赚钱，但是在很多时间里铁路空闲着非常浪费，降低了铁路的利用率。
为了使铁路更加适用于为广大市民提供及时的运输服务，经过大家的讨论，决定使用一种新的货物运输方式，将大家的货物分成若干份，分别装入不同的货物包，每个货物包装进一个小型火车单独运输，同时一定要在火车头上写出目的地火车站的地址。这样大家就不需要预约线路，而是有货即发，并且当发货人数较多时也不需要等待太长时间，可以让每个人的货物包穿插在一起依次发出。
一切看起来都完美极了，大家决定按照这个方案开始修建铁路和火车站并投入试运营。在试运营的几天里，大家发现一系列问题，不得不先暂停了运输服务，开始了新的讨论。
调度站
首先，大家发现目前采用的铁路铺设方法使得铁路利用率非常低，因为在一条连接所有城市的铁路上，每列火车的目的地多有不同，为了避免火车相撞，在任何时刻，必须只允许某两个火车站之间行驶火车，而其他火车站则必须等待发车。
于是，大家开始考虑当时提出的第2种铁路铺设方式，在城市中心位置修建一座强大的调度站，然后所有火车站都与调度站之间铺设铁路相连，任何火车站之间行驶的火车必须经过调度站。调度站设有工作人员，将驶入调度站的火车根据火车头上的目的地火车站地址，调度至连接该火车站的正确线路。同时，工程师们还改进技术，设计出了更加强大的高级调度站，可以将从不同火车站同时驶入调度站的火车进行同时调度，互不影响，这一项技术改进使得铁路的利用率大大提升。
车流控制
接下来的问题是，火车站在为火车装货和卸货的时候需要一定的时间，而且时间可能不相
同，这往往取决于目的地火车站货物临时库房的大小以及搬运速度。如果货物临时库房太小或者进入库房的速度太快的话，还没将货物转给收货人，临时库房就满了，新的货物无法进入仓库，便容易发生丢失。也就是说，如果目的地火车站的卸货速度比出发地火车站的装货速度慢，那么按照出发地火车站的装货速度发出的火车到达目的地火车站后，便容易发生货物丢失，这种情况非常严重，必须避免发生。
为此，聪明的工程师认为，必须要通过某种反馈机制，让出发地火车站实时了解目的地火车站的卸货速度，从而不断调整发车速度，比如某目的地火车站1小时能完成10列火车的卸货任务，则出发地火车站在1小时内不能发出超过10列火车。那么如何实现这种反馈机制呢？
在场有位工程师提出，当一列火车到达目的地火车站并且成功地完成卸货后，目的地火车站必须通知出发地火车站，而且出发地火车站必须等待该通知后，才可以发出下一列火车，这样就不会发生之前的问题了。
但是，另一位工程师认为这种机制虽然实施起来简单，但是很明显可以看出，从出发地火车站发出一列火车到目的地火车站发送通知的这段时间内，出发地火车站无法继续发车，由于火车行驶也需要时间，导致卸货员有一部分时间处在等待状态，所以发车速度反而低于卸货速度，这大大降低了铁路的利用率。
这位工程师提出了改进方案，让出发地火车站连续发出多列火车，但是数量有限，这些火车恰好能将这段铁路利用起来，同时也等待目的地火车站的通知，当目的地火车站到达一列火车并且卸货完成后，通知出发地火车站，这时出发地火车站再发出一列火车。这样的话，两个火车站之间的铁路全线不会闲置。大家很赞同这种方法，同时还决定成立技术小组长期致力于提高卸货速度的研究。
货物重发
另一个问题是，货物在运输过程中有可能会被损坏，比如由于路况问题或者环境问题，以及恐怖主义袭击等原因，大家觉得铁路公司应该保证所有货物都能准确到达目的地，并对这些货物的完整性负责。于是在每次发货的时候，应详细清点货物，并将清单贴在火车尾部，目的地火车站卸货后要根据清单检查货物，如果发现货物损坏，必须通知出发地火车站重新发送。这就要求出发地火车站在每种货物发送之前，将其复制一份，放在库房里，一旦得知货物损坏后，就进行货物重发。
其实，在后来的实际运营中，铁路公司认为由自己来进行货物重发，过程相当复杂，而且还涉及很多细节问题需要处理，比如重复发货带来的货物到达顺序不同等，同时需要花费大量的时间和资金成本。另一方面，实际在运输途中损坏货物的情况并没有想象的那么多。所以铁路公司决定对于损坏的货物不进行直接重发，而是由收件人根据损坏情况决定如何处理，包括要求铁路公司重新发货或者赔偿等。
跨城运输
以上的问题解决后，这座城市的铁路运输就可以有条不紊地进行了。过了不久，铁路公司似乎想到了些什么，所有专家和工程师被聚集在一起，开始考虑一个新的问题，如何将这座城市的铁路系统推广到星球上的其他城市，并且不同城市的火车站之间也可以运输货物。
将铁路系统推广到其他城市比较容易，只要派专家和工程师去其他城市建设一套一模一样的系统即可。但是要让这些城市的火车站可以相互运输货物，目前还无法解决，这包括以下几个问题：
如何铺设铁路连接不同城市的各火车站？
火车如何知道目的地火车站的地址是本城市的还是其他城市的？
如果目的地是其他城市的火车站，火车如何到达呢？前面曾经提到，火车只要知道该城市内目的地火车站的地址，就一定会知道如何到达，但对于其他城市可不行。
工程师们希望能够在不推翻当前整个系统的情况下，设计出一套方案来解决以上几个问题，这套方案必须包括以下内容：
设计城市之间的互联方式，以实现所有城市的任意火车站可以相通。
设计良好的寻址方式，以实现火车在跨城市行驶时可以找到正确的目的地。
城市互联
这时，一位工程师提出城市中转站的概念，他提议在每座城市选一个火车站，作为该城市的对外中转站，这样的话，当火车需要从一个城市进入另一个城市时，就可以通过中转站到达。
关于中转站的铁路连接，根据情况有不同的方式，比如多个小城市的中转站可以同时连接到附近一个大城市的调度站。另一方面，需要对中转站进行扩建，它的卸货速度要比其他火车站快很多，以避免来自城内多个火车站的火车同时出城造成的中转站拥挤现象，导致货物丢失。
火车站名称
有了以上的城市互联方案后，接下来要解决的问题是如何让火车可以准确地找到不同城市的目的地，这就需要在火车站地址中增加关于城市的描述，而目前的火车站地址格式无法实现这部分扩展。
工程师们意识到必须设计出一套新的火车站命名方案，并且能与现有的铁路系统很好地协作运转。新命名方案必须满足以下条件：
可以被火车直接或间接识别。
包含火车站地址。
包含城市信息。
这时，一位一直沉默不语的可用性研究专家终于开口了，他说出了埋藏在心里很久的想法，从一开始，他就觉得那串火车站地址看起来真是太丑陋了，而且难以记忆，让市民们发货的时候填写这个地址很不人性化，应该趁这次机会给火车站取个优雅的名字。
聪明的工程师仔细考虑后给出了自己的方案：由每个城市的市民来为城内所有火车站命名，但不能重复，然后在火车站的名字前追加该城市的名字，作为火车站的名称。比如：
太空城 . 和平站
到目前为止，火车站的标识有以下两种，大家不要搞混。
地址：由铁路公司给火车站起的名字，火车可以识别。
名称：由市民们给火车站起的名字，火车无法识别。
有了火车站名称后，在发货的时候，要求发货人在自己的货物包上贴一个标签，写上目的地火车站的名称，在装货的时候，由出发地火车站负责将其转换为火车可以识别的目的地火车站地址，并标注在
试读结束[说明：试读内容隐藏了图片]