《实用负载均衡技术：网站性能优化攻略（完美应对云环境及大数据的挑战）》 - [英]门伯里 - 人民邮电出版社 - 香港大書城

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台(0)　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2023年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』实用负载均衡技术：网站性能优化攻略（完美应对云环境及大数据的挑战）

書城自編碼： 2066732
分類：簡體書→大陸圖書→計算機/網絡→網絡與數據通信
作者： [英]门伯里
國際書號(ISBN)： 9787115314635
出版社：人民邮电出版社
出版日期： 2013-05-01
版次： 1 印次： 1
頁數/字數： 221/341000
書度/開本：大16开釘裝：平装

售價：HK$ 145.8

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《南方谈话：邓小平在1992 》
售價：HK$ 82.8

《纷纭万端：近代中国的思想与社会》
售價：HK$ 109.8

《中国古代文体形态研究（第四版）（中华当代学术著作辑要）》
售價：HK$ 172.5

《朋党之争与北宋政治·大学问》
售價：HK$ 102.4

《甲骨文丛书·波斯的中古时代（1040-1797年）》
售價：HK$ 90.9

《以爱为名的支配》
售價：HK$ 64.4

《台风天（大吴作品，每一种生活都有被看见的意义）》
售價：HK$ 55.2

《打好你手里的牌（斯多葛主义+现代认知疗法，提升当代人的心理韧性！）》
售價：HK$ 66.1

建議一齊購買：

HK$ 205.4
《大型分布式网站架构设计与实践》

HK$ 156.4
《Nginx高性能Web服务器详解》

HK$ 156.4
《大型网站技术架构：核心原理与案例分析（最接地气的网站架构经验》

HK$ 156.4
《大规模分布式存储系统：原理解析与架构实战（阿里巴巴高级技术专》

HK$ 221.3
《构建高性能Web站点（修订版）（畅销多年，经典再现！）》

編輯推薦：

网站负载均衡架构全揭秘，完美应对云环境及大数据的挑战，网站性能优化必备指南，
从整体上来看，《实用负载均衡技术：网站性能优化攻略》是一本比较好的负载均衡入门书籍，内容也较新（已出版的几本相关英文著作都较早）。

內容簡介：

《实用负载均衡技术：网站性能优化攻略》介绍了处理负载均衡问题的相关概念和工具，说明了如何避免性能退化和服务器上的服务突然崩溃的风险，阐述了单个服务器以及可以执行cookie插入或者改善SSL吞吐量的负载均衡器，最后还探讨了云计算中的负载均衡。《实用负载均衡技术：网站性能优化攻略》适合对系统架构、性能维护感兴趣的初级、中级读者以及有经验的系统架构师和运维师。

關於作者：

Peter
Membrey是获得认证的IT专业人员，拥有15年以上使用Linux和开源方案的实战经验。他17岁就通过了RHCE（Red
Hat认证工程师）认证，成为最年轻的认证得主，还曾有幸为Red Hat工作，撰写过介绍开源方案的著作。 EelcoPlugge
本科毕业后就一直对信息安全领域很感兴趣。他曾在McAfee担任数据加密专家。现在，他在利物浦大学攻读信息安全硕士学位，并利用零散时间写书。他持有多个专业证书，并热衷于Linux、网络安全和加密数据等诸多技术方面。
David Hows
来自澳大利亚，以优异成绩毕业于信息与通信技术专业。他热衷系统性能优化和系统安全，并一直坚持在这个枯燥的领域工作。

