又拍云存储介绍

  从目前云计算发展情况看来,大家对云服务的稳定、安全问题很关心。以我们所理解的云计算并不应该存在丢失数据等类似的严重问题,云计算的主要使命就是解决这些问题而存在,否则就不能称之为云计算了。如 SAE 类 PaaS 云计算平台是保障应用网站的正常服务,高度容错且可扩展,而又拍云存储则属 IaaS 类云计算平台,又拍云存储是向客户提供基础的存储服务,存储可用性和访问保障是又拍云存储最主要的工作。
  使用云存储服务不应该有数据风险,这是最基本的要求,所以请大家不用担心这个问题。到目前又拍云存储系统已经稳定的为又拍网、图片管家等网站服务两年多时间。存储系统已通过严格的业务测试,才于2011年面向互联网全面开放。可以说对又拍云存储系统的服务能力是有绝对信心!
  简单的从技术层面来说明又拍云存储的架构,让大家对又拍云存储有更深入的认识。热备、无单点这两个词语从头到尾贯穿整个系统架构,用户的一个数据文件存储于又拍云的数据中心,并自动分配到三台且不在同一机柜的服务器上,就是说任何一台服务器故障,都不影响正常访问,甚至某个机柜整体出现故障,因是分布到不同机柜的三台,所以还是不影响正常访问。为避免机房线路故障的情况发生,又拍云的数据中心自主接入了7线(电信两根、网通两根、移动、教育网、华数宽带)。再考虑更恶劣的情况发生,如机房断电,机房因政策问题而暂时无法提供服务等,所以又拍云的数据中心也做到无单点,目前在浙江杭州和萧山分别建立两个数据中心,这两个数据中心是互相热备的。现在大家能放下心头大石了吧 :)
  总结又拍云存储的服务高可用,仅一句话:“分布式的存储架构,且任何设备都做热备份,甚至机房”。
  在数据安全得到充分保障的基础上,又拍云存储为提高数据文件的访问速度,自主建立了覆盖全国的 CDN 网络系统(肯定的,地方节点也跟数据中心架构一样,多服务器热备份,无单点故障隐患)。并在传统 CDN 服务的基础上加入人性化的服务,如:域名防盗链、地址防盗链、IP 防盗链、客户端防盗链和 Token 签名防盗链等,涵盖当前主流防盗链系统的功能。并且这一切只需要用户在管理后台完全管理,在10分钟内全网设置成功。同时又拍云存储更革命性的使用实际流量进行计费,不再像传统 CDN 的带宽计费方式,做到用多少付多少,绝对不多一分钱。
  现在云服务已遍地开花,有做云主机的,云数据库的,更有云存储服务的,可以现在建立网站的成本比以前低很多。我建议大家可以先尝试一下云服务,如考虑把托管的服务器迁移到云主机,而论坛附件、用户上传类文件可考虑存储到又拍云存储上,又拍云存储已提供丰富的接入方式,Discuz和phpwind论坛只要到后台设置 FTP 信息就完才接入工作,很方便的。而对于数据库这类有高要求的数据,我还是建议大家仍旧使用托管的物理服务器,毕竟目前云主机的性能和稳定性方面仍有待观察。

使用 Nginx 构建一个“高”可用的 PHP 集群

  跳过没必要的介绍,直接进入主题。目前建立一个高可用集群的方案不少,可以使用硬件或软件 LVS 类构建,现在我说的方案是只用 Nginx 来进行构建。

  这个集群的架构如下图:

  上面我们共部署了5个节点,每个节点上配有 Nginx + PHP。这个架构的重点就在于,Nginx 不只是与本机的 PHP 通信,整个集群应该把 Nginx 部分抽象到面向业务的第一层,而 PHP 则在第二层。每层都为多节点均衡架构。

  其中 Nginx 层面使用 DNS 均衡实现,DNS 负载均衡是一个很传统的方案,在单个域名下绑定多个 IP 进行轮循,可有效的把业务请求分发到多个节点上,但某节点故障时则需要有相应的解析处理,把故障的节点从 DNS 记录中删除。目前推荐使用 DNSPOD 的解析服务,可支持 API 操作。这样我们就可以自己建立一个服务器状态管理的程序,自动切换 DNS 解析。(注意:域名解析的切换需要 5~10 分钟,当然这是由域名解析记录的 TTL 值决定,为避免大量的 DNS 解析影响请求打开速度,建议 10 分钟或以上为佳)

  第二层 PHP 则由 Nginx 使用 upstream 实现均衡,Nginx 本身的 upstream 就已支持节点健康维护的功能,可以放心的交给 Nginx 来做。而如果 PHP 业务层带缓存功能,则要考虑使用一致性哈希模块来实现 upstream 的均衡策略,否则节点故障对整个 PHP 集群的缓存造成大幅度的震荡。根据我们测试的数据,在普通哈希策略下,一个节点故障会导致 90% 的缓存失效,而使用一致性哈希则可降低到 50% 。并且我们的 Nginx 一致性哈希模块,还可以把故障节点的请求分发到邻近的节点,可以再提高部分缓存命中率,使得整体提升到 70% 的样子。

  这样一个架构方案给我们实现了一个“高”可用的 PHP 集群,并且没有单点故障的隐患存在。DNS 解析服务是多节点,Nginx 层是多节点,PHP 层更是多节点的模式。如使用 LVS 方案,LVS 服务本身也要做一套热备,才能避免单点问题,且增加了架构复杂性。

  应该选择那套架构方案还由业务决定,这里我只是提供一个新思路罢了 ;)

  Nginx 一致性哈希模块:ngx_consistent_hash-1.0.tar

             ngx_consistent_hash-1.1.tar.gz (Fix nginx reload bug)

  使用方法:

