时值秋招，offer拿得还算顺利，所以也没有特别大的压力了，这段时间刚好可以加强一下理论的积累。

下午听了一个和CAP相关的讲座——《CAP Theorem and Its Implications for Building Robust Distributed Systems》，当然主要还是介绍CAP Theorem，基本没怎么涉及“健壮的”分布式系统，毕竟1个小时也分享不了多少内容。

虽然网上已经有不少关于CAP的文章了，但和这次讲座上提到的相比，似乎存在一些问题，并不是说做学术的就是权威，大家需要自己斟酌。

关于容器技术的原理，我在很早之前翻译过命名空间相关的文章，但这还远远不够，需要切入的还有cgroup、文件系统和网络相关方面的细节。

到了招聘季，稍微有点时间整理这方面的资料，索性先从文件系统入手，本文的目标仅仅是“知其然”。

最近在写一个新程序，由于需要依赖平台相关的特性，因此每次提交前都需要手动在各种平台测试，令人十分苦恼。

好在，最近在实验室的一台主机上装了ESXi，虚拟出几个节点别提有多方便，所以CI也可以搞起了。

目前(一直以来)比较流行的CI有Jenkins，那就先从Buildbot开始吧。

读研以来，很少关注高层架构的变动，所以忽略了期间服务化趋势带来的一些变化。近期，在某厂的面试中就被问到了服务调度和容错。

目前，各厂基本都已进入了服务化的阶段，对于单节点的性能挖掘变得不再是那么迫切，服务调度、容错等问题才是焦点。之前通过开发服务器，基本掌握了Linux用户态的程序开发，但对于服务化方面的知识和经验，还是相当欠缺。

比较早接触docker，也翻译过一些相关的文章，但坦白说平日里用的真心不多。

自2014年博客启用至今，出于对成本和性能的平衡，我已经对网站做了近20次的迁移。期间主要面临的问题是服务商提供的Linux发行版比较有限，且并未在所有平台(例如Xen)成功实施在线的发行版替换工作，由于平台的制约，运行环境无可避免地会出现不一致的情况，细节部分自然也难以统一，为此出过不少差错。

一般情况下，我是比较懒的，除非真正想要折腾，否则能拖就拖。而这次做出了docker化的决定，出于以下2点原因：

1. 想折腾了，期望能够在部署、备份等环节尽可能实现自动化，最好能够实现闭环，这一切自然需要实践
2. 近期有在规划重写整个站点将其转成一个SPA，采用MicroService彻底分离前后端，并使其跑在自己的server和framework之上