在 Google Cloud 架设博客的费用

说说目前博客的费用,给想用 Google Cloud 的同学们一个参考。

Google Cloud 的计费方式和 AWS 有点不太一样,AWS 想要便宜,需要事先买一个套餐,套餐价比常规价格便宜,但必须用上个一年或三年,如果一年内终止使用,套餐的费用是不退的。之前发生过买了三年的套餐,结果 AWS 推出新机型并且降价了,导致老的套餐性能又差又不合算的局面。

而 Google Cloud 则没有这个限制,它只需要你使用一种机型达到一个月,即可以享受优惠价格,比 AWS 要灵活很多。刚搬过来的时候,进行过几次调整,导致没有用满完整的自然月,于是一直没法发这个统计,总算现在有完整一个月的纪录了。

总共使用 45.06 美元,包括三台主机,博客放在亚洲的主机,兼当 DNS 服务器,另外还有两台从属 DNS,分别在欧洲和美国地区。目前这样的配置应该超过90% 的博客了,所以新建博客的费用只会比这个少。

以下是明细,单位为美元,已减掉用满一个月带来的优惠:

  • 博客主机,总计 28.99
    • A(Small / 亚洲):17.29
    • B(Micro / 欧洲):6.11
    • C(Micro / 美国):5.59
  • 流量,总计(58.9 GB) 12.19
    • 中国地区(46 GB):10.63
    • 亚洲其它地区(5.5 GB):0.68
    • 欧洲地区(2.4 GB):0.28
    • 美国地区(5 GB):0.6
  • 硬盘,总计(30 GB)3.85
  • Google Cloud Storage,863 GB * 小时,0.03

需要指出的是,Small 主机的配置是 1.7G 内存,外加我用了 10G 的硬盘,这样的配置比大多数 VPS 是要好的,比如 Linode 和 Digital Ocean 上 2G 内存的 VPS 都要 20 美元一个月。

而这个月 Google Cloud 又进行了一次降价,降完之后应该属于超合算的云主机了。

“延迟加载”的原理及实现

Lazy Load,中文大概可以译成“延迟加载”,是一种常见的降低网站流量的方式。它的大概原理是,以图片为例,在刚打开页面的时候,图片不加载,只要在用户看到图片的时候,才去加载图片。如果一个页面很长,平均分布着很多图片,那么用户在刚打开页面的时候,只能看到顶部的少量图片,如果这位用户没有看完全部的网页,那么页面底部的一些图片,即使加载了,他也没有看到,白白浪费了流量。于是对于图片大站来说,使用“延迟加载”技术,可以节约很多流量。

前几天我把博客的 Gravatar 重新开启了,并且做了反代,为了不让 Gravatar 占用太多流量(以及降低网页的加载速度),我把 Gravatar 的图片都做了延迟加载,等用户浏览到评论区了之后,才开始一点点加载。同时,搜索引擎的爬虫也访问不到 Gravatar,不会空跑无谓的流量。

在 WordPress 中使用“延迟加载”,除了使用插件之外,自己写代码也不难。首先,我们要修改服务器端的代码,使得默认输出是一个空白的图片:

上面代码把 Gravatar 图片的 src 改成了 data-src、srcset 改成了 data-srcset,并且重新设定了一个 src,是一个 1px * 1px 的空白图片。

接下来,要写一段 Javascript,动态地加载实际的 Gravatar 图片:

这段代码用来判断一个 element 是不是已经进入用户的视野,由于浏览过程中只可能向下或是向右滚动,所以只需要判断下边界和右边界即可。

上述代码检查所有 Gravatar 图片,并把已经可见的图片,替换成实际的图片。

最后,把 checkElements 函数挂载到一些事件中去,这样用户浏览页面的过程中,脚本会自动执行并替换图片。

于是,一个简易版本的“延迟加载”功能就实现了,是不是很方便呢?

投靠 Ubuntu

经过一番纠结之后,我还是把博客换到了 Ubuntu 之上。

之前提到过,从 AWS 转到 GCE 的时候,被迫选择了 RHEL 7(Redhat Enterprise Linux),因为只是 RHEL 7 是完全兼容 AmazonLinux 的。虽然 RHEL 需要另外付费,但为了平滑过渡,我还是以谨慎为先。

RHEL 有非常完善的商业支持,文档很齐全,有什么问题一查就可以明白。唯一的问题是,它的收费太高了,GCE 上面用一个月需要 50 刀以上,且不像主机一样用的时间长会打折,这样算下来,年费和一个 Radhat 的订阅差不多价格。但是我并不需要什么客户支持,技术问题都可以靠 Stackoverflow 搞定,这个订阅费用就白白浪费了。这也是我转向 Ubuntu 的主要原因。

