Windows平台网站图片服务器架构的演进

　　解决方案如下：

　　首先，关闭旧版本上传入口（制止继续使用导致数据纷歧致）。将旧图片数据通过rsync工具一次性迁徙到自力的图片服务器上（即下图中形貌的Old Image Server）。在最前端(七层署理，如Haproxy、Nginx)用ACL（会见规则控制），将旧图片对应URL规则的请求（正则）匹配到，然后将请求直接转发指定的web 服务器列表，在该列表中的服务器上设置好提供图片（以Web方式）会见的站点，并加入缓存计谋。这样实现旧图片服务器的分散缓和存，兼容了旧图片的会见规则并提升旧图片会见效率，也制止了实时同步所带来的问题。

　　整体架构如图：

　　基于FastDFS的自力图片服务器集群架构，虽然已经很是的成熟，可是由于海内“南北互联”和IDC带宽成本等问题（图片是很是消耗流量的），我们最终照旧选择了商用的CDN手艺，实现起来也很是容易，原理实在也很简朴，我这里只做个简朴的先容：

　　将img域名cname到CDN厂商指定的域名上，用户请求会见图片时，则由CDN厂商提供智能DNS剖析，将最近的（固然也可能有其它更庞大的计谋，例如负载情形、康健状态等）服务节点地址返回给用户，用户请求到达指定的服务器节点上，该节点上提供了类似Squid/Vanish的署理缓存服务，若是是第一次请求该路径，则会从源站获取图片资源返回客户端浏览器，若是缓存中存在，则直接从缓存中获取并返回给客户端浏览器，完成请求/响应历程。

　　由于接纳了商用CDN服务，以是我们并没有思量用Squid/Vanish来重复构建前置署理缓存。

　　上面的整个集群架构，可以很利便的做横向扩展，能知足一样平常垂直领域大型网站的图片服务需求（固然，像taobao这样超大规模的可能另当别论）。经测试，提供图片会见的单台Nginx服务器（至强E5四核CPU、16G内存、SSD），对小静态页面（压缩后的）可以扛住上万的并发且毫无压力。固然，由于图片自己体积比纯文本的静态页面大许多，提供图片会见的服务器的抗并发能力，往往会受限于磁盘的I/O处置惩罚能力和IDC提供的带宽。Nginx的抗并发能力照旧很是强的，而且对资源占用很低，尤其是处置惩罚静态资源，似乎都不需要有过多担忧了。可以凭据现实会见量的需求，通过调整Nginx参数，Linux内核调优、缓存计谋等手段做更大水平的优化，也可以通过增添服务器或者升级服务器设置来做扩展，最直接的是通过购置更高级的存储装备和更大的带宽，以知足更大会见量的需求。

　　值得一提的是，在“云盘算”盛行的当下，也推荐高速生长时代的网站，使用“云存储”这样的方案，既能帮你解决各种存储、扩展、备灾的问题，又能做好CDN加速。最主要的是，价钱也不贵。

　　总结，有关图片服务器架构扩展，大致围绕这些问题睁开：

容量计划和扩展问题。数据的同步、冗余和容灾。硬件装备的成本和可靠性（是通俗机械硬盘，照旧SSD，或者更高端的存储装备和方案）。文件系统的选择。凭据文件特征（例如文件巨细、读写比例等）选择是用ext3/4或者NFS/GFS/TFS这些开源的（漫衍式）文件系统。图片的加速会见。接纳商用CDN或者自建的署理缓存、web静态缓存架构。旧图片路径和会见规则的兼容性，应用程序层面的可扩展，上传和会见的性能和宁静性等。

　　作者先容

　　丁浪，手艺架构师。善于大规模（高并发、高可用、海量数据）互联网架构，专注于打造“高性能，可扩展/伸缩，稳固，宁静”的手艺架构。 热衷于手艺研究和分享，曾分享和自力撰写过大量手艺文章。

 3/3   首页 上一页 1 2 3