GCE 和 AWS 的简单比较

Google Compute Engine(GCE)是 Google 云服务的一部分,和 Google App Engine(GAE)不同,GCE 提供了完整的虚拟机服务,而不是单纯的程序运行环境。GAE 一直被人诟病的是它移植难度高,很多开发者担心一旦入了 GAE 的门就很难再出去了,于是 GAE 一直推广不开。和 Amazon Web Service(AWS)如日中天的现在,Google 也无奈地跟风推出了 GCE 服务。

本博客使用 GCE 差不多也有一个月了,这里总结一下两者各种的优点和缺点。

网络架构

数据中心:AWS 在亚太有四个主要的数据中心:东京、新加坡、悉尼和北京,另外还有八个次级数据中心(Edge Location,主要用于 CDN 和 DNS)。相比之下,GCE 在亚洲只是一个数据中心,位于台湾彰化县。在美国和欧洲,AWS 对于 GCE 也处于同样的压倒性优势。AWS 在南美有一个数据中心,而 GCE 则完全没有。

DNS:AWS 支持分区域 DNS,即可以设置在亚洲地区解析到亚洲的 IP,在美洲地区解析美洲的 IP。GCE 只支持普通的 DNS 设置。

静态 IP:AWS 和 GCE 都支持静态 IP 绑定。除了分区域的 IP 地址之外,GCE 有一个功能称为全球 IP 中转,它可以使用一个不限定区域的 IP 地址来指向任意区域的机器,用于容灾。而 AWS 中必须在不同的区域使用各自独立的 IP,一旦某个区域的虚拟机全挂,就无法通过 IP(反向代理)把流量导向其它区域,只能修改 DNS。

跨区域备份:GCE 中的硬件备份(Snapshot)可以在所有区域中共享,网页中即可操作;而在 AWS 中则需要通过命令行方式手工复制。

分组路由:两者都提供了虚拟机分组,并可自定义组内的路由。

防火墙:两者都支持端口和协议限制,比如对于普通网站来说,只开放 80 和 443 端口,用于保护主机不被攻击。

虚拟机硬件

主机类型:标准类型,GCE 的 N1 和 AWS 的 M3 几乎一模一样,应该是 GCE 直接照抄了。两者也同时提供了临时测试的机型,f1-micro、g1-small(AWS)和 t2.micro 和 t2.small,配置也几乎一模一样。

SSD 硬盘:两者都支持 SSD 硬盘,在创建主机的时候可选。AWS 的 SSD 分为“通用 SSD”和“针对 IO 优化的 SSD”两种,而 GCE 的 SSD 还在试用阶段,并且不是每一个数据中心都提供了 SSD 支持。

虚拟机软件

官方操作系统:AWS 提供了 AmazonLinux,它是 RHEL 的分支,由 AWS 官方维护,另外还提供了对 Windows Server 2003 / 2008 / 2012、RHEL 6 / 7、SUSE 11 / 12 的支持。GCE 则没有定制系统,它支持 CentOS 6 / 7、Debian 7、RHEL 6 / 7、SUSE 11 / 12、Windows Server 2008 R2 等。

第三方操作系统:AWS 支持其它组织创建并公开的第三方系统镜像(AMI),基本上所有主流的 Linux 发行版(和主要软件,如 Oracle)都能在其中找到,无须自己安装。而 GCE 尚未开放这一功能。在 GCE 中,你可以创建一个镜像,但只能自己使用,无法分享。

数据存储及分发

数据存储:两者都有,Google Cloud 中称为 Cloud Storage,AWS 中称为 S3。概念也基本一样。AWS 还额外提供了廉价的 Glacier 存储服务,用于长期存放不经常改动的数据。

CDN:两者都有,Google Cloud Storage 自带 CDN 功能,AWS 中由 CloudFront 提供。

布署和管理

命令行:AWS 和 GCE 都提供了命令行工具,用于操作远程的主机和设置。

布署:AWS 中有 Elastic Beanstalk 和 CodeDeploy 可以用来布署机器,而 GCE 中目前只有 Startup Script 来配置机器。感觉 AWS 更成熟一点。

远程登录:两者都开放远程登录功能,视操作系统不同而不同,SSH(Linux)或 RDP(Windows)。GCE 额外提供了网页版的 SSH,无需 SSH 帐号即可登录,比 AWS 方便。

安全

帐号管理:GCE 中的项目(Project)绑定了管理员的 GMail 帐号,并且可以添加更多的 GMail 帐号做为管理员。AWS 中也类似。

