嘿，我老板让我来找你 - 听说你对 Web 软件知之甚多。
是呀，我现在主要研究对分布式系统。我刚刚从 ContainerCamp 和 Gluecon 回来，下周还要去参加 Dockercon 大会。 我对这个行业的发展趋势颇感兴奋 - 一切都将变得更加简单、更加可靠。这就是未来！
太好了。我眼下正在构建一个简单的 Web 程序 - 一个常规意义上的增删改查类应用程序，采用 Rails 框架开发，打算部署到 Heroku 上。你觉得这个方案怎么样呀？
噢，不！这种方法太古老了。Heroku 即将消亡 - 现在没有人再愿意用它了。你需要使用 Docker。这就是未来。
嗯，好吧。Docker 是个什么东东？
Docker 是一种新型的容器化技术。它就像 LXC，但也是一种封装格式、一种分布式平台、一种让分布式系统变得更加简单易用的工具。
容器... - 什么？LXE 是什么？
应该是 LXC。 它就像 chroot on steroids 一样。
什么是 cher-oot？
好吧，事情是这样的：Docker、容器化技术，这是未来技术的发展方向。这种技术和虚拟化技术非常相似，但是运行效率更高、开销更低。
噢。我明白了，有点像 Vagrant。
不对，Vagrant 即将消亡。从现在开始，一切都将走向容器化，这就是未来。
好吧，所以我并不需要了解虚拟化方面的知识，对吗？
不对，你依然会用到虚拟化技术，因为容器技术无法提供完整的安全方案。因此，如果你运行一个多用户环境，你必须确保沙箱的安全性。
好吧，但是我似乎有一点儿迷惑。让我重新复述一下。现在有一种类似虚拟化的技术，名叫容器。我是否能把这种容器技术用在 Heroku 上？
是这样，Heroku 部分支持 Docker，但是我已经和你说过了：Heroku 即将消亡。你需要把你的容器跑在 CoreOS 上。
好的，CoreOS 是什么？
这是一个非常适合与 Docker 一起使用的酷炫操作系统。我差点都忘了，你甚至无需使用 Docker，你可以直接使用 rkt。
Rocket？
不是 Rocket，是 rkt。
对呀，是 Rocket。
不对，它的名字现在叫 rkt。完全不同两个单词。rkt 是另一种容器化技术规格，无需和 Docker 完全绑定，所以说它的组合性更强。
真有那么好？
当然非常好。模块化及其可组合性就是未来。
好吧，应该怎样使用它呢？
我不知道。据我所知，目前还没有人使用它。
唉。你能不能再多说点 CoreOS？
好的，它是一个可以和 Docker 一起使用的 Host 操作系统。
什么是 Host 操作系统？
Host 操作系统可以运行你自己的容器。
运行我自己的容器？
是的，你需要有一个东西来运行你的容器。因此，当你搭建好一个类似 EC2 那样的环境后，你就需要安装 CoreOS，然后，运行 Docker 守护进程，再然后，你就可以部署 Docker 镜像啦。
这里面到底哪部分是容器？
全部都是。听我说，你要为你的应用程序编写一个 Dockerfile 文件，然后在本地将其生成一个镜像，再然后，你就可以把这个镜像推送到任何 Docker 环境中了。
啊，看起来就像 Heroku？
不对，不是 Heroku。我已经告诉过你了，Heroku 即将消亡。你现在使用 Docker 运行你自己的云。
什么？
是的，这非常简单。就像 #gifee。
Gify？
『Google’s infrastructure for everyone else』。你现在只需利用现成的工具、堆栈，结合容器化技术，你就可以享有和谷歌一样的基础架构和设施了。
为什么不直接使用谷歌的平台？
你是不是认为这将会花费你很多时间？
是的，现在不是有很多公司都在做这类事情吗？我真的不想自己来管理这些事情。
好吧，亚马逊有一款产品名叫 ECS，但是你需要自己编写 XML 或者其它一些配置。
你觉得基于 OpenStack 搭建环境如何？
一脸厌恶的表情。
不喜欢？
依旧一脸厌恶的表情。
你听我说，我真的不喜欢自己管理这么多事情。
不用，这件事情非常简单。你只需把 Kubernetes 集群环境构建完成就好了。
我真的需要一个集群吗？
Kubernetes 集群。它可以帮助管理你所有的服务部署。
我只有一项服务。
-你是什么意思？你已经有一个现成的 Web 程序了，所以你至少需要维护 8-12 个服务。
什么？不是这样，只有一个应用程序。服务也只有一个。
你的想法不对！我们一起来看看微服务（microservices）这个概念吧。就像我们今天探讨的其它事物，它就是未来。你可以将你的一体化程序划分为 12 个服务。一个服务仅承担一项任务。
这看起来似乎有点儿多余。
这是确保服务可靠性的唯一办法。因此，如果你的身份验证服务宕掉了...
身份验证服务？我只打算使用一个我过去常常使用 gem。
很好。就用那个 gem。将其做成一个独立的项目，然后给它设计一套 RESTful API。你的其它服务就可以使用这个 API 了，这样的话，你就能够优雅地处理故障及其它事宜了。将其置于一个容器中，它就连续不断地提供服务了。
好吧，所以现在我就有了一堆无法管理的服务了，对吗？
不是这样的，我刚才不是已经和你提起过 Kubernetes 了嘛。这个东西能让你很好地把你的服务管理和协调起来。
管理和协调这些服务？
是的，你已经有了这些服务，为了让它们变得更加可靠，你需要为它们生成多个副本。Kubernetes 可以确保其万无一失，而且，在你的 fleet 中，这些冗余服务将分布在多个主机上，因此，它们随时可供使用。
我现在需要一个舰队（fleet）？
是的，为了保障可靠性。但是 Kubernetes 会为你完成这项任务的。你知道谷歌实现 Kubernetes 的原因就是如此，它运行在 etcd 上。
什么是 etcd？
它是一个 RAFT 实现。
好吧，那什么是 RAFT？
它就像 Paxos。
上帝啊，这个该死的兔子洞究竟还有多深？我只想发布一款软件。唉，该死的。好吧，深呼吸。上帝呀。好吧，Paxos 究竟是什么？
Paxos 就是一个古老的分布式协商协议，从七十年代起已经没有人真正能够理解和使用它了。
太好了，感谢你告诉我这一事实。那么 Raft 呢？
由于没有理解 Paxos，有一个名叫 Diego 的家伙...
噢，你认识这个人？
不，我不认识。 Diego 这个家伙在 CoreOS 工作。不管怎样，因为 Paxos 太难了， Diego 在他的博士论文中设计了 Raft。 Diego 真是个调皮且聪明的家伙。然后，他基于 Raft 实现了 etcd。有一个名叫 Aphyr 的人认为迭戈做的东西就是一坨臭狗屎。
谁是 Aphyr？
Aphyr 就是撰写了 Call Me Maybe 的那个人。你知道，他是一个专门研究分布式系统的自虐狂。
什么？你为什说他是自虐狂？
是的，他就是一个自虐狂。在旧金山，每个人只要不属于分布式阵营，一定就是自虐狂。
哦，好吧。他撰写了凯蒂·佩里演唱的那些歌曲？
不是的，他撰写了一系列博客文章，主要阐述数据库故障的 CAP。
什么是 CAP？
CAP 定理。这个理论的大意是，在可靠性、可用性以及容错性之间，你只能做到三选二。
好的，所有的数据库系统均遵循 CAP 定理？这句话到底是什么意思？
它的意思是，这些数据库系统就是一堆狗屎。比如 MongoDB 数据库。
我觉得 MongoDB 可以支撑很大访问量的网站？
现在已经没人这么看了。
好吧，那么 etcd 呢？
是的，etcd 是一个分布式键值存储系统。
噢，就像 Redis。
不是的，一点儿不像 Redis。etcd 是一个分布式系统。如果把网络划分为不同的区域，Redis 就会丧失一半的写入能力。
好的，它就是一个分布式的键值存储系统。那么它究竟有什么用处呢？
Kubernetes 搭建起 5 个节点的集群，并且利用 etcd 构建一个消息总线。结合 Kubernetes 的其它服务，我们就有了一个极具弹性的协作系统。
5 个节点？我只有一个软件。建立这样一个系统需要多少台机器？
好吧，你有 12 个服务，每一个服务你还需要一些冗余、一些负载均衡、一个 etcd 集群、数据库以及 kubernetes 集群。所以，大约有 50 个容器需要运行。
这真 TMD 的见鬼！
没什么大不了的！容器非常高效，因此你应该可以将你的那些服务分配到 8 台服务器上！你难道不觉得这非常神奇美妙吗？
照你所言，只要做好这一切，我就可以轻松地部署我的应用了？
当然。我的意思是，存储对于 Docker 和 Kubernetes 而言，依然是一个悬而未决的问题，而且，网络方面，很可能还需要再做一点配置，但是基本上就是这么多啦。
我明白了。好吧，我觉得我已经完全理解了。
太好了！
感谢你的解释。
不用客气。
请允许我简单地复述一下，你帮我看看还有什么不对的地方？
好的！
按照你的设想，我需要把我简单的增删改查类程序划分为 12 个服务，每一项服务均有自己的 API，它们彼此之间可以相互调用，这样就让系统有了一定的容错能力；再将它们放入一个名叫 Docker 的容器里，搭建一个由 8 台物理机器组成，在 Docker 容器里运行 CoreOS 的集群系统，然后，利用一个运行 etcd 的 Kubernetes 集群系统协调管理这些服务；再然后，解决掉网络和存储方面遗留的几项悬而未决的问题，最后，我就可以连续不断地向这个系统部署我的代码了，是这样吗？
是的，完全正确！这难道不是一件让你倍感荣耀和自豪的事情吗？
我还是去用我的 Heroku 吧。
作者： Paul Biggar，程序员，CircleCI 创始人，生活在旧金山。
感谢：Qingniu 帮助审阅并完成校对。