高性能网站构建实战 - (EPUB全文下载)

文件大小：0.42 mb。
文件格式：epub 格式。
书籍内容：

高性能网站构建实战
第一篇 架构规划篇
第二篇 负载应用篇
第三篇 页面缓存篇
第四篇 Web服务器篇
第五篇 数据缓存篇
第六篇 文件服务篇
第七篇 监控应用篇
版权
第一篇 架构规划篇
第1章 网站架构简介
第1章 网站架构简介
在目前这样一个高速的信息时代，我们更希望在最短的时间内以最简单的方式获取自己需要的内容。因此，我们需要一个高性能、高可用性的网站架构来支撑网站大量的访问。所以，网站的架构在网站运营当中所占的分量是相当之重的，那么如何构建稳定而又可平滑扩展的网站结构呢？我们先来了解什么是网站架构。
网站架构通过对用户需求进行分析、了解并定位网站的目标用户，从而对网站整体架构进行规划、设计，以最大限度地进行高效资源分配与管理的设计。网站架构粗略分为硬架构和软架构。
1.1 网站的硬架构
1.1.1 机房的选择
在选择机房的时候，根据用户的地域分布，可以选择双线或多线机房，但更多时候，可能多线机房才是最合适的。越大的城市，机房价格越贵，从成本的角度看可以在一些中小城市托管服务器，比如说北京的公司可以考虑把服务器托管在天津、廊坊等地，不是特别远，但是价格会便宜很多。
1.1.2 带宽的大小
通常我们在架构网站的时候，会设定一些目标，比如网站每天要能承受千万 PV 的访问量，这时我们要估算一下大概需要多大的带宽。计算带宽大小主要有两个指标（峰值流量和页面大小），我们先做出必要的假设：
1．峰值流量是平均流量的3倍；
2．每次访问平均的页面大小是100kB左右。
如果1000万PV的访问量在一天内平均分布，每秒大约120次访问，如果按平均每次访问页面的大小是100kB字节计算，120次访问总计大约就是12000kB。字节的单位是Byte，而带宽的单位是bit，它们之间的关系是1Byte = 8bit，所以12000k Byte大致就相当于96000k bit，也就是90Mbps的样子。实际上，我们的网站必须能在峰值流量时保持正常运行状态，所以按照假设的峰值流量计算，真实带宽的需求应该在270Mbps左右。
当然，这个结论是根据前面提到的两点假设得出的，具体值则需要根据公司实际情况来计算。
1.1.3 服务器的划分
一般情况下网站需要的服务器包括图片服务器、页面服务器、数据库服务器、应用服务器、日志服务器等。
对于访问量大的网站，图片服务器和页面服务器的分离是相当必要的。我们可以在图片服务器上运行Lighttpd，在页面服务器上运行Ngnix，当然也可以选择别的。我们也可以扩展成多台图片服务器和多台页面服务器同时运行，并设置相关域名，如imgs.domain.com和www.domain.com，页面里的图片路径都使用绝对路径，如，然后配置 DNS 轮循，达到最初级的负载均衡。服务器多了就不可避免地涉及同步的问题，这时可以使用Rsync软件来完成。
数据库服务器是重中之重，因为网站的瓶颈问题大多出在数据库身上。现在一般的中小网站多使用MySQL数据库。一般而言，使用MySQL数据库的时候，我们应该配置为一个主从（一主多从）结构，主数据库服务器使用InnoDB 表结构，从数据服务器使用MyiSAM表结构。这样充分发挥它们各自的优势，而且这样的主从结构分离了读写操作，降低了读操作的压力。我们还可以设定一个专门的从服务器作为备份服务器，有时候还需要借助Memcached之类的第三方软件，以便适应更大访问量的要求。MySQL在后面的章节有具体介绍。
如果有条件，可以应用独立的日志服务器。一般网站的做法是把页面服务器和日志服务器合二为一，在凌晨访问量不大的时候计划任务运行前一天的日志计算。不过对于百万级访问量而言，即使按天归档，也会消耗很多时间和服务器资源来计算。所以分离单独的日志服务器还是有好处的，这样不会影响正式服务器的工作状态。
1.2 网站的软架构
1.2.1 框架的选择
现在的框架有很多选择，比如PHP 的Symfony、Zend Framework等，至于应该使用哪种并没有唯一的答案，这要根据业务以及团队成员对各个框架的了解程度而定。很多时候，即使没有使用框架，仍然可以写出好的程序来，据说Flickr就是用Pear和Smarty这样的类库写出来的。所以，是否使用框架，使用什么样的框架，这都不是最重要的，重要的是我们的编程思想里要有框架的意识。
1.2.2 逻辑的分层
网站达到一定的规模之后，前期代码逻辑设计里的不足便会给维护和扩展带来巨大的障碍，但我们的解决方式其实很简单，那就是重构，将逻辑进行分层。通常，自上而下可以分为表现层、应用层、领域层和持久层。
表现层
表现层的表现形式不应该仅仅是模板，它的范围还可以更广一些，所有和表现有关的逻辑都应该纳入表现层的范畴。比如说某处的字体要显示为蓝色、某处的开头要有空格，这些都属于表现层应解决的问题。通常，我们容易犯的错误就是把本属于表现层的逻辑放到了其他层去完成。举一个比较常见的例子：通常在列表页显示文章标题的时候，都会设定标题允许的最多字数，一旦标题长度超过了这个限制，就会被截断，并在后面显示“...”，这就是最典型的表现层逻辑。但实际上，有很多程序员都是在非表现层代码中完成数据的获取和截断，然后赋值给表现层模板。这样的代码最明显的缺点就是，同一段数据，在一个页面可能要显示前5个字，在另一个页面可能要显示前10个字，而一旦在程序中固化了这个数值，这就丧失了灵活性。正确的做法是用视图程序来专门处理此类逻辑。
应用层
应用层的主要作用是定义用户可以做什么，并把操作结果返回给表现层。至于如何做，这就不属于其职责范围（而是领域层的职责范围），应用层会通过委派把工作实现的具体方法交给领域层处理。
领域层
最直接的解释就是包含领域逻辑的层，是一个软件的灵魂所在。首先，我们来看看什么叫领域逻辑。简单来说，具有明确的领域概念的逻辑就是领域逻辑，比如在 ATM 机上取钱，过程大致是这样的：插入 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。