第1章　引言　
1.1　性能问题　
1.2　解决方案　
1.3　什么是负载均衡　
1.3.1　负载均衡的前世　
1.3.2　负载均衡的今生　
1.3.3　纵向扩展　
1.3.4　横向扩展　
1.4　负载均衡的实现　
1.4.1　网络的构成　
1.4.2　缓存：网站的曲速引擎　
1.4.3　使用DNS进行负载均衡　
1.4.4　内容分发网络　
1.4.5　6P原则　
1.4.6　基础知识　
1.4.7　HTTP负载均衡　
1.4.8　对数据库进行负载均衡　
1.4.9　对网络连接进行负载均衡　
1.4.10　SSL负载均衡　
1.4.11　建立高可用性集群　
1.4.12　云平台上的负载均衡　
1.4.13　IPv6：实现和概念　
1.4.14　下一步做什么　
1.5　总结　
第2章　网站工作原理　
2.1　开始我们的旅程　
2.1.1　来自非IT背景　
2.1.2　开始浏览的过程　
2.1.3　通过DNS查找网站　
2.1.4　最终连接到服务器　
2.1.5　服务器自身　
2.1.6　连接到数据库　
2.1.7　缓存技术速览　
2.1.8　回传到客户端　
2.2　进一步了解　
2.3　网络　
2.3.1　TCP　
2.3.2　DNS　
2.3.3　速度、带宽和延迟　
2.3.4　网络连接小结　
2.4　HTML和Web　
2.4.1　HTML　
2.4.2　为什么基于文本很重要　
2.4.3　为什么链接很重要　
2.4.4　HTML小结　
2.4.5　浏览器　
2.5　Web内容　
2.5.1　静态内容　
2.5.2　动态内容　
2.5.3　创建动态内容　
2.5.4　Web内容小结　
2.6　数据库：最薄弱的环节　
2.7　总结　
第3章　内容缓存：保持低负载　
3.1　什么是缓存　
3.2　走马观花　
3.2.1　基于浏览器的缓存　
3.2.2　Web加速器　
3.2.3　Web代理　
3.2.4　透明Web代理　
3.2.5　边缘缓存　
3.2.6　平台缓存　
3.2.7　应用缓存　
3.2.8　数据库缓存　
3.2.9　仅仅是个开始……　
3.3　缓存理论：缓存为什么这么难　
3.3.1　HTTP 1.0对缓存的支持　
3.3.2　HTTP 1.1加强的缓存支持　
3.3.3　解决方案　
3.3.4　缓存不像看起来那么简单　
3.4　Web代理　
3.4.1　Squid代理服务器　
3.4.2　开始了　
3.4.3　故障排除　
3.4.4　透明代理　
3.4.5　发生了什么　
3.4.6　获得帮助　
3.4.7　Squid，代理中的瑞士军刀　
3.5　边缘缓存：Varnish　
3.5.1　默认保守缓存　
3.5.2　安装Varnish　
3.5.3　配置并运行　
3.5.4　定制Varnish　
3.6　总结　
第4章　基于DNS的负载均衡　
4.1　DNS内幕　
4.1.1　IP地址　
4.1.2　问题　
4.1.3　解决方案　
4.1.4　回退一步　
4.2　DNS详解　
4.2.1　亲自查询　
4.2.2　DNS查询进阶　
4.3　DNS缓存　
4.3.1　查询DNS缓存　
4.3.2　Linux系统上的DNS缓存　
4.3.3　实质内容　
4.4　BIND9　
4.4.1　DNS DB的头　
4.4.2　DNS数据库记录　
4.4.3　加载数据库　
4.4.4　检查配置文件　
4.4.5　常见问题　
4.4.6　测试DNS　
4.5　基于DNS的负载均衡　
4.5.1　基于DNS的负载均衡的优势　
4.5.2　基于DNS的负载均衡的问题　
4.6　总结　
第5章　内容分发网络　
5.1　选择CDN服务提供商　
5.2　开始使用Rackspace　
5.3　向CDN账户添加内容　
5.4　Rackspace云文件API　
5.4.1　将API集成到PHP中　
5.4.2　用API密钥进行认证　
5.4.3　建立连接和断开连接　
5.4.4　对容器进行操作　
5.4.5　对文件进行操作　
5.4.6　其他有用的函数　
5.5　总结　
第6章　性能和可靠性计划　
6.1　yoU MAke DInner In TiME　
6.1.1　理解　
6.1.2　决策　
6.1.3　设计与实现　
6.1.4　安装　
6.1.5　测试、维护、评估　
6.1.6　计划的重要性　
6.2　备份　
6.2.1　为什么备份如此重要　
6.2.2　前方可能有麻烦　
6.2.3　必须实现自动化　
6.2.4　战术备份　
6.2.5　战略备份　
6.2.6　增量备份与全备份　
6.2.7　一定，一定要测试恢复！　
6.3　总结　
第7章　负载均衡基础　
7.1　什么是负载均衡　
7.2　有哪些可用的计算资源　
7.2.1　处理器　
7.2.2　内存　
7.2.3　使用top命令查看CPU和RAM的性能　
7.2.4　网络　
7.2.5　存储（磁盘）　
7.3　负载均衡实战　
7.4　指导原则　
7.4.1　深入理解系统　
7.4.2　规划　
7.4.3　监测和测试　
7.5　总结　
第8章　对网站进行负载均衡　
8.1　测量Web服务器的性能　
8.2　加速Apache HTTP　
8.2.1　禁用空载模块　
8.2.2　禁用DNS查询　
8.2.3　采用压缩　
8.2.4　FollowSymLinks和SymLinksIfOwnerMatch选项　
8.3　加速nginx　
8.3.1　worker_processes和worker_cpu_affinity　
8.3.2　Gzip压缩　
8.4　对Web服务器进行负载均衡　
8.4.1　配置　
8.4.2　准备IPVS服务器　
8.4.3　准备工作服务器　
8.4.4　测试负载均衡器　
8.5　划分动态和静态内容　
8.6　总结　
第9章　对数据库进行负载均衡　
9.1　搭建MySQL Cluster　
9.1.1　安装管理程序　
9.1.2　配置管理程序　
9.1.3　准备集群数据节点　
9.1.4　安装MySQL Server和NDB守护进程　
9.1.5　配置NDB守护进程　
9.1.6　启动集群节点上的服务　
9.1.7　更新MySQL的root用户　
9.1.8　测试上述安装和配置　
9.2　实施负载均衡　
9.2.1　建立负载均衡　
9.2.2　设置负载均衡服务器　
9.2.3　设置工作服务器　
9.2.4　测试负载均衡服务器　
9.3　总结　
第10章　对网络进行负载均衡　
10.1　分担负载　
10.2　TCPIP　
10.2.1　TCP　
10.2.2　IP　
10.3　路由　
10.4　负载均衡服务器　
10.5　IPVS　
10.5.1　IPVS的调度方式　
10.5.2　在Ubuntu上安装IPVS　
10.5.3　在CentOS上安装IPVS　
10.6　IPVSADM　
10.7　扩展IPVS　
10.8　IPVS进阶　
10.8.1　修改调度算法　
10.8.2　分配权值　
10.8.3　协议与多台虚拟服务器　
10.8.4　增加IP地址　
10.9　保存设置　
10.10　总结　
第11章　对SSL进行负载均衡　
11.1　什么是SSL和TLS　
11.2　公钥密码学　
11.3　信任和数字证书认证机构　
11.4　TLS加密　
11.5　TLS负载均衡　
11.6　配置Web服务器上的SSL　
11.6.1　配置Apache服务器上的SSL　
11.6.2　配置nginx服务器上的SSL　
11.7　SSL加速　
11.7.1　在Apache上启用SSL加速　
11.7.2　在nginx上启用SSL加速　
11.8　SSL前端　
11.9　测试SSL　
11.10　进一步配置　
11.10.1　在SSL前端中启用SSL加速　
11.10.2　启用缓存　
11.10.3　指定要支持的协议　
11.10.4　指定加密方法　
11.11　LVS和SSL终结前端　
11.12　将负载均衡服务器SSL终端功能集成到同一台服务器上　
11.13　总结　
第12章　使用集群提高可用性　
12.1　高可用性　
12.2　单一故障点　
12.3　集群化　
12.4　IPVS故障恢复　
12.4.1　在Ubuntu上安装集群软件包　
12.4.2　在CentOS上安装集群软件包　
12.4.3　配置集群　
12.4.4　常见配置问题　
12.4.5　检查系统　
12.5　测试　
12.6　Web服务器细节配置　
12.6.1　Ubuntu　
12.6.2　CentOS　
12.7　高级配置选项　
12.7.1　ha.cf　
12.7.2　ldirectord.cf　
12.7.3　Web服务器　
12.8　总结　
第13章　云端负载均衡　
13.1　云计算　
13.2　虚拟化　
13.3　虚拟化资源　
13.4　管理虚拟资源　
13.4.1　平衡　
13.4.2　超量供给　
13.4.3　计划　
13.5　云的弹性　
13.6　用云服务器工作　
13.7　总结　
第14章　IPv6：影响和概念　
14.1　IPv6　
14.2　十六进制表示　
14.3　缩略表示　
14.4　IPv4地址的耗尽　
14.5　部署IPv6　
14.6　IPv6的优势　
14.7　实现　
14.8　互联网连接　
14.9　DNS　
14.10　操作系统　
14.11　网络　
14.11.1　单一网关的网络　
14.11.2　双重网络　
14.12　软件支持　
14.12.1　Apache　
14.12.2　nginx　
14.12.3　Varnish　
14.12.4　Memcached　
14.12.5　IPVS　
14.12.6　ldirectord　
14.12.7　heartbeat　
14.13　总结　
第15章　何去何从　
15.1　回顾　
15.2　监控　
15.3　安全　
15.3.1　访问控制　
15.3.2　视图　
15.3.3　常见的攻击防护　
15.4　操作系统性能　
15.4.1　自己编译　
15.4.2　裁剪　
15.4.3　高性能操作系统　
15.5　计划　
15.6　总结　
索引　

