说是年中，其实已经到了8月的尾巴，开学季即将来临。在暑假期间新购了一些VPS，想和大家分享一些我的看法和购买的心路历程，顺便做一些简单的评测汇总。

很久没有写博客了，感谢 琉璃 和 Tankey 两位作者带来的专栏，他们是我的好朋友、好管理，同样也会是好作者。关于博客下半年的内容我已经有了简单的规划，其中几篇已经准备开坑，敬请期待！

群组：@NewlearnerGroup

频道：@NewlearnerChannel

购机标准和信息渠道

我不是一年前那个满足于四大金刚的人了，记得 123大佬 当时已经开始关注 韩国VDS 了，而我到现在也没有这样高的需求。但是还是很怀念当时水群刚创建的时候和大家一起买鸡的时光，时隔一年，在最近买鸡发频道 & 群组讨论的过程中，这种感觉又回来了。

先说一下我最近的购机标准：

我知道这样的价钱和这样的要求可能不相符。譬如就香港而言，cloudiplc的cmi 需要70一个月，dmit 也不便宜，hkt 很多都是独服，很多 nat专线 又不符合要求。美西方向的gia目前 rfc 等商家也不便宜，瓦工在涨价后依然划得来，但我不想年付了。

说白了是预算不足带来的问题，很多人抱怨自己买不到满意的VPS，反过来想想是钱没有到位。

再介绍一下我都是从什么渠道得知一些VPS补货、促销信息：

但要正确看待所谓的「推广」、「评测」，你得到的消息千千万万的人也看见了。如果出现价格过于低廉，人们一哄而上的情况，要看清现实选择果断放弃。对于刚成立的小众商家，不要一味地看 affman 的分析和评测，要有自己的判断和看法。

购机历程

在8月13日凌晨3点，身体不适起床，刚好看见梨园在推 Moecloud 这个商家的gia，决定先mark白天再看。起床后了解到 MoeCloud 是两天前刚成立的国人商家，用的前端是 WHMCS ，ssl证书是cf的，域名是今年8月8号从 NameSilo 注册的，只续费一年。

商家的上游是hkss，十分可靠。而VPS为月付37元，正在预售，具体情况如下：

还是冒险上车这个刚成立的商家的车，后来得知原来是陌离大佬开的。过了两三天开通了，测试和使用（江苏电信、移动）来看十分满意，对得起这个价格。更令我感动的是，除了一些个人博客和个别aff商家推送，全网找不到任何宣传的文章和帖子。这就保证了不会出现超售、一哄而上的情况，保证了用户的体验，做到了「小而精」。期待他们九月份迁移完宿主机之后的表现。

就在几天前，我在主机测评的tg群看到有人说自己买了企鹅小屋月付13元的cmi，于是果断买了一台。买完之后才得知这个廉价促销活动从11号就开始了，宣传的文章也不多（最起码我没看见）。

不出所料刚买完的晚上宿主机就遭到了一顿毒打，太便宜了，老板不得不停止销售。第二天起来装完之后测试了一下，电信/移动表现都不错，虽然配置差了点，但是不要自行车了。

套餐配置如下：

后来重新开始预售了，流量多了10G，价格改为14元月付。我还是希望企鹅小屋能一直保持他们的价位，过于廉价可能会时不时遭到毒打。

总之，这两次购机都是缘分使然，无意中看到的两条消息满足了我今年的购机需求：

1、GIA和CMI线路，晚高峰稳定

2、年轻人的第一台香港服务器

3、都可以解锁流媒体

简单评测

• Moecloud GIA

测试时使用了江苏电信50M和移动4G，评测过程已在tg频道发过（倒序观看）：https://t.me/NewlearnerChannel/76

评测结果：https://paste.ubuntu.com/p/z3X3Pr5JNx/

线路已经说过了，电信联通双程GIA，移动去程 Cogentco，回程GIA。这里就不上图了，期待tpe海缆维修结束之后的效果。硬件配置确实是不错的，可以用来建站，也可以纯作联网需求。通过他们家的上游hkss，我查到了 moecloud 的宿主机配置：

不知道将来会不会搞活动宣传，我很自私地想保持现状，这样用户体验不会差，但是商家总要赢利的。九月份全部VPS的宿主机将会换为上图右侧配置，VPS配置不变，还是很期待的。希望 moecloud 能一如以往地坚持下去。

• 企鹅小屋

测试时使用了江苏电信50M和移动4G，评测过程已在tg频道发过（倒序观看）：https://t.me/NewlearnerChannel/296

评测结果：https://paste.ubuntu.com/p/pXthJcBjPN/

因为是超级mini版，商家对CPU和io都有所限制，CPU购买三日内单核不得长时间超过50%，三日后不得超过15%，不可以push。因此适合拿来作纯联网用途，受制于性能和各种攻击，不建议放重要的项目。至于ip归属地个人推测是美国广播过来的，ipip查询后目前在香港，真人率很高，因此可以看b站港澳。晚高峰 奈飞1080p 无压力（江苏移动），表现还算不错。

企鹅小屋的这款套餐我认为属于羊毛一样的存在，也安利给了一些朋友，目前表现令人满意。

随想

之前在VPS一周年的帖子中，我说了「一时买鸡一时爽，一直买鸡一直爽」。通过loc等论坛，每天都会看到许多吸引人的促销和羊毛活动。我不禁问自己：你是否陷入了买鸡成瘾的怪圈之中？

买鸡成瘾指的是看到优惠促销就购买，往往没有目的、理由，眼里看见的是「便宜」。这样下去买的服务器越来越多，用的却很少，最后大部分吃灰。

这次买的两台服务器填补了我没有美西GIA和香港服务器的遗憾，价格适中，作为学生可以承担的起，并且可以流畅奈飞。今年买的VPS并不多，但都没有选错。大概今年黑五也不会剁手了，需求已经满足甚至过剩。

在各种上架和促销信息纷飞的今天，跟风一拥而上往往没有好结果。今年暑假在loc上面很火的ion cn2和ruvds 3元毛子鸡我也有关注，结果跑了跑别人提供的测速，效果惨不忍睹。VPS的出售有一个「度」，商家在这个「度」内提供服务，用户会得到一个较好的体验。超出了这个「度」，商家可能赚的盆满钵满，但是超售的代价就是用户迅速涌入又迅速流出，商家名声败坏，最后走向破产（参考alp）。如何把握这个「度」，全看商家。

至于affman，也要辩证看待。affman，顾名思义是专门推广VPS收取返利的，他们的目的很明确：赚钱。affman 也有个「度」，较好的 affman 会亲自去使用推荐的产品，并建立一些测试站供读者们测试，这样避免了用户购买后发现体验糟糕。一般的 affman 会跟着几位出名的 affman 推送服务器，有评测但不会全部亲自试用。Bad affman 会根据商家返利的百分比，不经过测试直接推送服务器，譬如曾经的「超兽五杰」。

因此我们不能全信别人的推荐，也不能一点不看盲目购买。但有一点是可以肯定的：某商家的VPS推送满天飞，论坛和 affman 天天推送，这个商家你就要三思了，他们的质量是否对得起你付的钱。「酒香不怕巷子深」，好的商家用户们自然会口口相传，相互推荐的。

所以说鸡场也是个「江湖」，里面有idc大佬，有浑水摸鱼想捞几笔aff的 affman，有刚入VPS坑的玩家，也有机场主。买鸡的经验需要靠自己去总结，去交学费，去一次次的跳坑。时间一长你会对这个「江湖」形成自己的一套世界观和一些必要的经验，这些需要时间去积累，而不要幻想有什么大佬一下子能传授给你。

买鸡的时候，需要关注以下几个点：

VPS除了访问外网，我们也要充分利用起来，做一些有意义的事情。我在博客写了不少这里就不再赘述。如果单纯想要访问外网又不想在VPS投入太多，强烈建议购买机场服务。但VPS一分钱一分货的道理是不变的，既然选择了VPS，就不要天天想着掉馅饼，每个套餐都是便宜的「传家宝」。

这次购机的过程可谓充满了惊喜与快乐，结果也很好，又可以佛系一段时间了。想要买到心仪的VPS，耐心等待和灵通的消息是必要的，当然还要考虑上运气的成分。希望大家可以抓住这样的机遇，买到符合自己需求的VPS！

