web 服务搭建需考虑的六大因素

概述

在搭建web服务时，怎么做才能实现稳定、可持久的服务，如何保证数据安全，实现高速的访问速度，是一个非常重要的事。

HTML 静态化

资源占用最小、效率最高的就是纯静态化 HTML 页面，事实上，即便是内容时长变化的页面，其动态请求的内容在很长一段时间内也是不会变化的。 如果将动态请求静态化，以一定的频率去更新缓存的静态页面，对于资源利用与网站访问效率都有很大的提升。

图片服务器分离

对于 web 服务器来说，图片都是最消耗资源的，因此如果将图片与网页进行分离，用独立甚至多台服务器专门存储图片，这样的架构对于降低服务器访问系统压力来说是很有效的。 对于图片服务器，可以通过尽量少支持 ContentType、LoadModule 来保证更高的效率。

数据库集群、库表散列

大型网站都有复杂的应用，他们依赖于数据库存储，当面对大量访问时，数据库瓶颈很快就会显现出来，这时一台数据库将很快无法满足应用，需要考虑使用数据库集群或库表散列。

有时候我们还需要从应用程序的角度考虑改善系统架构，库表离散是最常用的且有效的解决方案，不同的模块对应不同的数据库或表，这样的细分不仅能够以低廉的成本提升数据库性能，并且可以做到很好的扩展性。

例如，sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

同时，越来越多优秀的 NoSQL 数据库提供了应对高并发业务需求的能力。

缓存

架构缓存

架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

应用缓存

网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。

分布式缓存

分布式的缓存不仅提供了快速的高可用性存储，而且可以避免缓存中数据的丢失，常用的有 memcache、redis 做 session 等频繁使用的数据的存储服务器，缓解应用服务器的压力，并且做到数据的统一管理和备份。

镜像

镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如 ChinaNet 和 EduNet 之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。 在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如 Linux 上的 rsync 等工具。

负载均衡

负载均衡将是大型网站解决高负荷访问和大量并发请求采用的解决方法。 通过多台服务器分担网络压力来提升系统的并发性能。

硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。 在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。 “Yahoo中国”当初接近2000台服务器，只使用了三、四台Alteon就搞定了。

软件四层交换

了解硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理是一样的，不过软件交换的性能稍逊于硬件交换。

软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

软件交换的性能很大程度上在于使用者对配置的熟悉能力，熟练的配置能力可以在满足压力的情况下游刃有余，灵活多变。

总结

对于大型网站来说，前面提到的每个方法都会被同时使用，这里的描述还较为浅显。 当然了，任何一种优秀的框架的意义都是基于实际的应用需求的，没有可以适应一切需求的解决方案，在必要的时候，根据实际的需求编写实际应用场景下最实用的存储、网络模型才是最佳的解决方案。