upstream backend {
server 192.168.1.101 weight=1;
server 192.168.1.102 weight=2;
server 192.168.1.103 weight=3;
server 192.168.1.104 weight=4;
server 192.168.1.105 weight=5;
consistent_hash $host$request_uri 2;
}

  consistent_hash 支持2个参数,第一个参数为哈希字符串,第二个参数为备份节点数量。当某节点故障时,将把该节点的请求分发到2个备份节点上。当然你可以设置1或更高,建议2为佳 :)

  模块对 nginx 原 upstream 模块的 weight 节点权重功能进行了替换,weight 的功能是配置节点在集群中的位置顺序。(做一致性哈希,这是必须的)

Tips: 使用 FireFox+FireBug 美化博客

  对上一篇文章我已经大概介绍过 FireFox 浏览器的 FireBug 扩展,它不仅仅能够帮助我们分析页面的加载过程,更重要的功能是帮助网页设计人员开发网页。

  因涉及的知识面很广,所以我只在这里跟大家说说,如何利用它来美化自己的博客模板 :)

 tips-firebug-01.gif tips-firebug-02.gif

  左图:是FireBug扩展查看页面HTML元素的截图,左侧为HTML代码,而右侧则是当前HTML标记的css属性。

  右图: 点击扩展界面左上角的查看按钮,我们的鼠标在浏览器上指向某一区块,那么左侧的HTML标记可自动定位到当前标记上。找到自己需要的区块,按下回车键(防止点击页面上的链接)右侧的css属性可切换到当前标记下。通过该功能我们可以快速找出自己想修改的HTML标记和css,方便修改。

tips-firebug-03.gif tips-firebug-04.gif

  左图:在HTML标记的css属性上,我们还可以点击相关的文字进行修改。比如我刚从是定位到博客标题的文字上,css属性列表中的 #header a {..,} 就是文字的属性了,其中已带color颜色属性为#000000黑色。点击颜色值将出现编辑框,我们可以在这里即时修改css属性并预览效果。

  右图:我们已经准确找到准确HTML标记的css属性,我们就可以参考css熟悉列表上的元素名称,对自己的模板css进行修改。

tips-firebug-05.gif tips-firebug-06.gif

  左图:切换到布局选项卡,我们还可以直观的看到当前HTML元素的大小和定位信息。

  右图:Yo2的博客可以进入管理后台-》私有模板-》编辑私有模板,修改模板的css文件。一般把自己需要修改的css写在文件的尾部。(如果你正在使用系统模板,请先私有化)

  以上是很简单的使用说明,至于如何写出自己需要的css效果请参考《CSS2 参考手册》 ,通过css可以不仅于修改文字的大小、颜色,还可以修改背景、定位、特效等等,你所能看到的一切 :) BTW:我无法提供HTML或CSS的教学指导,因日常工作量也蛮大的,还请体谅。我鼓励大家一起学习,互相帮助!

Tips: 使用 FireFox+FireBug 分析网页加载过程

Firebug是Firefox下的一款开发类插件,现属于Firefox的 五星级强力推荐插件之一。它集HTML查看和编辑、Javascript控制台、网络状况监视器于一体,是开发JavaScript、CSS、HTML和 Ajax的得力助手。Firebug如同一把精巧的瑞士军刀,从各个不同的角度剖析Web页面内部的细节层面,给Web开发者带来很大的便利。~~引用: 初识Firebug 全文

安装好FireBug扩展后,在 FireFox 中打开FireBug的界面,扩展就可以捕获当前窗口(标签)的网页加载过程。如我按Ctrl+F5强制刷新访问博客首页 http://oneoo.com

 firebug-tips-01.gif firebug-tips-02.gif

  从左图最下方,我们可以看到整个页面加载浏览器发起了94个请求,总下载数据是146Kb,整个加载过程耗时5.24秒。而在右图,点击请求列表以展开显示该请求的详细信息,当中包括了服务器传回浏览器的Header信息,和浏览器向服务器发出请求的Header信息。这些Header信息对于普通用户来说,没什么特别意义,我就不在这里给大家阐述了。我们只需要找出影响页面加载速度的地方就足够了 :)

 firebug-tips-03.gif firebug-tips-04.gif

   从左图我们可以在请求列表上,很直观的就可以判断出哪些请求是比较慢的。查出原因就可以对症下药,想办法加快它的加载速度(通常是由我来想的)或删除之。而右图则是浏览器刷新访问时产生的请求列表,当中可发现很多请求只是304 Not Modify返回(即无需重新下载,使用浏览器缓存)结合下面的右图(普通点击访问)所产生的请求列表,来做一个综合性的分析,看看哪些请求在下载时的速度慢,和哪些请求是可以被浏览器缓存下来的(这个最重要)务求把普通点击访问所需要发起的请求数量降到最低(Yo2的博客最低可以只发起2个请求)我的博客已经做过认真的分析和优化,去除了第三方网站的访问统计,第三方网站的图片调用等等,与博客没什么必要关联的东西,可以说是最佳状态了。当然关闭yo2sns插件的访问统计功能,速度还能更快一些。

  但做事不一定要极端的,能把页面的加载耗时控制到10秒以下,基本ok :)