有了服务器监控服务，就能知道网站运行的情况以及在线时间。当服务器出现问题时，便能第一时间收到通知。个人网站运维需要这些服务来保证稳定性。但是，大量的此类服务都是面向企业，导致价格十分昂贵，而且并用不到其所提供的功能。本文就给各位站长推荐几个免费的服务器监控服务。

在线率（Uptime）监控服务

StatusCake

StatusCake 同时提供免费和付费的监控服务。免费版本可以创建无限多个 HTTP(s)、TCP、DNS、SMTP、SSH、Ping 和 Push 的协议监控，监控周期最短为 5 分钟，提醒主要支持 E-mail 和 Webhook 两种方式。免费版本不支持监控服务器配置信息，所以也无需在服务器上安装任何软件。

此外，StatusCake 支持 Public Reporting，你可以利用 StatusCake 建立一个监控页面。它还支持将在线率图像及网页嵌入在你自己的网页中，十分方便。

注册地址

UptimeRobot

UptimeRobot 也提供免费的监控服务，支持 HTTP(s)、端口检测、Ping，监控周期最短为 5 分钟。同样不支持监控服务器配置信息，所以也无需在服务器上安装任何软件。最多只能创建 50 个监控，支持 E-mail 提醒。

相比 StatusCake，它的监控功能要少，但是 Public Reporting 的页面要漂亮一些。由于 StatusCake 所多的那些功能个人站长也几乎用不到，所以 UptimeRobot 也是 StatusCake 的一个良好的替代。

注册地址

监控宝

监控宝是一家国内的监控服务，长期提供的免费版可以创建 6 个 HTTP(s)、Ping、DNS、FTP、TCP、UDP、SMTP 甚至是使用 SNMP 对服务器性能监控（需要软件），监控周期最短为 15 分钟。如果你需要检测国内到你的主机的速度，或者你的主机在国内，监控宝是一个不错的选择。它的免费监控是从中国内 3 个位置同时监控。它支持 E-mail 和手机短信告警。它不支持 Public Reporting，但是可以给分享网站的 SLA 证书。功能相当齐全，就是网站的界面设计比较欠缺。

注册地址

服务器指标监控服务

Stackdriver

最后，就要介绍我最近开始使用的强大的 Stackdriver。Stackdriver 是 Google Cloud Platform（下文简称 GCP）旗下的服务器监控服务，支持监控、调试、跟踪、日志。其中的 Uptime Check 支持 HTTP(s) 和 TCP，监控周期最短为 1 分钟。它支持 E-mail 、手机短信和 APP 内告警。它的 Uptime Check 是从全球 6 个地区同时监控，可以看到每一个地区的延迟。用来检测 CDN 的速度肯定会很不错。

如果你正在使用 Google Compute Engine（下文简称 GCE） 或者其他 GCP 的服务，那么这个服务还可以帮你记录服务器日志，每月有 5 GB 额度，超出后每 $0.5/GB。此外，它还能进行服务器性能监控，监控服务器各项指标。虽然原本 GCE 面板也能提供 CPU 等信息，但是这个是需要在服务器上安装 Agent，于是就能提供更丰富更准确的信息。安装过程如下：

curl -O https://repo.stackdriver.com/stack-install.shsudo bash stack-install.sh --write-gcmcurl -sSO https://dl.google.com/cloudagents/install-logging-agent.shsudo bash install-logging-agent.sh # 谨慎安装，见下文

毕竟是 Google 自家的服务，安装不需要任何登陆等操作。安装完毕后就会自动采集数据。它分为两个部分，Stack Monitoring 用于监控服务器指标，包括硬盘存储空间、内存占用（包括 Used、Buffered）等 GCE 默认无法监控到的数据。还有就是 Logging，它可以自动同步日志到 Google 的云端，你可以集中的执行搜索等操作。然而 Logging 这个进程会大概占用 100M 内存，小内存实例谨慎使用。需要注意的是，只有 Logging 是免费的，Monitoring 是收费的，每月 $8。 然后，你还可以为某一项指标建立告警，比如我创建了一个当磁盘空间高于 90% 的时候给我发邮件。 它可以创建公开页面分享服务器指标和 Uptime Check 延迟的图标，但是却不能显示在线率，实在是一个奇怪的设计。

Observium

Observium 通过 snmp 可以用来监控服务器的各项指标，包括内存、储存、网卡等。它可以免费安装在自己的服务器上，需要 MySQL 和 PHP 环境。官网给的是 Apache 的范例，如果你用 Nginx 就不需要安装 Apache。

它通过在服务端生成 PNG 来显示图表，所以图表很漂亮精致，但是由于不是矢量图，所以很难做到实时增量更新而且不能精细看到某一个时刻的数值。 Observium 可以轻松的管理许多个服务器。你可以体验在线 Demo。

建立网站、建立软件（或游戏）的服务器等，可能会有很多纠结的地方，也有很多坑，这篇文章根据我个人的经验来帮助大家选择最适合自己的方案，以及一些建议，在最后列出来一些我推荐的服务。

服务的三种类型

一般的，建站所需要购买的服务也是属于这三种服务之间的。从 SaaS、Paas 到 IaaS，依次从使用简便到复杂，从可拓展性低到高。了解这三种服务类型有助于选择合适的服务。

• SaaS，软件即服务：比如 WordPress.com 等提供了一整套服务（包括了域名、主机、平台和软件）的，就算是 SaaS，这种服务对于初学者使用起来最方便，专业人士也能玩出不少花样，但可拓展性受到软件的限制，通常这种服务都有较高的可用性，并且是分布式的。
• PaaS，平台即服务：比如基于 cPanel、Plesk 面板的虚拟主机，你可以在平台上安装已有的开源软件，或者将自己软件代码上传，总体使用几乎和 SaaS 一样简单，使用特定的操作系统和代码语言，安装各种程序。PaaS 有普通的也有分布式的，后者的在可用性和数据保障，以及可拓展性上都要好于前者。
• IaaS，基础设施即服务：包括 VPS、独立服务器、云 VPS 和共有/私有云服务器。VPS 和独立服务器相比主要差距是在配置上，包括 CPU、内存、硬盘等，后者的配置会高很多，可用性方面没有太大区别。云 VPS 和共有/私有云实际上是基于云端分布式的 VPS 和独立服务器，一样的，他们的在可用性和数据保障，以及可拓展性上都要好于 VPS 和独立服务器。IaaS 需要自己选择操作系统，所有的服务和软件都是自己配置，通常都给你 root 权限。

服务的选择

• 位置选择之国内：首先需要考虑的是国内还是国外？如果选择国内，首先你得域名需要经过备案，这可能需要将近一个月时间，这无疑为建网站增加了不少成本。而且国内的服务器普遍较贵。不过如果要选择国内，我比较推荐的主机是新浪的 SAE，它价格很低，是按需付费，并且还有免费额度，它属于分布式的 PaaS，提供高可用率的服务，支持 Docker 容器、DDOS 防御。不过 SAE 对于非企业用户不提供 CDN 和自定义域名 HTTPS，我推荐你使用 UPYUN 来实现 CDN 和自定义域名 HTTPS 功能。国内的优点：可以保证网络延迟低，并能符合目前的一些法律政策。
• 位置选择之国外：不少亚洲的主机（包括但不限于香港、日本、新加坡）从大陆连接会 “绕道”，导致延迟很高，购买前需要先了解清楚，香港便宜的共享主机推荐 TlOxygen。亚洲的主机普遍网络带宽不大，流量比较少，如果不选择亚洲的，那就建议先选北美的。国外的主机通常会有比国内很多主机更低的价格，更好的国际带宽。 如果有条件，可以配置多个服务器，两个服务器推荐的解决方案是亚洲 + 北美东岸，并将亚洲和大洋洲都指向亚洲，其余的都指向北美。如果有条件配置更多服务器，那么可以同时配置北美东岸 + 北美西岸 + 欧洲 + 亚洲的四个服务器并分区解析，就我的实际测试而言，把非洲指向欧洲，把大洋洲指向北美西岸能达到最快的速度。

一些可能需要的特性：基于要实现的不同功能，可能需要在以下方面有要求，在选择服务的时候需要优先考虑。