主机监控:AWS 提供了 CloudWatch 来监控虚拟机的状态,并且在发生问题时可以发邮件通知或采取一些自动化措施,比如自动升级主机性能。GCE 中暂时还没有相应的功能。

费用

免费额度:AWS 对每张信用卡提供了一年的免费额度,可以使用 micro 类型的主机。GCE 没有类似的设定。

标准费用:以最便宜的标准机型来说,AWS 在亚洲地区的费用是每小时 $0.101,GCE 是 $0.069。

打折费用:GCE 中用满一个月可自动获得七折优惠,即所支付的费用直接降 30%;AWS 则需要事先购买一年或三年的套餐,折扣也在五折到七折左右。另外 AWS 还提供了低价的 Spot Instance 可供临时需要。

总体而言,从生态环境的完整度来说,AWS 有着巨大的优势,GCE 还需要一点时间才可以追上。但是,如果你的需求已经能被 GCE 满足,那么 GCE 的操作方便、价格低廉则比较有吸引力。

正常访问人人影视的方法

2014.02.06 更新: 域名再次更换,rrmj.tv,此站是一个讨论区,没有下载资源。

2014.02.01 更新:《人人影视》已重新上线,域名更新为 zimuzu.tv

2014.12.20 更新:《人人影视》在官微宣布人人影视网站正式关闭。

2014.12.17 更新:www.yyets.com 和 www.rrys123.com 均处于不可访问状态。前者会自动跳转到后者,但后者的 DNS 解析失败。看来又在停机维护状态了。

2014.12.09 更新:《人人影视》已完全开放,如果你还不能访问,请使用 hosts 绑定 www.yyets.com 到以下任意一个 IP。

2014.12.05 更新:《人人影视》已重新上线,IP 58.64.155.186,位于香港。只是暂时还没有开放访问,贴了一张大图说在清理数据。

2014.12.03 更新:《人人影视》所有域名(yyets.com、rrys123.com、rrys.tv)包括其附属站点(yayaxz.com)目前均处于无法连接的状况,DNS 无法解析,目测正在迁移服务器过程中。不过我对这种迁移的方式有点疑惑,看上去《人人影视》在没有找到备用方案之前,就早早地把原站给关了,连 DNS 设置也一起删除。这种做法和之前的 DNS 分地区解析的方案相去甚远,有一种不祥的感觉。

以下为原文:
一周之前,两个重要的影视网站接连宣布关闭,一个是《人人影视》,另一个是《射手网》。《射手网》是彻底关闭了,站长留下了一段比较伤感的文字,然后整个站的字幕就都无法下载了;而另一方面,《人人影视》则没有关闭,而是藏了起来。

尽管国内媒体大书特书,《人人影视》已经关闭,并留下一张截图。但这只是表象。实际上《人人影视》并没有关站,而是转移到了国外。从 DNS 的检测来看,www.yyets.com 在国内被解析到了如下 IP 地址:

如果你访问这些 IP 地址,就是得到像媒体公布的那样的“站点已关闭”的消息。但是,在国外,www.yyets.com 却被解析到了如下 IP 地址:

这些 IP 地址中,包含了正常的《人人影视》网站。于是乎,如果你想继续访问《人人影视》,请自行修改 hosts 文件。目前来看,修改 hosts 是最简单的方法,《人人影视》本身并没有做任何的限制,只是 IP 地址解析出来不一样罢了。

至于为什么会有这一设定,我认为这是《人人影视》的一个“避风头”的临时妥协的方案。由于来自国内过大的压力,《人人影视》暂时“屏蔽”了“一些”访问,同时在寻找一种更好的长久的方案。

另外我还追踪了一些正常的 IP 地址,它们似乎分布在很多地区,有新加坡、韩国和美国。看上去《人人影视》正在学习海盗湾(Pirate Bay)的方式,采取分布式的部署方式,使得网站下线的可能降到最低,同时也保护了核心数据的安全。具体技术不多说,总之《人人影视》看上去一时半会不会关闭。

如果你想知道最新的 IP 地址,可以通过这个工具来查找,它会列出《人人影视》网站在世界各地所解析到的 IP 地址,任选其一应该都能正常地访问。

屏蔽来自网页端的垃圾评论

上一篇提到我把 XML-PRC 的评论功能关掉了,但是效果并不明显,一晚上仍然有超过 20 条垃圾评论。和往常一样,这些垃圾评论被 Akismet 拦截下来,然后被我手动全部清除。