还有一个原因是 HHVM。HHVM 是 Facebook 的 PHP 引擎实现,完全兼容 PHP 5.5 (及以上)。WordPress 从 3.9 开始,完整兼容 HHVM。

HHVM 的响应时间,据说是 PHP-FPM 的一半,也就是提升了一倍的吞吐量。原生 PHP 要做到这个效果,需要等 PHP 7 发布才行。看着各种发行版对于新软件的保守程度,不知道 PHP 7 要到什么时候才能成为主流。另一方面,Facebook 的研发能力肯定要比 Zend 来得强,等 PHP 7 发布了,HHVM 的性能肯定会更强。于是我就抛弃了原生 PHP,转投 HHVM。

当然,我也可以在 RHEL 上自己编译安装 HHVM。我试过,GCE 的机器编译了一个小时,我都快睡着了才编译完成,但安装(make install)的时候,告诉我某个文件不存在 -_-。我还是老老实实用官方的安装包吧,而 HHVM 官方只提供了 Debian 系列的安装包。

为什么没有选 Debian?Debian 保守到现在还只提供了 Apache 2.2,无语。

那也可以转投 Nginx 呀?我不高兴重写那一堆的 RewriteRule,并且 PageSpeed 在 Nginx 上也需要自己编译安装,不想再重蹈 HHVM 的覆辙。

由于 HHVM 和 PHP-FPM 的用法几乎一模一样,转换过程没出现任何问题,我做的唯一的工作就是重新设置了 Apache。花了几个小时,不过没什么难度,转换过程很顺利。

现在博客已经运行在 Ubuntu 14.04 + Apache 2.4 + HHVM 3.5 + MySQL 5.6 之上,欢迎测试,有问题请留言。

为博客开启站内支付功能

2016.02.15 更新:由于使用量太小,本方式已被关闭。

几年前,阮一峰在自己的博客上做了个实验,让读者看完文章之后,象征性地捐点钱以资鼓励。一年的时间里,他写了 88 篇文章,一共募捐了 5703.13 元人民币,平均一篇文章收入 65 元。读者的付费率不到 0.1%。

对于付费阅读的困难,阮一峰在文章中总结了这么几点:一)手续费高,如果每篇文章收 0.99 元,他还得倒贴钱给支付宝;二)付款流程麻烦,不是所有读者都有支付宝,即使有,就为了几块钱的捐赠走一遍付费流程,似乎不是每个人都愿意的;三)无法和读者互动,读者付了钱和不付钱,看到的内容是一样的。

那个实验是在三年前完成的,这三年里网络支付发展得非常好,在线支付的体验已经今非昔比了。

原先本站就已支持了四种支付方式:微信、支付宝、Paypal 和比特币。这四种方式现在都已支持手机扫码支付,打开手机应用,扫码即可完成支付,不必经历网页版冗长的支付流程。这些支付方式存在已久,大家都熟悉了,不必多言。

而从今天开始,本博客将增加一种全新的捐赠方式:站内信用卡支付,由 Stripe 提供支持。

简单的支付流程如下:

  1. 点击要捐赠的金额,比如¥10;
  2. 在弹出的对话框中填写:邮箱、信用卡号、有效期、CVC码,然后点击“捐赠”;
  3. Stripe 和本站服务器会联合完成剩余的工作。

整个过程中,连网页跳转都没有,非常高效快捷。实际的交易由 Stripe 完成,全程 HTTPS。本站无法获得(或保存)信用卡信息,仅能看到用户的邮箱地址和捐赠金额,作为归档之用。具体的交易流程将在之后的文章中详细介绍。

回到一开始的话题,这样的站内支付,可以解决阮一峰先生的两个问题:付款流程麻烦、无法和读者互动。

站内支付,自然没有复杂的付款流程,只需要一张信用卡即可。在 Visa 和 MasterCard 普及的今天,拥有一张信用卡并不是难事。在支付的过程中,也不必填写账单地址,或是等待短信验证码。整个流程可以在一分钟内完成。

而更重要的是用户体验,由于博客的服务器可以接收到用户的付款信息,也就可以做出相应的反馈。比如可以在用户付款之后,再开放某一部分文章的阅读权限,使得付了钱的用户,可以得到一些回报。当然本站并没有这样做的打算,目前还是以捐赠为主。

总而言之,科技在前进,前几年做不到的事情,现在变得简单,而逐渐没落的博客圈了,可能会因为多种多样的收款流程,而日益蓬勃起来。

与时俱进的垃圾评论

和垃圾邮件一样,博客中的垃圾评论也是一种 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 的类似,就不贴图了。