內容試閱：

"引言
互联网，尤其是万维网，为分布在世界各地的企业和个人提供了一个公平的竞争环境。你有建站或提供互联网服务的好点子吗？即使是比较前卫的点子，也能在启动资金不多的情况下以相对简易、低廉的方式实现。每个月花一点钱，你就能享受共享托管服务了，而独立主机（虚拟主机或者非虚拟主机）的价格甚至比几年前的托管主机还要便宜。
这样当然好了，可以放手去干而不必担心囊中羞涩也是一种进步。但如果你想让应用吸引更多的用户，该怎么办？如果它一炮走红，你发现手中的是下一个Facebook或者亚马逊，那时你又该怎么办？
1.1　性能问题
想象一下，你提出了下一个了不起的创意。它很棒、令人惊叹，而且今后几年里，人们会一直谈论它。你很确信自己会成为《时代》杂志的年度人物。毫无疑问，你很快就会和比尔?盖茨和马克?扎克伯格平起平坐。你的前途一片光明！
你花了几个月时间准备发布会。你进行了一遍又一遍的测试，邀请朋友和家人访问你的网站，还跑了一些beta测试。好评如潮！网站看起来很绚，用起来也很方便，每个人都很喜欢。你觉得再无改进空间了，决定立即发布。你伸手按下了那个神奇的按钮：网站上线了！然后坐下，等待属于你的赞美！
一开始，一切都还好。你得到了一些反馈，人们很满意，他们不停地拉朋友访问这个网站，因此注册用户越来越多。此时，你兴奋不已！
但好像什么地方出了问题。有人把网站链接发到Slashdot上了。瞬间，所有人都想看一下你的这个网站。服务器刚才还是每秒提供十几个页面，但现在正承受着每秒1万次页面访问的严峻考验！这完全出乎你的意料！不仅服务器并未按如此大的负载设计，而且你还注意到，数据库遭受冲击后，之前还能很快响应的请求也在变慢。一些人开始看到错误页面，一些人被提示访问超时，还有一些甚至不能看到这两个提示页面！
30分钟后，一切都完了。Slashdot报道说你的网站无法承受负载，每个人都在说这网站真烂。“一点都不稳定，”他们说，“有一半时间甚至都加载不了！”他们抱怨道：“完全是浪费时间！”还不停地发着牢骚。
这不可能！刚才都还好好的，没理由啊！所有的时间、努力和投资都付诸东流！
注意
在数不胜数的强劲需求下，slashdotted和slashdotting两词已趋于同义。Slashdot的全部能量甚至足以冲击那些规模最大、资金最雄厚的公司的网站。尽管你可能无法承受这样的冲击，但是可以让你的网站准备好，以迎接这样潜在的流量陡増，从而避免功亏一篑。对于用户来说，你的网站将更稳定、更迅捷。而如果你能有幸得到Slashdot的青睐，那你就会更胜一筹。
1.2　解决方案
好吧，这个例子有点故作声张，不过写起来还是很有趣的，而且也是基于真实案例。别忘了，WWW代表万维网，每时每刻都有无数人在使用。就算你在某一时间仅仅吸引了其中极小的一部分人，你也可以想象到那是相当多的访问者。在只有一两个人访问时，大部分网站都能正常响应，但是你有没有试过在模拟10万人访问的情况下，看一眼自己的网站？这种事情确实会发生，而且大部分时间都有人会碰到。
（Peter按：举个例子，我曾为一个在线销售各种毛绒玩具的大公司提供咨询。我不是很确定光靠卖绒毛玩具，它怎么能成长为一家大公司，但他们肯定有自己的办法！不管怎样，跟大多数行业一样，他们也有旺季和淡季。他们平均每周有2000个订单。但在特定时期，比如圣诞节或者情人节，他们的订单数就会飞涨，常常达到每天2000个！生意火爆的时候，每秒需要处理5个订单！）
但是，他们的服务器实际并不能处理那么大的负载。你可以想象，那么多的订单数意味着服务器需要生成多少网页和图片来发送给客户。每一个订单都可能代表有十几个人正在浏览网站。平常，他们的服务器处理那点负载确实没有问题，然而在高峰期，服务器就会出现问题。
结果如何？订单会丢失。浏览网页的人会发现站点响应太慢，所以他们选择放弃，转而去往其他网站。那些走完订单流程的人会在支付页面看到超时错误（我们都知道这会有多令人反感），他们也会选择放弃，然后关掉浏览器。
显而易见的解决方案是升级系统，以使其能处理如此大的负载。但他们查了价格后发现，这样一台机器比已有服务器贵出很多倍。于是，他们决定，与其买这样一台大机器，不如购买两台和现有服务器配置相似的机器，然后再采用负载均衡方案。
这个方案有很多优势。首先，相比买一台配置高出很多、能独自处理所有负载的高端服务器，再买两台配置合理的机器要划算得多。同时，这还意味着能更好地应对未来的增长，因为一般来说，两台服务器能够提供比一台服务器更多的资源。如果某台服务器挂了，他们还可以回退到只使用一台服务器的配置。这也就表示，进行网站维护时，他们可以只关闭一台服务器，而不需要关闭整个网站。
这些解决方案很常用，同时也是部署以高性能和高可靠性为关键的重要网站的有效方法。本书将会帮你快速了解相关基础知识，教你如何给网站插上高性能的翅膀。
1.3　什么是负载均衡
现在，你已经知道负载均衡能解决什么问题了，但它究竟是什么？这一术语已经存在多年。对于那些不了解Web发展的人来说，很有可能会认为负载均衡跟电力和发电厂有关。你不应嘲笑他们，因为他们的理解基本正确。而这也是你了解负载均衡的好起点！对的，没错！
1.3.1　负载均衡的前世
家庭中许多设备都要使用来自电网的电。要发电，我们就需要某种形式的发电厂。这点非常简单明了。
然而，在每天的不同时段，人们对电力的需求并不相同。早晨，当人们起床和准备上班时，这种需求非常强烈。他们会打开电热壶、烤面包机、电烤箱以及其他大功率设备。电网需要保证有足够的电力来满足每个人的需求。
但当人们开始工作时，又是什么情况呢？虽然突然用不到这么多电力了，但不能立即关掉一座发电厂。当大家都开始做早餐时，电网的负载很有可能会超过单个发电厂所能提供的负载。
幸运的是，负载均衡正好帮忙解决了这个问题。通过存储非高峰时段多余的电力，电网能够在高峰时段提供更多的电力。
那么，这跟计算世界的负载均衡有什么相似之处？它们都具有有限的资源，并且想要尽可能地充分利用这些资源。你的目标是让网站快速和稳定，要做到这点，需要将请求发送给能够处理它们的最佳机器。
1.3.2　负载均衡的今生
在计算机术语中，情况类似，人们发出的大量请求会给网站带来负载。这其实很正常，毕竟这是你创建网站的初衷，而且没有人希望自己的网站无人访问。
但当人们开始使用各自的应用访问网站，并开始给服务器增加负载时，会发生什么？这时，事情可能会变得糟糕。如果负载过高（浏览的人过多），网站可能会出现性能损失。它会逐渐变慢，而且随着用户越来越多，会变得越来越慢，直到最后完全没有反应。这当然不是你所期望的。
要解决这一问题，就需要更多的资源。可以选择购买一台配置更高的机器来替代当前的服务器（纵向扩展，scale
up），或购买另外一台普通配置的机器来和当前服务器一起搭配工作（横向扩展，scale out）。
1.3.3　纵向扩展
纵向扩展常用于应用需要更多计算能力的情况。例如数据库增长过快，导致之前的内存不够用；又如硬盘空间不足，或者数据库需要更大的计算能力和处理更多的请求。
总的来说，数据库是纵向扩展的很好实例，因为传统来看，将数据库分散到多台机器上运行会出现严重的问题。原因在于，很多在单台机器上理所当然的设计无法在多台机器上运行。比如，如何在多台机器上高效共享数据表？这是一个很难解决的问题，也正是MongoDB和CouchDB等一些新的数据库设计成以另外一种方式运行的原因。
但纵向扩展可能会非常昂贵。通常，当需求达到特定规格时，服务器的价格会突然暴增。现在的机器都有一个高规格的RAID控制器、多个企业级硬盘和一个新型处理器（看起来很神秘，实际上跟之前的处理器的表现差不多，但标价却高出很多）。如果你只需要更新某些部件，可能纵向扩展要比横向扩展便宜，但你很可能会发现，这么做并不合算。也就是说，如果需要的只是额外的几千兆RAM或更大的硬盘空间，或者只需要提高某种用途的性能，这才可能是你的最佳选择。
1.3.4　横向扩展
从这里开始，事情才会比较有意思，也才会真正揭示让你捧起本书的原因。横向扩展出现在你手里有两台或三台机器，而非单台机器时。纵向扩展的问题在于，到了某种程度，你会碰到无法逾越的限制。单台机器能容纳的计算能力和内存有限，如果你需要的不止那些，该怎么办？
很多人会跟你说，他们很羡慕你能拥有那么多用户，尽管用户之多使得单台服务器无法承受那么大的负载。不管你相信与否，这是一个很容易解决的问题。横向扩展的优势就在于，只需不断添加机器。当然，到达某种程度后，也会开始碰到存储空间和计算能力的问题，但通过横向扩展，肯定能获得比纵向扩展更大的计算能力。
除此之外，在进行横向扩展时，有了更多的机器。如果某台机器没法工作了，仍然可以用其他机器来处理负载。而纵向扩展时，如果机器没法工作了，一切都将无法运行。
横向扩展当然也有问题，而且是个大问题。假设这样的情况：对单个网站或网络应用进行操作，而目前手中有三台机器，如何对这三台机器同时进行操作，使得它们能像单台机器一样工作？负载均衡能解决这个问题！
1.4　负载均衡的实现
是的，你已经翻到第4页，而我们尚未真正讨论负载均衡。鉴于负载均衡为本书要探讨的主题，这看起来有点奇怪。但不必担心，我们马上就一探究竟。我们还会看一下缓存技术。它跟负载均衡紧密相关，可带来非常大的性能提升。
但首先，让我们回到负载均衡这个话题。如前面提到的，负载均衡的最大挑战在于如何让多台机器像单台机器一样运行。说具体点就是，如何让三台服务器在客户看起来就像是单个网站服务器？
1.4.1　网络的构成
作为旅程的第一站，我们先来看看Web各部分如何协同工作。当你点击浏览器上的“前往”按钮时，幕后是怎么工作的？本书将会深入介绍一些细节，甚至放在TCP（Transmission
Control
Protocol，传输控制协议，支撑Web的协议）层面来简要介绍。根据我们以往的经验，能开发出出色的Web应用的人，并不一定非常了解底层的细节。在现实中，这根本不算什么问题。按照互联网的设计，写出出色的软件，并不需要了解整个互联网的内部工作机制。然而，如果想让你的应用以很快的反应速度在竞争中赢得赞美，你需要更加深入地了解其各部分如何协同工作。
对这些内容没有兴趣？不必担心。如果你真的不想阅读第2章，仍然可以从本书中学到很多东西。你可以让网站运行得更快，让它们有更好的扩展性和稳定性。但是，如果你不清楚其如何实现，可能最终会重复创建有同样问题的网站。
1.4.2　缓存：网站的曲速引擎
第3章将带你了解缓存技术，并向你展示，即使是最简单的缓存技术，也能够让网站变得更快。如果没有理解副标题中的科幻引用的意思
，那我告诉你，它的意思是说，你的Web应用将会变得极其快速！
我们将以基础知识开始：让Web应用来说明哪些可以缓存，哪些不可以；为什么这点很重要；为什么在使用这种方法时要格外小心，否则就可能会缓存了不想缓存的东西。
然后，你将会了解如何进一步控制要缓存的内容以及如何缓存。尽管缓存的强大之处才刚刚开始凸显，但叫人足够吃惊的是，这一点非常容易做到。根据我们的经验，这是使用缓存技术需要付出的绝大部分成本，也是像Facebook和Twitter这样的网站使用这些技术的原因。现在，你也可以跟他们一样使用这些技术了！
让我们为此努力吧！
1.4.3　使用DNS进行负载均衡
第4章将会着重介绍最具潜力的负载均衡方法。虽然使用DNS（Domain Name
System，域名系统，互联网系统的黄页）进行的负载均衡不及使用其他技术轻巧和强大，但它是到目前为止最容易搭建的解决方案。只需几秒钟，你就可以建立起负载均衡并使其发挥作用，非常不错！
我们还会介绍一些在进行任何形式（并非只在使用DNS）的负载均衡时都可能碰到的问题。我们将会介绍一些针对这些问题的可能的解决方案，以及当你遇到的情况不同时，应该从哪里开始排查问题。
你将会了解DNS的工作方式和原理。然后，你还会了解任播DNS（any-cast DNS）。这种技术被CDN（Content
Delivery Networks，内容分发网络）采用，是跨区域负载均衡时采用的一个强大工具。
1.4.4　内容分发网络
第5章将会探讨CDN以及它们如何帮助你提升性能。你无法自建这样一个网络，但幸运的是，这样的网络已经存在，你可以对它们加以利用。
想让网站的下载内容离用户尽可能地近吗？想要提供静态资源（如图片、JavaScript和CSS文件），同时又避免给已经为高负载的服务器增加负载吗？CDN可能正是你所需要的！
我们将会介绍Rackspace
Cloud，因为他们提供的云服务给我们留下了很深刻的印象。这些原则适用于任何CDN提供商，因此你不必受限于某一家提供商。事实上，自从我们使用Rackspace
Cloud以来，他们至少已经改变过两次他们的CDN提供商，但这并未影响到开发人员和终端用户使用系统的方式。看看，这样是不是很方便？
CDN非常了不起，而且对于要在全球范围内传送内容的网站来说，其重要性日益突出。如果你在网站名称中看到 CDN
字样（下次载入Facebook的页面时，留心一下状态栏就能看到），那就说明他们使用了这种技术来大幅提升网站的性能。现在，你也可以这么做！
1.4.5　6P原则
6P原则（Proper Planning Prevents Pretty Poor
Performance，事前的适当准备，能够避免糟糕表现）之所以作为世界范围内的军人准则，是有原因的。如果你事前设定一个计划，哪怕它并不完善，相比在毫无准备的情况下奋起直追，还是有可能获得成功的。
第6章介绍了一些可以遵循的基本原则，它们能保证Web应用分层合理、便于扩展并按需增长。这里并没什么独特的技巧，只有曾经偶然遗忘原则而深陷其中的过来人给出的一些传统建议。一旦陷入困境，不耗费很大的努力和付出，就很难走出来。如果听取了这些建议（哪怕只是其中一部分），就可以一路走下去而不会触雷。
1.4.6　基础知识
在继续了解较难的负载均衡技术之前，我们会先快速介绍一些在深入研究前必须知道的重要概念。第7章篇幅很短，它只介绍了有助于理解后续章节内容的基础知识。另外，我们还会了解一些比较少见的负载均衡概念，但不会进行深入介绍。这些知识能防止你在Web上遇到提及它们的相关内容时卡壳。
1.4.7　HTTP负载均衡
真正有趣的内容从第8章开始。在这一阶段，我们假定网站负载很大，必须布署至少两台服务器才能保持运行的流畅。不用担心，我们会介绍如何做到这一点！
不过，在介绍负载均衡之前，首先讲讲如何优化单个Web服务器来获得最佳性能。我们会对比Apache（业界最常用的Web服务器）和nginx（最快、最出色的服务器之一）。nginx真的能给你的网站带来大的性能提升吗？若确实如此，什么时候用Apache，什么时候又用nginx？第8章将会解答所有这些问题。
除此之外，我们还会了解一下其他能提升性能的功能，比如启用压缩功能、在日志功能中禁用DNS查找、移除不需要的模块等。
1.4.8　对数据库进行负载均衡
一直以来，数据库是Web应用中最慢的部分。不管机器运行有多么快或是已经做了很多调试，只需跟动态生成HTML的速度一试高下，数据库都会相形见拙。
当需要更快的速度或无法忍受数据库故障（有人能忍受吗？）时，就需要建立数据库集群。这章内容介绍了如何创建MySQL集群，以及如何对其进行负载均衡。
1.4.9　对网络连接进行负载均衡
当1 GB每秒的网络带宽不够用，而你又不想再花一大笔钱来安装10 GB的网络时，这时怎么办？可以装两个1
GB的网络，然后将它们当成一个来使用！
想要冗余吗？想让吞吐能力翻倍吗？本章将逐步介绍如何让网络设施发挥最大作用，并介绍各种不同的方法来配置网络，以获得最快和最可靠的连接。
1.4.10　SSL负载均衡
安全的Web页面是电子商务和所有现代交互式Web应用的核心。现今，如果用户访问网站时，浏览器地址栏的小锁不是金色的，他们就不会再访问。问题在于，对应用服务器来说，同时处理1万个SSL连接还是有点过于密集。事实上，你可能会发现，花在处理SSL连接上的时间比花在执行应用上的时间还多。
第11章将首先概述PKI加密如何工作和为什么它如此重要（以及如此占用资源）。我们还会介绍如何生成自己的密钥（Key）和证书申请（Certificate
Request），以便能轻松地从多家证书授权机构（Certificate Authority）中的某家获取可信任证书（Trusted
Certificate）。我们还会介绍如何生成和签发自己的证书，这样就能立即开始测试而无需为可信任证书支付费用了。
然后，我们会介绍如何用nginx来搭建SSL终结前端（SSL
Termination），以及如何将负载分散到多台机器上。我们还会涉及一些安全问题和如何通过一些简单设置来提高Web应用的安全性。
1.4.11　建立高可用性集群
尽管通过负载均衡器来将负载分散开来还不错，但现在引入了一个故障单节点。如果负载均衡不工作了，就算后面有10台正常工作的服务器也无济于事：没有请求能够到达那里。
在第12章，我们将讨论一些方案，保证可通过构建集群来避免这种情况。如果一个负载均衡器出现了故障，另一个会接管负载。
1.4.12　云平台上的负载均衡
云平台将会是下一个大事件，随之而来的是，你需要应对的一系列新的挑战。第13章将会介绍云、它如何工作，以及在查看应用性能时需要知道的一些知识。我们会讨论为什么不是所有的云服务提供商都“生来平等”，以及为什么对某个网站凑效的方案却并不适合另一个网站。
1.4.13　IPv6：实现和概念
Web主要基于IPv4，但不幸的是，我们已经快用尽了可用的IP地址。有些人可能会说，IPv4地址空间已经耗竭。而IPv6就是替代方案，并且已被推广到了全世界。IPv6如何工作？它会对你产生什么影响？通过本章，你会了解到IPv6成为主流后的一些好处和可能需要处理的问题。对许多用户来说，IPv6跟IPv4没有太大或太明显的区别，但仍有一些细节需要注意，尤其是在本书一直讨论的应用当中。本章会帮你快速将在其他章节中所学的知识应用到IPv6的世界中。
1.4.14　下一步做什么
有了本书介绍的知识，你就可以大幅提升Web应用的性能了。但是，Web并非一成不变。一切也都在不断地改变。第14章将介绍一些有趣的知识，你或许应该予以关注。
1.5　总结
那么，本书会对你有何帮助？它假定你并不懂互联网具体如何工作或者负载均衡大概如何工作。它会告诉你互联网是如何构成的，浏览Web最终会带来什么这样的基础知识。我们会介绍如何使用缓存技术来提高Web应用的访问速度、如何使用各种负载均衡技术，以及可使应用更容易扩展的核心理念（还有更重要的是，如何应用这些理念）。我们还会介绍如何将负载均衡器建成集群以获得高可用性、设立SSL会话以获得更高的吞吐能力以及构建稳定的解决方案。最后，我们会了解一下需要关注的新兴技术，比如IPv6和云计算。
简单说来，本书将会带你从一个对如何使得网站运行得更快、更稳定感兴趣的人，发展成为一个能够轻松地搭建这样一个解决方案并确信自己通晓其中工作原理的人。
我们希望你能够跟我们享受写作本书一样，享受阅读本书！
"

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.