通用型小文件web架构.docx

通用型小文件web架构介绍通过3层结构：lvs，haproxy，nginx，实现此架构。通过对uri哈希的方式实现小文件的分布存储，同时每个文件有1份冗余。可以方便的进行扩展或缩减。拓扑图原理所有HaProxy的配置是相同的，每个Nginx都有一个唯一的ID。当请求到达LVS时，会轮询转发到一台HaProxy，HaProxy对请求的uri进行hash，根据hash值找到对应ID，再将请求转发到ID对应的Nginx。因此同一个uri会固定转发到同一个Nginx。例如：有6台Nginx，ID分别是1-6。请求的uri是/test.html，根据计算的hash值，找到对应的ID是2，那么此请求就会转发到ID为2的Nginx。如果ID为2的Nginx宕机，HaProxy会根据hash值重新查找对应的ID是4，那么此请求就会转发到ID为4的Nginx。那么在此例中，ID为2和4的服务器上都需要有/test.html的内容，针对/test.html，ID4是ID2的备份。技术实现LVS也可以考虑使用FreeBSD的CARP+pf+relayed。Haproxy利用软件本身的负责均衡功能，通过uri哈希值判断后端服务器，保障每个uri被分配到固定的后端服务器。Haproxy中的server配置中，id和weight的值决定哪些uri被发送到此server，因此一定要对这2项进行明确设置（weight的默认值是1，不推荐使用默认值）。maxconn、minconn、maxqueue的配置则会影响server的weight，因此这3个配置要是有默认值。Nginx此架构中，Nginx有两种工作模式：web server模式和反向代理模式。在反向代理模式中，通过proxy_cache_bypass设置需要缓存的内容，而缓存时间的控制最好通过原站控制，就是在响应的http头中设置：X-Accel-Expires（优先权最高）或Expires/Cache-Control。这种模式下，一般不用考虑下面管理部分的内容。在web server模式中，需要解决两个问题：1、将响应是404的请求重定向到原站（内部重定向，不推荐用302）；2、热点内容的处理。就是将访问较频繁的内容存放在速度快的载体上（通过日志分析），如SSD硬盘或内存（memcached）。如果使用SSD硬盘，先判断SSD硬盘上是否有要访问的内容。有，就重定向到SSD硬盘。顺便说一下，将文件拷贝到SSD要先拷贝再改名，避免拷贝一半时有用户请求。配置示例：假设将SSD硬盘挂载到/ssd，执行：ln –sf /ssd $document_root/ssdif (-f $document_root/ssd$uri) { rewrite (.*) /ssd$uri break;}如果使用memcached，配置示例：location / { set $memcached_key $uri; if ($http_accept_encoding ~ gzip) { set $memcached_key $uri-gzip; add_header Content-Encoding gzip; } memcached_pass :11211;error_page 404 @disk; }location @disk { root /opt/www/down; }Pure-ftp扩展的认证模块（perl开发），支持一次性密码，支持ssl（只针对认证）。通过update钩子，将上传的文件分发到各个webserver。管理编写一个小工具：hachash。此工具的功能就是如何得知一个文件需要分发到哪个web server上。用haproxy一致的算法和配置（web server配置：ip，id，weight），计算uri应该分配到哪个web server，及当此web server宕机后，应该分配到哪个web server。然后通过ftp上传到各个服务器。当需要对增加web server时，需要3个步骤：在每台现有服务器上，用增加webserver后的配置运行hachash，遍历所有文件，按运行的结果重新分发。等待所有服务器都完成分发后，更新Haproxy的配置，将新服务器加入Haproxy，并重新加载配置。将每个服务器上重新分发的文件删除。