尽管 Akismet 的检测非常有效,几乎没有误伤的情况,但我依然觉得它有点大材小用了。Akismet 的工作原理是把每一条评论都发往 Akismet 的官方服务器,让服务器来判断是不是垃圾评论。它之所以高效是因为,Akismet 监控了大量 WordPress 博客的评论,一旦有某种模式的评论被认为是垃圾评论,所有启用了 Akismet 的博客都可以对那一类的垃圾进行过滤。这样略有一点用牛刀杀鸡的感觉。Akismet 会在网页中嵌入一些代码,虽然不大,但我对网页大小一直都很挑剔,能减则减;并且它会和其它的服务器通信,不仅增加了博客主机的负载,还消耗了更多的流量。

一定有一种更有效、更轻型的方法,可以用来检测并屏蔽这些垃圾评论。

以下是我的方法,它基于两点假设:

  1. 正常读者的浏览器都支持 Javascript。目前主流的浏览器都已支持并默认开启 Javascript,如果你所用的浏览器不支持它,那我也爱莫能助了。
  2. 正常读者都是通过评论框来写评论,而不是通过脚本自动填写的。基本信息如名字、邮箱等可以用脚本填写,这没有问题,但实际的评论内容也用脚本的话,那就说不过去了。另一方面,垃圾评论则有可能是机器自动生成、自动填写的,填写的方式基本是利用 Javascript 直接改评论内容。

基于以上的理论,我在 functions.php 中增加了以下代码:

这是两个全局的常量,用于后续的检测。它们用于生成一个随机数,在服务器端进行后续的检测。

以上代码在评论框中添加一个隐藏的元素“leonax-magic”,它的初始值是 0,当用户填写了评论的内容之后,它的值会变成另一个随机数字,大小介于上述的 $leonax_magic_lower 和 $leonax_magic_upper 之间。这个值有助于我们检测垃圾评论。

以上代码在评论提交之后进行检测,如果“leonax-magic”的值介于 $leonax_magic_lower 和 $leonax_magic_upper 之间,则表示该评论是正常的,反之则说明是垃圾评论。如果是垃圾评论,则直接报错(即在网页中会显示错误信息),而不是像 Akismet 一样存在数据库中。因为根据上面的假设,这样抓获的评论一定是垃圾评论,不需要再审核,于是就直接丢弃。

接下去是一些说明:

1. 为什么要用 $leonax_magic_lower 和 $leonax_magic_upper?
如果垃圾评论的机器蛮得聪明了,学会了在 HTTP 请求中添加 $leonax_magic 的值,我们可以通过改变 $leonax_magic_lower 和 $leonax_magic_upper 的值来继续阻止垃圾评论。

2. 这个机制有多么有效?
目前已使用超过48小时(至 11 月 28 日),没有一条垃圾评论漏网。

全站禁用 XML-RPC 评论

垃圾评论真是头疼,现在每天能收到超过 100 条垃圾评论,并且有上升趋势。

当然垃圾评论都被 Akismet 过滤掉了,但每天都要看一眼里面有没有误伤的,是件很头疼的事情。

于是解决方案之一就是禁用 XML-RPC 形式的评论,我就不相信所有的垃圾评论都是通过网页发的。如果垃圾评论是机器自动发出的,那通过 XML-RPC 是最合理且高效的形式了。而普通读者则不会通过 XML-RPC 来发送评论。

如果你发现在本博客留言出现故障,请留言。

顺便说一句,禁用的方式,是在 functions.php 中加一句:

这样就禁用了匿名用户通过 XML-RPC 的评论,而本博客并没有开放注册,所有的评论都被认为是匿名评论,于是就等同于屏蔽了所有的来自 XML-RPC 的评论。

与时俱进的垃圾评论

和垃圾邮件一样,博客中的垃圾评论也是一种 SEO 的方式。它的主要特点是包含一些网页链接或者关键词,以达到做广告的效果。Wordpress 有一个很好用的官方插件叫做 Akismet,它把所有的评论都发送到 WordPress 的官方服务器,来鉴别每条评论是不是垃圾评论。这样做的好处是一旦某一种模式的评论,如果包含某个特定网址,被认为是垃圾评论,那么它将在所有的 WordPress 站点中被阻止,总体上提升了垃圾评论的识别率。

我一直都在使用 Akismet 来阻止垃圾评论,不过在上周发生了一点小小的意外。