• 高数据可靠性：几乎所有的网站或是和网络相关的软件，都需要存储用户的数据，所以高数据可靠性是十分重要的。所以磁盘阵列为 RAID1 和 RAID10 是首选。而且用户数据的备份也是十分重要的，可以存储在第三方如 AWS S3。一些服务提供商提供了备份功能，其实也是能够保证高数据可靠性。
• 防御攻击的能力：攻击的成本已经越来越低，种类也很多。通常最难防御的攻击种类是 DDOS，其余的几乎都可以通过软件实现。建议在选择服务器时就要选择有 DDOS 防御的服务器，或者直接使用 CloudFlare 之类的基于第七层的防御。
• 可伸缩，按需付费：最简单的例子就是网络的计费方式不是按照带宽计费，而是按照每 GB 多少钱计费，不限带宽，能够避免不必要的支出的同时还会让用户享受最快的速度。同样的道理，按照系统资源的使用来计费的模式是最好的选择。一般的，基于云端的 PaaS 都是这种计费方式，IaaS 则需要自行配置来实现资源不够时升级配置，资源过剩时回收配置（也可以是 Auto Balancing），所以按小时（或分钟、秒种）级别的计费 IaaS 计费方式最适合这样伸缩以达到按需付费的目的。
• 网络可靠性：网络可靠性也十分重要，如果服务的网络不好，那么将极大的影响用户体验，导致用户不可以使用服务。
• SLA：重要的服务都需要 SLA，SLA 能给你承诺服务的可用率，当服务没有满足承诺时，服务提供商会给你赔偿。
• IPv6：就目前来看，如果不支持 IPv6 也没什么问题。但是能有原生的 IPv6 支持总比没有好，而且现在正在有越来越多的运营商支持 IPv6，使用 IPv6 有可能会有更低的网络延迟，同时配置 IPsec 也有优势。

其他

• 域名相关：不管你是选择使用虚拟主机、VPS 或是独立服务器，通常你还需要自己买一个域名，配置 DNS 解析等等，推荐免费的 DNS 解析有 CloudFlare、Rage4，国内还有 CloudXNS，一些虚拟主机商以及域名注册商也提供免费的解析，但不如前面介绍的那几个（详细关于 DNS 的介绍请见此）。如果选择使用 CloudFlare，那么你还可以在 DNS 后台选择开启 Proxy（CDN），这样能为你的网站缓存并加速（但实际上对于国内来说有可能反而减速），并获得一些基础的 DDOS 防护，并隐藏你的源站 IP 地址。
• 域名注册商的选择：首先，要保证总的域名保有量大；其次，要域名后缀种类齐全；第三，最好能附加免费的企业邮箱和高级的隐私保护；第四，域名注册后要能删除并退款，防止手抖注册错了；第五，价格不能太贵。在我做的 TlOxygen 这个公共域名注册服务上，使用的域名注册商是全球前十大域名注册商；有 500 多种域名后缀，数量超过 GoDaddy；赠送企业邮箱，可以配置无限个转发邮箱，甚至还可以配置子域名邮箱，还支持 DKIM；大多数种类域名删除可以拿到退款；价格比 Godaddy 便宜很多，续费价格没那么坑，基本上是 7 折；域名隐私保护只有 5 元，但功能比很多免费的高级：即使开了域名隐私保护，别人给你发邮件时，会收到表格，还能继续填写表格与你联系。

一些服务商的推荐

排列的顺序只是与添加在这个列表里的时间有关，新添加的会被放在后面。此处添加的服务商全是个人的推荐的，以后还会持续更新。 标注列表：

• (6)：全面支持 IPv6
• (6)：部分支持 IPv6
• (D)：支持免费 DDOS 防御

SaaS

建立网站

• WordPress.com
• Tumblr (6)
• GitHub Pages

CDN

以下 CDN 都支持 HTTPS 与 IPv6

• UPYUN/又拍云 (6)
• CloudFront (6)
• CloudFlare (6、D)

DNS

• Route 53 (6)
• Rage4 (6、D)

数据存储

• AWS S3

代码托管

• GitHub
• GitLab.com
• Coding

SaaS 还有很多，太多的东西都是 SaaS 了，所以这里只能算举几个例子。

PaaS

虚拟主机

• BlueHost

云主机

或者说是分布式的虚拟主机，但是有独立的 CPU 和内存资源。

• ResellerClub
• BlueHost

可自选软件语言的/Docker 容器

• 新浪 SAE (6¹、D)
• OpenShift
• AWS Elastic Beanstalk
• AWS EC2 Container Registry

IaaS

VPS/Cloud

标注列表：

• (U)：独享 CPU³

• (C)：基于云端的技术，高可用性

• (S)：关机后不计费

• Vultr (6、D⁶)

• OVH (6²、D、C⁴)

• Google Compute Engine (D⁵、C、U、S)

• Linode (6)

• DigitalOcean (6)

• AWS EC2 (S)

• QingCloud/青云 (S)

• 腾讯云

备注

1. SAE 的 IPv6 的激活需要额外的月付
2. OVH 的 SSD VPS 暂时不支持 IPv6
3. 在购买某种配置时，若告知你是共享 CPU，那么还是共享 CPU
4. OVH 只有 Cloud VPS 是基于云端的 VPS
5. Google 官方并没有明确说明提供 DDOS 防御，但实际上是有能力防御的
6. Vultr 的 DDOS 防御需要额外购买，且仅部分地区支持，最大防御仅 10Gbps

在上一篇文章中，我简单的介绍了 Google Compute Engine（简称 GCE）的基础使用。这篇文章我将介绍如何利用 GCE 建立一个 Anycast 网络，并测试了其速度。 想要实现这个功能，就需要使用 Cross-Region Load Balancing（跨地区的负载均衡），此功能就相当于一个 HTTP(S) 的反向代理，所以只能针对 HTTP/HTTPS 请求进行负载均衡。

简要概述

GCE 上所实现的这个功能是基于第七层的网络代理，所以其拓扑图是这样的： 用户 —> 边缘服务器 —> 实例

• 用户到边缘服务器之间的连接：使用 HTTP 或 HTTPS；如果是 HTTPS 连接，那么 TLS 加密过程是在边缘服务器上实现。
• 边缘服务器到实例的连接：使用 HTTP 或 HTTPS 连接，之前的网络是走的 Google 的专线。

不论配置了几个位置的实例，边缘服务器都是使用 Google 全部的边缘服务器。 启用这个功能后，就会得到另一个 Anycast 的 IP 地址，这是个独享的 IP 地址。

什么是 Anycast？Anycast 能够让多个主机使用一个 IP 地址，当用户连接这个 IP 地址的时候，连接到的只是这多个主机中的其中之一，通常会选择最快的线路，能有效的降低延迟，所以很多 DNS/CDN 提供商都使用了 Anycast。

此外，目前使用负载均衡是唯一能让其原生支持 IPv6 的方法。具体可以参见其文档：IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing

配置方法

建立实例

首先，需要前往到 GCE 后台，建立至少两个不同地区的实例，我专门为测试 Anycast 功能建立了两个新的实例：

每个地区也可以建立多个实例以提高可用性，而我只给每个地区建立了一个实例，这两个实例分别叫 anycast-asia 和 anycast-us。

建立实例组

然后，需要给每个地区的实例建立一个实例组：

需要注意的是，实例组配置页面中位置里的 “多地区（Multi-zone）” 是指同一个地区（Region）的不同可用区域（Zone），而不是多个不同的地区，所以这实际上是翻译的错误，应该叫做 “多可用区域” 才对。

刚接触云服务的人可能不理解可用区域的概念，可以参考 AWS 的这篇文章来理解。简单点说，地区这个概念就是指离得很远的地区（比如城市之间，如北京和上海），所有在北京的服务器都算北京地区，所有在上海的服务器都算上海地区。但是为了能达到更高的可用性，通常还会在同一个地区设立多个数据中心，也就是可用区域。这些可用区域虽在一个地区中，其之间的距离可能相隔几十甚至几百公里，但这些可用区域之间的距离和不同地区之间的距离相比起来要小得多，所以这些可用区域之间的网络延迟也很低。

设立多个可用区域的意义是：可以能加更高的可用性（主要是为了避免外界因素：比如说火灾等），虽然是异地分布，但是可用区域之间的距离并不远，所以网络延迟可以忽略。

我只给每个地区建立了一个实例，所以我只需要选择 “单地区（Single-zone）”。每个地区都需要建立一个实例组，所以一共需要建立两个（或更多的）实例组。我配置了两个实例组，分别叫 asia-group 和 us-group。

建立负载均衡

完成前两步之后，就需要建立负载均衡的规则了，需要选择 “HTTP(S) 负载平衡” 来实现 Anycast 的功能。