firebug-tips-05.gif firebug-tips-06.gif

  左图是我使用另一个扩展 Yslow分析得出的数据,左边的饼图是浏览器在没有任何缓存数据的情况下,将需要下载的页面元素,右边的饼图则是在浏览器有缓存数据的访问所需下载元素。 Yslow还可以给页面下载速度打分,要获取高分就得有很高深的优化能力了 _-!!不是一般人可以做得来,我的博客评分也只是60左右,勉强及格。

  我的博客页面上的元素非常多,达到 94个,能够获得5秒左右的加载速度,成绩算理想的。我个人评分是90分 :D 看过其他BSP提供的博客服务,个别经过精心优化(很少图片)的页面加载需要发起30多个请求,耗时在3~5秒左右。而部分华丽的BSP甚至一个页面就需要发起100多个请求,加载耗时超过10秒 _-!!什么音乐播放器、动态相册、广告等等的附加元素都挂到博客上,不慢才怪 _-!!

  博客是以内容为主打,千万别忘记这个宗旨。太多花哨的玩意不会增加流量。

Tips: 使用 Fiddler 分析网页加载过程

Fiddler 是一个http调试代理,它能够记录所有的你电脑和互联网之间的http通讯,Fiddler 可以也可以让你检查所有的http通讯,设置断点,以及Fiddler 所有的“进出”的数据(指cookie,html,js,css等文件)

引用自:HTTP调试工具:Fiddler介绍一(翻译)

   Fiddler2 下载地址:http://www.fiddler2.com/fiddler2/version.asp

  安装好 Fiddler 并开启该软件,然后 Ie 浏览器的所有访问请求都将被 Fiddler 截获,我们会根据截获的内容进行分析:) 以下为全新访问(浏览器没有任何缓存数据) http://oneoo.com 所获得的截图:

fiddler-tips-01.gif fiddler-tips-02.gif

  软件界面上的左栏为打开该页面所产生的全部访问请求,其中包括请求次序、请求的返回状态、请求类型、所发请求的域名和地址等简要信息。右栏为访问请求的详细数据,包括请求的完成时间和浏览器发送请求的Header信息和服务器返回的详细信息。

  全选左栏的请求记录,并在右栏切换到 TimeLine 分析整个页面加载流程中各个请求的消耗时间:

fiddler-tips-03.gif fiddler-tips-04.gif

   选择第一个请求和最后一个请求,可获得整个页面加载所消耗的总体时间(右图)。从左图的条形图表中还可以分别出哪些请求耗时最多,从而对页面的访问进行访问速度优化(如果是第三方网站的服务调用,可以考虑去除)。而状态栏上可查看到整个页面所需要发送的请求总数。

  分析得出,我的博客首页总共有 84 个请求,其中两个比较大的图片耗时最多,全新的访客打开页面需要 9 秒时间。

  现在我们点Edit菜单Remove -> All sessions 清空记录,开始分析普通访客的加载过程 :)

 fiddler-tips-05.gif fiddler-tips-06.gif

   左图为用户点击链接访问,因刚才的访问已经让浏览器把大量的数据缓存下来,所以需要发送的请求数量很少,才5个,总耗时1秒。而右图为用户点击刷新按钮访问页面,因为是刷新访问,浏览器不会使用缓存数据,但会发送请求询问页面服务器浏览器上的缓存数据是否过期,所以会发送 84个请求。因为这些请求比较特殊,如果浏览器上的缓存数据跟页面服务器上的内容一致,那么服务器会返回 304 状态,而不需要重新下载内容的,所以总体耗时是 5 秒。比起没有缓存的全新访问要快一倍时间。

  综合以上的全新访问、带缓存点击访问和带缓存刷新访问,三种形式测试得出的数据,可以看到浏览器缓存在加快页面访问速度上起到非常大的作用。作为网站开发员应该充分考虑这方面的细节调整。

  如果你觉得自己的博客打开速度慢,也可以试试用 Fiddler 来测试一下,看看到底是慢在哪个地方,做出优化 :D 通常国外的统计代码都比较拖时间的~

  Ok~ 下期将会推出 FireFox + FireBug 和 httpfox 扩展来分析网页加载过程的教程。(FeedSky 验证 ece410df)