本来不想取这个标题，因为它第一眼看上去有一种炫耀的情绪在里面。甚至连这篇文章都犹豫了很久要不要写，犹豫的原因无外乎读者可能会有下面几种看法：

1. 作为一个工作多年的人，还对考研成绩念念不忘，是不是说明考研之后的人生太失败？
2. 这种文章写出来会不会像现在满大街的鸡汤文一样，都是正确的废话？

为什么又决定还是写下这篇文章呢？

首先是我想写一系列回忆过去的文章，从中思考“我是怎么成为现在的我”这个哲学命题，考研虽然只是一件小事，但仍有值得记住和总结的地方。其次，考研一结束，这个事情就被我抛在脑后，几乎忘掉，近年来各种关于“认知”、“精进”、“学习”的自媒体非常火爆，但是读了这些看上去非常高大上的文章之后，我才发现其实我在考研中其实就用到了很多相关的方法，只是当时并不自知，因此也值得回忆和总结一下。

这篇文章没有什么实际内容，请谨慎点开，不要浪费自己的时间。我就是想测试一下在手机上写一篇博客的感觉如何，能否达到以前使用动态博客程序时的体验。

几年前，在以 Hexo、jekyll 为代表的各种静态博客生成系统百花齐放的时候，我写过一篇继续留在Typecho。并不是因为我非常守旧，而是经过实际使用测试之后，我认为不管这些静态生成器宣传的多么天花乱坠，它们实际上就是很难用，体现在安装、发布的各个方面。而它们的那些优点并不能让我忽略这些缺点。

直到我遇到了 Hugo。

在去年下半年发现了 Hugo 后，我毫不犹豫的写了个脚本将之前所有的文章全部迁移了过来。仅凭它的无依赖和执行速度，就甩开它的那些前辈们好几个身位。

这些年来，由于 Go 缺少依赖管理，社区涌现了五花八门的依赖管理方案，比如 glide、govendor、godep 等。而 Go 自 1.11 起，内置了 modules 方案，总算是来了个一锤定音。

Go modules 方案的设计是非常好的，网上介绍 Go modules 机制的文章很多，我这里也不再赘述。工作中写的一些 Go 项目，我都已经用上了该方案来做依赖管理。之所以这么快的拥抱新方案，是认为有 google 的背景，即使是新鲜出炉的功能，稳定性应该是有保证的，即使有坑，趟趟也就过去了。

但是在这个过程中，发现的一些问题让我对 Go 软件工程质量的信心大打折扣。

OpenStack/Swift 在很早之前就有了 global clusters 的概念，给每一块磁盘赋予一个 region 的属性，在跨地域分布的集群里进行对象读写操作时，前端 proxy server 可以选择地缘近的后端存储服务来通信，进而达到低延迟和高吞吐的目的。具体配置见：Global Clusters。