在负载均衡的配置界面，把这两个实例组都添加到 “后端” 中。 该功能还需要创建一个运行状态检查（相当于监控功能），当主机宕机后能实现切换。

创建成功后，可以看到如下界面，其中的 IP 地址就是 Anycast IP 了。

Nginx 的配置

这里的配置只是为了方便调试，实际使用不用额外修改 Nginx 的配置。 在这两个主机上都安装 Nginx，然后稍微改动默认的配置文件：增加两个 Header，然后 Reload。

add_header X-Tlo-Hostname $hostname always;add_header Cache-Control "max-age=36000, public";

检测是否可用

在测试 Anycast 之前，先测试这两个主机是否存在问题。为了方便阅读，我将 curl 的 IP 地址换为主机名，并省略两个主机都相同的 Header 字段

$ curl anycast-us -IHTTP/1.1 200 OK…ETag: "57ef2cb9-264"X-Tlo-Hostname: **anycast-us**$ curl anycast-asia -IHTTP/1.1 200 OK…ETag: "57ef2b3b-264"X-Tlo-Hostname: anycast-asia

可以看到这两个主机都没有什么问题。然后，我用我的电脑去测试那个 Anycast IP：

$ curl anycast-ip -IHTTP/1.1 200 OK…ETag: "57ef2b3b-264"X-Tlo-Hostname: anycast-asiaAccept-Ranges: bytesVia: 1.1 google

可以看到，这是 anycast-asia 主机响应的。现在我使用另一个在美国的主机继续测试这个 Anycast IP：

$ curl anycast-ip -IHTTP/1.1 200 OK…ETag: "57ef2cb9-264"X-Tlo-Hostname: anycast-usAccept-Ranges: bytesVia: 1.1 google

此时就是 anycast-us 主机响应的，是因为客户端离这个服务器更近。 当通过 Anycast IP 访问时，就可以看到 HTTP Header 中的 Via: 1.1 google 字段。

速度测试

Ping 测试

Ping 测试发现速度很快，看来反代的操作是放在 Google 的边缘服务器上了。速度堪比 Google 啊！

中国的速度那更是一流的快，Google 有香港的边缘节点，所以基本上是直接走的香港节点，比原本的连接台湾可用区快不少。（只有部分 IP 段是完全直连的）

HTTP GET 测试

在开启 CDN 功能之前，负载均衡器是不会对任何内容缓存的，所以会发现 Connect 的速度很快，但是 TTFB 延迟还是有不少。

可以预测，如果启用了 HTTPS 功能，其 TLS 所需要的等待时间也会很短，TTFB 时间不变，总时长不会延长太多。

开启 CDN 后进行 HTTP GET 测试

当将 CDN 开启后，负载均衡器就会自动地对静态资源做缓存了，当缓存命中后会显示 Age 字段，这个字段是表示自缓存命中了，后面的数字代表这是多少秒之前缓存的内容。

curl anycast-ip -I
HTTP/1.1 200 OK
…
Via: 1.1 google
Age: 10

经过多次执行这个指令，会发现有一定几率 Age 字段消失，这可能是流量指到了同一个地区的不同可用区上。但总之，是缓存命中率不高，即使之前曾访问过了。

多次运行测试确保有缓存之后，发现速度似乎并没有太多明显的提升。能够明显的看出改善的是：巴黎和阿姆斯特丹的 TTFB 延迟从 200ms 减少到了 100ms，然而还是不尽人意。可能的原因是：Google 并没有将内容缓存到离访客最近的边缘节点上，而是别的节点上。 CDN 缓存服务器的位置列表

统计与日志

开启了 Load Balancing 后，就会自动在 Google Cloud Platform 下记录一些信息了。

实时流量查看

在网页后台的 Network，Load balancing，advanced menu 的 Backend service 下，可以查看实时的流量情况：

延迟日志

在网页后台的 Stackdriver，Trace 下，可以看到延迟日志：

这里的延迟包含了网络延迟和服务器响应延迟

总结

GCE 所能实现的 Anycast 功能，只能通过 HTTP 代理（第七层）的方式实现，所以只能代理 HTTP 请求，其他功能（如 DNS）无法实现。所以很多功能受限于负载均衡器的功能（比如证书和 HTTP2 都需要在负载均衡器上配置），然而由于 TLS 加解密过程是在边缘服务器上实现，而且其本身也带有 CDN 功能，所以会比单纯的 Anycast（比如基于 IP 层，或是 TCP/UDP 层）的更快一些。

价格

前五个 Rules $18/月，流量费用相比 GCE 不变，已经被缓存的内容的流量有一点优惠。

对比

Cloudflare

通过使用 Cloudflare 所提供的服务也能实现 Anycast，也是基于第七层的，即将也能实现 Cross-Region Load Balancing 的功能。虽然它还不能根据主机的 CPU 占用率去调整权重（毕竟它拿不到这些数据），却有强大的 Page Rules 功能以及 WAF 功能。 CloudFlare 并不提供独立 IP 地址，不过这不是什么大问题。 由于它属于第三方服务，不受服务提供商的限制，于是就可以给多种不同的服务提供商去做 Anycast 功能；而且无论服务商是否支持，都能够使用。 连接速度上，GCE 的在中国连接速度有明显的优势。

BuyVM

BuyVM 是一家 VPS 提供商，却提供免费的 Anycast 功能，其 Anycast 功能是直接基于 IP 层的 Anycast，所以可以配置 HTTP 之外的各种服务。BuyVM 没有所谓的边缘服务器一说，只能有三个节点，Ping 的结果不像前两家那么快，而且 TLS 过程也是在原本的主机（这三个主机中里用户最近的一个）上进行，也会有一定延迟。 BuyVM 并不提供任何亚洲的主机，所以中国的连接速度也没有比 Cloudflare 快多少，整个亚洲的速度也不是很快。

2017 年 4 月更新：由于 GCE 在国内经常不稳定，本站主机已经换到了 TlOxygen 的虚拟主机上了。 最近想要寻找按流量计费、连接中国速度比较快的 VPS，最终选择了 Google Compute Engine（下文简称 GCE）的亚洲区。GCE 的后台配置页面虽不能在中国访问，但是其 GCE 实例是可以在中国访问的。 创建一个新的 GCE 的流程十分简单，只需要自定义配置、选择操作系统、配置 SSH Key，然后选择创建就好了，整个流程十分像 VPS，但是可自定义的功能却远比 VPS 多。

价格与配置

具体价格请参见官方价格表。（由于有持续使用折扣，每月实际价格比按照每小时更低） GCE 的价格比较亲民，最低配 (f1-micro) 1 共享核-0.6 GB 内存-10GB HDD 每月只需要不到 5 美元，而且由于 CPU、内存大小和磁盘大小都是可调的，所以可以根据自己的需要去购买最适合的，能省去不必要的开销。 而且对于北美的部分机房而言，账户首个最低配 (f1-micro) 实例可以享受到永久免费配额，对于建站而言 (再配合 Cloudflare 使用) 还是很划算的。流量的话对于所有的可用区，连中国大陆 $0.23/Gbyte、美欧地区 $0.12/Gbyte，流量的价格有些小贵，但是如果是连接 Google 自己的服务的话（包括但不限于 Gmail、YouTube），流量不计费（但是流量是双向的，所以是本地通过 GCE 上传完全免费，下载还是原价）。 GCE 还有一点比较特殊的是它是按分钟计费的，当服务处于终止状态（相当于关机，磁盘数据保留）时，不收取费用（除了少量的磁盘使用费用）。每次计算 Uptime 时，如果不到 10 分钟则一律按十分钟算，超过 10 分钟后才是真正的按分钟计费，不过还是很划算了。

关于共享核的实例的补充

f1-micro（0.6 GB）和 g1-small（1.7GB）这两个版本使用的是共享核心（其余配置都是独立核心），根据 Google 的说明，0.60GB 是 0.2 vCPU，1.70GB 是 0.5 vCPU。但是却支持 Bursting，也就是短时间内最高能使用到 1.0 vCPU。 那么 1.0 vCPU 是多少呢？查 cpuinfo，是 Intel(R) Xeon(R) CPU @ 2.50GHz。也就是说这两个版本最高能占用到 2.5GHz。但是假如长时间占用，速度就会压缩到 0.5GHz 和 1.75 GHz。