意外的根源来自我的一个邮件通知评论作者的插件,那是我一个月前刚刚启用的新功能。它的作用是在有人回复了某条评论时,自动给他所回复的人发送一封邮件,以便提升“回头率”。之前一直都工作得很好,我也没有仔细维护它,直到上周,一些读者开始抱怨收到了垃圾评论的通知邮件。

一开始我认为是 Akismet 的问题,因为确实有一些垃圾评论没有被过滤掉,然后我就手动把那些评论标记成垃圾评论。但在这之后,又收到了很多类似的通知邮件。这让我很纳闷,因为垃圾评论已经被 Akismet 给过滤掉了,不应该再触发通知功能。

后来仔细研究之后才发现,原来从一开始,垃圾评论就会触发通知功能,但始终没有人收到这些通知。原因是,那些垃圾评论没有回复给其它评论者,他们都是直接回复博文的评论。由于没有回复人,邮件就不会发出去。但是不知为何,垃圾评论的功能升级了,它开始回复已有的评论。由于我的插件中没有做好检测,尽管这些垃圾评论被 Akismet 过滤掉了,但依然会有通知邮件。

现在邮件通知功能已经改进了,不会再对垃圾评论发送邮件了。如果还有问题,请及时留言。

评论时自动填写身份信息

在别人的博客里留言,总少不了填写一些个信息,昵称、邮箱什么的。如果对方的博客中启用了集成式的评论,比如“多说”,那还登录一下就好了;但如果是最基本的评论功能(比如本站),还是要填这些信息的。虽说这些信息很少,打打字也不花多少时间,但如果有工具能帮我们填,岂不更好?

Chrome 的收藏夹有一个功能,它不仅可以记录一个网页地址,还可以执行一段 Javascript。这段 Javascript 需要以“Javascript:”开头,且只能有一行。大致样式如下图。当你点击这个收藏项的时候,Chrome 就会对当前页面执行这段 Javascript。于是我们要做的就是,写一段 Javascript 代码,在当前页面找写评论的地方,填上个人信息即可。

以下代码受博客评论个人信息自动填写代码一文启发,略加修改而成。它会依次搜索支持的博客类型,如果找到,就自动填写昵称、邮箱和网址。目前支持的博客有:Wordpress、Typecho、z-blog、Emlog。在手机和平板上同样可用。

把以上代码添加进你的收藏夹,填写好昵称、邮箱和网址之后,点击“生成链接”,然后把生成出来的链接拖曳进收藏夹:

>>>填写博客留言<<<

面向搜索引擎优化 之 面包屑导航

面包屑导航是(Breadcrumb Trail)是一种网站中的导航机制,简单来说,就是给每个页面加上一条路径。比如下图取自亚马逊的网页:

这个导航链接告诉了用户,当前页面的产品属于 Web Design 分类,而 Web Design 分类又是 Web Development 的一部分,最终归结为书籍(Books)。如果用户想找 Web Design 中其它的书籍,直接点击导航链接即可看到。不仅方便了用户,也会提升其它产品的销量。

面包屑导航不仅对用户有好处,搜索引擎也喜欢。比如下图就是本站在 Google 的搜索结果中的样子:

通常 Google 的搜索结果中,第二行显示的是页面的地址,但如果页面中使用了面包屑导航,Google 就会把地址替换成面包屑样式。面包屑的每一个部分都有独立的链接,对提升站点流量非常有用。

想要在站点中生成面包屑导航,和上一篇文章一样,要分搜索引擎来讨论:

Google

Google 的面包屑标准是在网页中嵌入类似下面这样的 HTML,如果一个页面属于多个不同的路径,可以放多个并列的面包屑:

Google 官方给出的介绍中全部使用了<div>标签,但试验下来上述的<span>也是支持的,看上去 Google 并不依赖了标签类型。

要生成这么一段导航,Wordpress 有很多插件都支持 Google 的面包屑导航,当然你也可以自己写代码,比如本站使用了下面这一段代码。如果你碰巧也使用了 Isola 主题,可以直接把下面的代码放进原先的 isola_posted_on() 中,并加以一点点的修改就可以用了。其它主题要看具体情况而定。

百度

百度也支持面包屑导航,只是要把它写在站点地图中。之前提到过,百度的站点地图格式中有一个<data>标签,面包屑也要写在这里:

完整的格式可以参考 XML 格式及规范说明。至于搜索结果中的样子,一时半会没有找到,想必应该和 Google 的类似,就不贴图了。