我的 f1-micro 装了监控软件，对比 GCE 给的 CPU 占用率（深蓝色）和系统自己监控到的占用率（浅蓝色），发现 GCE 图表上统计的 CPU 占用率正好是本地统计的 5 倍，也就是说如果本地看到的 CPU 占用是 20%，GCE 图表上显示的就正好是 100%，本地为 20100%，GCE 图表上就是 100500%，这时就算作 Bursting 了。 和其他 VPS 对比，其他的 VPS 也几乎都是共享核心，但你却无从判断是否超售。比如有 10 个用户共用一个核心，如果那 10 个人都在不停的占用 CPU，那么你的 CPU 速度会低于单核的十分之一。而 Google 的共享核心，保证了一个最低的速度（0.2 vCPU 和 0.5 vCPU），就算其他用户用的再狠，也能给你保证一定的速度。

使用流程以及配置方法

首先需要前往创建实例的页面，然后进行配置

基础配置

其他一些选项配置介绍

• “抢占”：该模式能够获得更低廉的价格，但是不能用做需要长期保持在线的服务（比如 Web 服务），它最长的使用期限是 24 小时，然而在我的使用中，它有时候不到 1 小时就会被终止使用。它只适合短时间去计算一些东西，计算完后中止它，平常的一般使用不要开启此功能。
• 自动重启：推荐开启，以获得在云端的好处，以及更好的 Uptime
• 主机维护期间：推荐选择 “迁移”，原因同上
• IP 转发：建议关闭，几乎不会用得着此功能，关闭有助于提高安全性
• SSH：这可能不同于其他一些 VPS，它默认不自动生成用户密码，所以为了远程登录必须配置好公钥私钥。而且所填写的公钥末尾的用户名是有作用的，所填写的用户名就是所需要登录的用户名，默认不支持 root 登陆，除非你将用户名设置成了 root。

防火墙配置

GCE 默认开启了防火墙且不能关闭，只能允许你自己指定的协议和端口的流量；经过我自己的实际测试，GCE 能够自动过滤相当的 DDOS 攻击流量。 由于防火墙不能关闭，所以不能配置类似 IPv6 Tunnel 的服务，所以导致目前的 GCE 是不能够支持 IPv6 的，不过相信以后 Google 还是会启用 IPv6 支持。 在 “网络” 里，可以找到防火墙规则，然后可以添加防火墙规则。 默认已经允许了 SSH 和 ICMP 等（以 default 开头的）

我只需要另一个主机去访问 SNMP 监控，不需要将其公开到互联网上，所以限制了 IP。

有的 DNS 请求是通过 TCP 发送的，所以需要同样启用 TCP 请求。 如果配置了目标标记，那么就不是默认应用到所有实例的防火墙规则，还需要在实例上配置好同样的标记才可以。

网络——如同 Google 自身一样棒

由于 GCE 是 Google 的，其网络其实也是 Google 的 AS15169，于是不用想也知道连接 Google 旗下的服务会很快，但是实际使用后发现远比我想象的快，GCE 连接 Google 的服务简直就像内网一样。

$ ping google.comPING google.com (74.125.203.102) 56(84) bytes of data.64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=1 ttl=53 time=0.631 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=2 ttl=53 time=0.433 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=3 ttl=53 time=0.330 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=4 ttl=53 time=0.378 ms64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=5 ttl=53 time=0.413 ms^C--- google.com ping statistics ---5 packets transmitted, 5 received, 0% packet loss, time 3999msrtt min/avg/max/mdev = 0.330/0.437/0.631/0.103 ms

要是 traceroute 的话就更神奇了：

$ traceroute google.comtraceroute to google.com (64.233.189.113), 64 hops max  1   64.233.189.113  0.826ms  0.313ms  0.435ms

中国目前连接 GCE 亚洲区的速度还算不错，按流量计费，实际测试能够超过 100M 带宽。亚洲区的位置在台湾，中国连接通常会绕香港，然后从香港到台湾这条路线走的是 Google 自己的骨干网，所以最终的结果只是比香港服务器慢了十几毫秒而已。

其他国家连接的话优势就更明显了，Google 的网络实在太强大，无论是亚洲还是欧美，几乎还没有出这个城市/国家就立即跳进 Google 的骨干网络里了，然后 Google 自身的骨干网的选路通常要比运营商的选路要好一些，几乎不会出现绕路的情况。

配置 Anycast

详细内容已在下一篇文章中介绍，通过 Load Balancing 可以分配到一个独立的 IPv4 地址，还能够有原生的 IPv6，支持 CDN 和 HTTPS。Google 的 Anycast 有多快？和 Google 一样快。

内部网络互通

每个实例都有其对应的内网 IP，方便两个主机间建立直接的连接，这个内网 IP 的神奇之处在于：它可以跨可用区使用，包括跨大洲。经过实际测试，使用内网 IP 建立的连接速度会稍快，而且收取的价格（如果是跨州的话）也有优惠。

功能

统计功能

在 GCE 的后台，能够显示长达 30 天的 CPU 利用率、磁盘字节数、磁盘操作字节数、网络字节数、网络数据包量等数据，都能够精确到分钟级别的记录，而且是实时更新的。

快照

你可以为主机增加快照，方便在其他实例中恢复快照，或者用做备份功能。GCE 的快照是增量备份，这意味着如果有两个快照，第二份快照只备份与第一份快照的差异部分。使用这个脚本可以实现自动备份，并且能够实现到期自动删除老备份。

附加硬盘

你可以轻松的添加任意（大于 10 GB）大小的硬盘，有多种磁盘种类可供选择。经过我的测试，如果执行长时间的高 I/O 操作，硬盘读写速度会明显地降低。而且并不一定 SSD 就比 HDD 快，硬盘的大小与吞吐量限制和随机 IOPS 限制呈正相关，也就是说 40G 的 HDD 的速度相当于 10G 的 SSD。

适用场景

低配置的版本用来建站或者是当 “梯子” 都很不错，每月 5 美元的价格还是很吸引人的（做 “梯子” 的一定要注意流量价格！）。已经相当完善的 Web 控制页面可以大大降低使用和学习的门槛。高配置的版本拥有独立 CPU，而且可伸缩性很大。与 Google Cloud 各种功能配合使用，可以搭建大型网站或者游戏服务器。

GCE 的一些坑

下面来讲一讲它的一些坑，尤其是从传统 VPS 转到 GCE 会遇到的一些问题。由于 GCE 是基于云端的，所以有很多东西都不太一样。

主机的外网 IP 并不是直接分配的

GCE 虽然是提供独立 IP 的，但是当你执行 ifconfig -a 时，你会看到默认分配的 IP 是一个内网的保留 IP（形如 10.123.0.1），这是为了方便 instance 里之间互相连接的 IP。当你配置一些需要外网的服务要 bind 到指定 IP 时，你只需要 bind 到这个 IP 即可，所分配给你的外网 IP 会自动将流量转发到这个 IP 上。而且，你的主机并不知道那个外网 IP 就是主机本身，所以所有发向主机对应的外网 IP 的流量都会经过一个路由器，然后再由路由器返回，并且会应用防火墙策略。所以，如果需要本地的通讯，建议尽量多使用环回地址（如 127.0.0.1，::1）或那个内网地址。

防火墙

不能关闭的防火墙对于初次接触的人来说可能有些不适，不过一旦习惯后便会爱上这个功能，这个基于在路由器上的防火墙功能要比在 iptables 里做限制更方便。强烈建议利用好防火墙功能，不要默认允许所有端口。比如你的网站流量全部经过 Cloudflare，那么就可以通过防火墙来只允许 Cloudflare 的 IP 与你的主机连接。

不支持多 IP 与 IPv6

GCE 上不能通过加钱的方式去购买多个 IPv4 地址，所以一个实例只能有一个 IPv4 地址，需要多个 IPv4 需求的可以尝试多个实例（或者可以通过 Load Balancing 来实现多个 IP 地址）。 同时，GCE 目前不支持 IPv6，这实在是很可惜的。目前已经可以通过负载均衡器来实现 IPv6。

最近我越来越喜欢自建一些东西，比如 GitLab。今天我又把 DNS 服务器改成自建的了，分享一下经验（PS：现在为了实现根域名 CDN，我用换成了 Route 53）：

本文的自建 DNS 是指的是权威 DNS，即给自己的域名配置的 DNS，而非在客户端配置的缓存 DNS。

优缺点

首先，我先说用自建 DNS 服务器的致命坏处：

1. 如果那天自己的服务器挂了，整个域名相关服务都会挂，即使你邮件收信服务器是用的是第三方的，你也不能收信了
2. 基本上必须是开放端口，并有固定 IP（而且最好还需要至少两个 IP） 的 VPS（当然也可以是两个主机，只需要保证配置文件完全相同即可），对于服务提供商要求高
3. 个人一般关于 DNS 运维经验不足，容易导致配置错误
4. 第三方 DNS 提供商基本都有 DDOS 防御，而你的服务器可不一定有，攻击者可以直接通过 L7 DNS Flood 攻击掉你的服务器，然后又回到第一个问题上了

使用自建 DNS 服务器优点：

1. 可 DIY 程度极大，各种 DNS 方面功能几乎都能配置，但却又都十分复杂
2. 可以建在已有的服务器上，不用额外花钱

最终我还是选择了使用 PowerDNS 软件（这其实也是很多提供 DNS 服务的服务商所使用的），我安装它的最近才出的 4.0 版本，这个版本支持的一些特性：

• EDNS Client Subnet
• DNSSEC
• GEODNS
• IPv6

等等，以上只是我想到的。同时 PowerDNS 支持超多的解析记录种类（至少是我目前见过最多的）：A、AAAA、AFSDB、ALIAS（也是 ANAME）、CAA、CERT、CDNSKEY、CDS、CNAME、DNSKEY、DNAME、DS、HINFO、KEY、LOC、MX、NAPTR、NS、NSEC、NSEC3、NSEC3PARAM、OPENPGPKEY、PTR、RP、RRSIG、SOA、SPF、SSHFP、SRV、TKEY、TSIG、TLSA、TXT、URI 等，还有不常用的没有列出来，见所有支持的记录。说实话有一些冷门的记录很多解析商都不支持，但我又需要用，比如 LOC、SSHFP 和 TLSA。不知道这一堆记录是干什么的？请见维基百科。

简述安装过程

详情安装方法见官方文档，需要先安装 pdns-server ，然后再安装 pdns-backend-$backend 。Backend 是你可以自己选的，常用的有 BIND 和 Generic MySQL ，需要 GEODNS 可以用 GEOIP ，所有列表见此。如果想做网页版控制后台，使用 MySQL 的可能比较方便。如果只是通过文件形式控制，那么 BIND 和 GEOIP 都可以。 我使用 GEOIP 版本的，GEOIP 版本可拓展性强，使用 YAML 文件，更灵活、优雅，本文就讲讲 GEOIP 版本： 在 Ubuntu 上安装（系统软件源里就有）：

$ sudo apt install pdns-server
$ sudo apt install pdns-backend-geoip

然后修改配置文件：

$ rm /etc/powerdns/pdns.d/* # 删除 Example

安装更新版本的 PowerDNS

很多特性，如 CAA 记录等，需要新版 PowerDNS。请前往官网配置软件源。

安装地理位置数据库

注意，你应该已经有 MaxMind GeoIP Lite 数据库，如果没有，通过如下方式安装：

重要更新⚠️：2018 年 4 月 1 日起已经无法通过软件自动下载到 DAT 格式的 GeoIP 数据库，请前往官网手动下载对应数据库。需要的是 Binary 格式的。

创建文件 /etc/GeoIP.conf 内容是：

# The following UserId and LicenseKey are required placeholders:UserId 999999LicenseKey 000000000000# Include one or more of the following ProductIds:# * GeoLite2-City - GeoLite 2 City# * GeoLite2-Country - GeoLite2 Country# * GeoLite-Legacy-IPv6-City - GeoLite Legacy IPv6 City# * GeoLite-Legacy-IPv6-Country - GeoLite Legacy IPv6 Country# * 506 - GeoLite Legacy Country# * 517 - GeoLite Legacy ASN# * 533 - GeoLite Legacy CityProductIds 506 GeoLite-Legacy-IPv6-CountryDatabaseDirectory /usr/share/GeoIP

然后安装 geoipupdate，执行 sudo apt install geoipupdate && mkdir -p /usr/share/GeoIP && geoipupdate -v ，你的数据库就已经下载完毕了。

配置 PowerDNS

创建文件 /etc/powerdns/pdns.d/geoip.conf 内容是：

launch=geoipgeoip-database-files=/usr/share/GeoIP/GeoLiteCountry.dat /usr/share/GeoIP/GeoIPv6.dat # 选择 IPv4 和 IPv6 国家模块geoip-database-cache=memorygeoip-zones-file=/share/zone.yaml # 你的 YAML 配置文件的位置，随便哪个地方都行geoip-dnssec-keydir=/etc/powerdns/key

创建那个 YAML 文件，然后开始写 Zone，这是一个例子（IPv6 不是必须的，所有 IP 应该都填写外部 IP，本文以精确到国家举例，并列内容的顺序无所谓）：

# @see: https://doc.powerdns.com/md/authoritative/backend-geoip/domains:- domain: example.com  ttl: 300 # 默认 TTL 时长  records:##### Default NS    ns1.example.com:      - a: # 你的服务器的第一个 IPv4 地址          content: 10.0.0.1          ttl: 86400      - aaaa: # 你的服务器的第一个 IPv6 地址          content: ::1          ttl: 86400    ns2.example.com: # 你的服务器的第二个 IPv4 地址（如果没有就和上面一样）      - a:          content: 10.0.0.2          ttl: 86400      - aaaa: # 你的服务器的第二个 IPv6 地址（如果没有就和上面一样）          content: ::2          ttl: 86400##### Root domain    example.com: # 根域名下的记录      - soa:          content: ns1.example.com. admin.example.com. 1 86400 3600 604800 10800          ttl: 7200      - ns:          content: ns1.example.com.          ttl: 86400      - ns:          content: ns2.example.com.          ttl: 86400      - mx:          content: 100 mx1.example.com. # 权重 [空格] 主机名          ttl: 7200      - mx:          content: 100 mx2.example.com.          ttl: 7200      - mx:          content: 100 mx3.example.com.          ttl: 7200      - a: 103.41.133.70 # 如果想使用默认 TTL，那就不用区分 content 和 ttl 字段      - aaaa: 2001:470:fa6b::1##### Servers list 你的服务器列表    beijing-server.example.com: &beijing      - a: 10.0.1.1      - aaaa: ::1:1    newyork-server.example.com: &newyork      - a: 10.0.2.1      - aaaa: ::2:1    japan-server.example.com: &japan      - a: 10.0.3.1      - aaaa: ::3:1    london-server.example.com: &uk      - a: 10.0.4.1      - aaaa: ::4:1    france-server.example.com: &france      - a: 10.0.5.1      - aaaa: ::5:1##### GEODNS 分区解析    # @see: https://php.net/manual/en/function.geoip-continent-code-by-name.php    # @see: https://en.wikipedia.org/wiki/ISO\_3166-1\_alpha-3    # unknown also is default    # %co.%cn.geo.example.com    # 默认    unknown.unknown.geo.example.com: *newyork # 默认解析到美国    # 洲    unknown.as.geo.example.com: *japan # 亚洲解析到日本    unknown.oc.geo.example.com: *japan # 大洋洲解析到日本    unknown.eu.geo.example.com: *france # 欧洲解析到法国    unknown.af.geo.example.com: *france # 非洲解析到法国    # 国家    chn.as.geo.example.com: *beijing # 中国解析北京    gbr.eu.geo.example.com: *uk # 英国解析到英国  services:    # GEODNS    www.example.com: [ '%co.%cn.geo.example.com', 'unknown.%cn.geo.example.com', 'unknown.unknown.geo.example.com']

这个配置，就相当于把 www.example.com 给分区解析，由于目前这个解析存在一些问题，导致不能同时在根域名和子域名下设置 GEODNS，这个 Bug 我已经提交反馈了。 如果你想只把解析精度设在洲级别，那么就直接 %cn.geo.example.com 这样少写一级就行了。如果你需要精确到城市，那么多写一级就行，但是需要在配置文件中添加 GeoIP 城市的数据库。然而免费的城市数据库的城市版本并不精准，你还需要去购买商业数据库，这又是一个额外开销。

配置域名

前往你的域名注册商，进入后台修改设置，给域名添加上子域名服务器记录，如图：

由于要设置的 NS 是在自己服务器下的，所以务必要在域名注册商上向上级域名（如 .com）注册你的 NS 服务器 IP 地址，这样上级域名就能解析道 NS 的 IP，自建 DNS 才能使用，比如 icann.org 下就有一个属于自己的 NS：

$ dig icann.org ns +shorta.iana-servers.net.b.iana-servers.net.c.iana-servers.net.ns.icann.org.

然后再看它的上级域名 org：

$ dig org ns +shorta2.org.afilias-nst.info.b0.org.afilias-nst.org.d0.org.afilias-nst.org.c0.org.afilias-nst.info.a0.org.afilias-nst.info.b2.org.afilias-nst.org.

随便找一个服务器，查询权威记录（我就不用 +short 了）：

$ dig @a0.org.afilias-nst.info icann.org ns;; QUESTION SECTION:;icann.org.INNS;; AUTHORITY SECTION:icann.org.86400INNSc.iana-servers.net.icann.org.86400INNSa.iana-servers.net.icann.org.86400INNSns.icann.org.icann.org.86400INNSb.iana-servers.net.;; ADDITIONAL SECTION:ns.icann.org.86400INA199.4.138.53ns.icann.org.86400INAAAA2001:500:89::53

可以看到，在这个 org 的 NS 服务器就已经把 ns.icann.org. 的记录返回来了，这也就是你需要在域名注册商填写 IP 地址的原因。然而你最好在你域名下的 DNS 服务器上也返回相同的 NS 和相同的 IP。 最后，不要忘了改域名的 NS 记录。

YAML 的一些高级写法

我刚才的 YAML 中其实就已经用到了 YAML 的高级写法，就是 &variable 设置变量，*variable 使用变量，这很像 CloudXNS 下的 LINK 记录，比如在 CloudXNS 下你可以这么写：

www.example.com    600   IN    A       10.0.0.1www.example.com    600   IN    A       10.0.0.2www.example.com    600   IN    AAAA    ::1www.example.com    600   IN    AAAA    ::2sub.example.com    600   IN    LINK    www.example.com

然后在你的 YAML 记录里就可以这么写：

www.example.com: &www  - a: 10.0.0.1  - a: 10.0.0.2  - aaaa: ::1  - aaaa: ::2sub.example.com: *www

这就是 YAML 的一种高级写法，不需要其他额外支持。

添加 DNSSEC 支持

详情可以参考文档，运行以下指令：

$ mkdir /etc/powerdns/key$ pdnsutil secure-zone example.com$ pdnsutil show-zone example.com

最后一个指令所返回的结果就是你需要在域名注册商设置的记录，不推荐都设置，只设置 ECDSAP256SHA256 - SHA256 digest 就行了。 最后在线检查设置即可 测试地址1 测试地址2，可能有几天缓存时间。 我的检查结果

其他一些有趣的东西

你可以在 YAML 里写上这个，为了方便你调试：

"*.ip.example.com":  - txt:      content: "IP%af: %ip, Continent: %cn, Country: %co, ASn: %as, Region: %re, Organisation: %na, City: %ci"      ttl: 0

这些变量都能作为你 GEODNS 的标准，也可以检查你的 GEOIP 数据库情况。 然后，正确检查的姿势：

$ random=`head -200 /dev/urandom  md5` ; dig ${random}.ip.example txt +short"IPv4: 42.83.200.23, Continent: as, Country: chn, ASn: unknown, Region: unknown, Organisation: unknown, City: unknown"

IP 地址就是 DNS 缓存服务器地址（如果你开启了 EDNS Client Subnet，且缓存服务器支持，那么就是自己的 IP，但是如果使用 8.8.8.8，那么会看到自己的 IP 最后一位是 0），如果你在本地指定了从你自己的服务器查，那就直接返回你自己的 IP 地址。由于我只安装了国家数据库，所以除了洲和国家之外其余都是 Unknown。

进阶使用

建立分布式 DNS

一般情况下，是一个 Master 和一个  Slave 的 DNS 解析服务器，但是这样的话对 DNSSEC 可能有问题，于是我就建立了两个 Master 服务器，自动同步记录，并设置了相同的 DNSSEC Private Key，好像并没有什么错误发生（毕竟包括 SOA 在内的所有记录也都是完全一样的），我的服务器目前的配置

$ dig @a.gtld-servers.net guozeyu.com;; QUESTION SECTION:;guozeyu.com.INA;; AUTHORITY SECTION:guozeyu.com.172800INNSa.geo.ns.tloxygen.net.guozeyu.com.172800INNSc.geo.ns.tloxygen.net.;; ADDITIONAL SECTION:a.geo.ns.tloxygen.net.172800INA198.251.90.65a.geo.ns.tloxygen.net.172800INAAAA2605:6400:10:6a9::2c.geo.ns.tloxygen.net.172800INA104.196.241.116c.geo.ns.tloxygen.net.172800INAAAA2605:6400:20:b5e::2

其中是两个 IPv4 两个 IPv6，其中 a.geo.ns.tloxygen.net. 是使用了 Anycast 技术的 IP 地址，其背后由三台服务器提供。c.geo.ns.tloxygen.net. 属于另一家服务商的主机，这样一个挂了之后还有备份，更加稳定。

Anycast or Unicast?

像我这种分布式的 DNS，其实是 Unicast 和 Anycast 的组合，这样存在的一个问题就是在一个地方连接其中一个会比较快，但是另一个会比较慢。只有在用支持异步查询，或者是带 GeoIP 的 DNS 缓存服务器，才有可能连接到最快的 DNS 权威服务器，其他情况下则是随机连接，而且如果一个服务器挂掉了，那么服务器对应的 IP 就废了。 Anycast 是一个 IP 对应多个主机，然而我却没有条件用，这个对于个人来说也许成本会比较高，要么你自己有 AS 号然后让主机商给你接入，要么你的主机商提供跨区域的 Load Balancing IP。我的 VPS 在两个不同的主机商，也没有 AS，就不能用 Anycast 了。我觉得 DNS 服务如果可能还是要用 Anycast，因为 DNS 服务器对应的 IP 不能 GEODNS（因为这是根域名给你解析的），使用 Anycast 后就基本能保障最快的连接速率，并且一个服务器挂了 IP 还能用。此外，DNS 必须要同时转发 TCP 和 UDP 的 53 端口。

宕机自动切换

如何实现宕机自动切换？实现这个的流程是： 监控服务发现宕机 -> 向服务器发送已经宕机的请求 -> 服务器对宕机处理，解析到备用 IP/暂停解析 监控服务发现服务正常 -> 向服务器发送服务正常的请求 -> 服务器对服务正常处理，恢复解析 可以建立两个 YAML file，一个是默认使用，一个是服务器宕机时使用的，当监控服务发现服务器宕机后，重新加载另一个 YAML file，然后这就是宕机模式了。

我的服务器上部署的代码、配置文件等内容大多是使用 Git 进行版本控制。为了能够使用、配置起来更方便，通常使用一整套系统去管理。很显然，在一些代码和配置文件里会有一些机密的内容，如一些密钥什么的，所以必须不能公开。GitHub.com 虽然提供了 Private 存放处功能，但是由于此功能是付费的，而且对于 Organization 的 Plan 还是极贵，并不十分划算；就算能有免费的 Private 存放处，把自己的很多重要的密钥放在第三方服务器上还是很不安全，所以能够 Host 在自己的主机上的，并且能够替代 GitHub.com 的软件/服务就是不错的选择。 本文将讲一下我在自己服务器上安装 GitLab 遇到的坑，进阶使用，包括使用 .gitlab-ci.yml 文件实现自动 Build，实时同步镜像到 GitHub。

能够 Host 在自己的服务器上的软件/服务其实有很多，比如 GitHub Enterprise，Bitbucket Server。不过再此还是推荐完全开源、免费、由社区维护的 GitLab Community Edition，没有任何限制，只是相比 Enterprise Edition 少了些本来也用不着的功能。

安装及遇到的坑

具体安装方法见文档，目前官方推荐的系统环境是 Ubuntu 16.04 LTS，安装起来非常简便，整个 Web 环境都会配置好。安装后的更多配置请参见文档。如果你的主机上跑了不只一个 Web 程序，那就需要对现有的 Web 软件做修改，需要参见官方的 Nginx 的配置文档。我的代码中使用了 sub_filter 来实现替换默认的标题，实现更好的 SEO，更加品牌化。 然后为了能达到更好的使用效果，还应该配置 SMTP 发件服务器，我使用的是 AWS SES；然后还需要一个支持 IMAP 的收件服务器实现 Reply by email，我使用的是 Gmail，收邮件的限制总比发邮件的限制少吧～这些的具体设置方法官方文档里都有。 安装后默认是允许注册的，如果你不想让外人注册，你需要直接去 Web 后台禁用。如果你想要开放注册，那么最好先想好新注册用户能干什么，比如和我一样：只允许新用户创建 Issues 和 Snippets，那就在 Web 后台将 Default projects limit 设置为 0，然后编辑后台的配置文件，禁止新用户创建 Group。同时建议在 Web 后台启用 reCAPTCHA 和 Akismet，防止恶意注册和恶意发 Issues。既然允许注册，那么也建议使用 OmniAuth 来支持第三方 OAuth 的方式登陆。

GitLab Runner

GitLab Runner 十分强大，但是并不是内置的，它可以极其方便的实现自动部署等非常有用的功能。安装配置好 Runner 后，在项目根目录下添加一个名为 .gitlab-ci.yml 的文件，以 master 分支为例，为了实现每次 commit 到 master 都将文件部署到 /var/gitlab/myapp ，那么文件内容应该是这样的：

pages:stage: deployscript:- mkdir -p /var/gitlab/myapp- git --work-tree=/var/gitlab/myapp checkout -fonly:- master

注意，你需要先创建 /var/gitlab 文件夹，并设置这个文件夹的用户组为 gitlab-runner:gitlab-runner

$ sudo chown -R gitlab-runner:gitlab-runner /var/gitlab

.gitlab-ci.yml 核心的部分就是 script: ，这里的脚本都是由用户 gitlab-runner 执行的，你可以根据需要修改，后文中也给了几种范例。 然后 commit，去设置页面里里激活这个项目的 Runner。建议在设置里设置 Builds 为 git clone 而不是 git fetch ，因为后者常常出现奇奇怪怪的问题，前者的速度瓶颈主要在于网络传输。

部署 Runner 在同一个主机上，Or not？

官方的文档里强烈不推荐把 Runner 部署在同一个主机上，其实这种说法并不正确。官方不推荐这样做是因为一些 build 会花费很长时间，占用很多的 CPU 和内存资源。但是如果你执行的 build 脚本并不会这样，那么安装在同一个主机上也未尝不可。

常见的部署范例

这几种部署是我比较常用的，大家可以当作范例，具体根据自己的需要弄各种不同的部署。 以下几种 Web 的部署方式所消耗的系统资源都不多，而且由于使用了 nice ，并不会阻塞其他任务，可以部署在同一台主机上。

Jekyll

修改之前那个 .gitlab-ci.yml 文件的 git checkout 一行，替换为：

jekyll build --incremental -d /var/gitlab/myapp

检查 PHP 的编译错误

也是添加以下代码到 .gitlab-ci.yml 即可自动检查所有 PHP 文件的编译错误，编译通过的文件不会显示，只会显示编译错误的：

if find . -type f -name "*.php" -exec nice php -l {} \;  grep -v "No syntax errors"; then false; else echo "No syntax errors"; fi

自动与 GitHub 同步

以下过程需要 root 权限登陆到主机，或者在每行命令前添加 sudo。 首先，需要先给 gitlab-runner 用户一个单独的 SSH Key：

$ ssh-keygen -f /home/gitlab-runner/.ssh/id_rsa

然后，创建 /home/gitlab-runner/.ssh/known_hosts ，内容是：

github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==

之后，获取 /home/gitlab-runner/.ssh/id_rsa.pub 文件内容，在 GitHub 上添加这个 SSH Key。 由于是使用 root 帐号，弄完了之后不要忘了修改用户组：

$ sudo chown -R gitlab-runner:gitlab-runner /home/gitlab-runner/.ssh

然后，同样是通过 .gitlab-ci.yml 实现自动同步：

git push --force --mirror git@github.com:[Organization]/[Project].git

修改 [Organization] 和 [Project] 为你自己的名称即可。

谈谈安装在自己服务器上的 GitLab 的好处

文件都存储在自己的服务器里，安全性比较有保障，自己有最高权限，不会遇到项目被删的情况。部署时延迟极低，可靠性也高，不会遇到自己服务器没问题但是第三方服务宕机导致无法部署的窘况。 可以根据情况部署到离自己最近的服务器，或者是内部服务器，像 GitHub 的服务器就在美国东岸，亚洲这边连接并不快，国内也不稳定。 最关键的是，如果你本来就有个 VPS 什么的，也有很大的空闲，那么相当于你可以免费获得私有存放处，但是要注意性能需求，没有足够的空闲还是不要启用。 由于能够配置好实时同步镜像到 GitHub，GitLab 还有那么多 GitHub 没有的功能，其实已经可以完全使用 GitLab 作为主要的版本控制工具，GitHub 只是存一份镜像备用。

本攻略适用于——

• 自建 mastodon（非大站）
• 使用 docker compose
• 将媒体文件直接保存在服务器上，而不使用 s3 外部存储

这个搭配虽然不多见，但其实用起来满爽的。很多人用的 s3 服务都是在薅羊毛，而 mastodon 那个变态的，把别人家的媒体文件缓存到自家的架构，流量的吞吐其实很大的（开了 relay 就更夸张），薅羊毛时很容易就超出了。反而是 vps 本身的流量上限很高。对于个人建站而言，媒体文件总量通常 <50GB，某些 vps 自带 200GB 硬盘，足够用了。

缺点是，除了数据库定期备份外，也要考虑媒体文件的异地备份问题。但其实只需要备份存储本地附件的 media_attachments，而 cache 是不需要备份的，所以工作量也不大。

两年前我把媒体文件转移到本地时，参照了 antisocial science 的设置。但因为我用 docker，官方默认的设置，docker 内外权限不一致，无法将媒体文件写到本地。于是匆匆又在本地建了个 minio s3 来中转……这样其实很浪费资源了，minio 的开销也不小。所以最近趁着搬家，又试了一下，终于把 docker + 本地存储 跑通了。

1. 在 docker-compose.yml 里，

web 和 sidekiq 容器中，已经预设了媒体文件的卷映射

volumes:
  - ./public/system:/mastodon/public/system

这个不用动。——也可以改成其它的路径，但要和后面的设置一致（本文用相同的颜色标明）。

2. 修改 .env.production

S3_ENABLED=false
PAPERCLIP_ROOT_PATH=/mastodon/public/system
PAPERCLIP_ROOT_URL=/fivestone-mastodon-media

PAPERCLIP_ROOT_URL 是服务器的所有媒体文件链接的子文件夹名称，形如：

https://mastodon.fivest.one/fivestone-mastodon-media/media_attachments/.../x.jpg

默认值是 /system；但是建议改成独特一些的名字，而且建议和 S3_BUCKET 一致。以后需要在本地存储和 s3 之间转换时，可以省一点心。（所以要独特一些，防止回头在 s3 上和别人撞名）

3. 修改 nginx 的域名配置文件

参照官方的配置，把域名文件夹里的 proxy_pass ，直接改成本地的 alias

server 
{
  server_name mastodon.fivest.one;
# ......

  location /fivestone-mastodon-media/
  {
    alias /path-to...docker-compose-folder/public/system/ ;

    proxy_cache CACHE;
    proxy_cache_valid 200 48h;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_lock on;

    expires 1y;
    add_header Cache-Control public;
    add_header 'Access-Control-Allow-Origin' '*';
    add_header X-Cache-Status $upstream_cache_status;
    add_header X-Content-Type-Options nosniff;
    add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
  }
}

然后重启 nginx

sudo systemctl reload nginx.service

4. 通过 docker 设置媒体文件夹的权限

在 docker 内部，是以 mastodon 用户的身份，来运行程序的，所以要把媒体文件夹的所有者改成（docker 内部的）mastodon：

sudo docker-compose run --user=root --rm web chown -R mastodon /mastodon/public/system

如果是从 s3 迁移到本地，把媒体文件移入这个本地文件夹（/path-to…docker-compose-folder/public/system/）后，也要再执行一遍上面这条命令。

或者在 mastodon docker 服务已经启动的情况下，执行：

sudo docker exec -u 0 mastodon_container_web chown -R mastodon /mastodon/public/system

但在这条命令执行结束之前，mastodon 在后台写入媒体文件时，仍然可能出现文件夹权限不足，无法写入的问题。