注：在 2016 年学 JavaScript 是一种什么样的体验？ 是模仿 Circle.ci 的这篇文章 It’s The Future 写的，也就是本文的原文。

嘿，老大让我来找你聊聊，听说你很懂 web 应用？

—是吧，我现在做分布式系统比较多。我刚参加了 ContainerCamp 和 Gluecon，下周又要去 Dockercon 了。行业的发展激动人心，让一切都变得更简单、更可靠。这就是未来！

酷！我现在想搭建一个简单的 web 应用，就是用 Rails 做的增删改查应用，打算部署到 Heroku 上。现在还应该这么做吗？

—噢，不。过时啦。Heroku 快挂了，没人用它了。你现在应该用 Docker。这是未来。

哦，好吧。Docker 是啥？

—Docker 是一种新的容器化方案，和 LXC 很像，但也是一种打包格式、一个分发平台，以及可以非常容易搭建分布式系统的工具。

容器化……等等？什么是 LXE？

—是 LXC，就像超级版 chroot！

cher-oot 是啥？

—好吧，是这样的。Docker，或者说容器化，就是未来。它和虚拟化很像，但更快也更便宜。

噢，所以说像 Vagrant。

—不，Vagrant 过气了。现在所有东西都要容器化，这是未来。

好吧，所以说我不需要知道任何和虚拟化有关的东西？

—不，你还是需要虚拟化，因为容器也不是完全安全。所以，如果你想要在多租户环境(multi-tenant environmen)中运行什么，就需要确保用户无法跳出沙盒。

好吧，我有点搞糊涂了。回顾一下。也就是说有一种类似于虚拟化的东西，它叫容器，而我可以在 Heroku 上用它？

—唔，Heroku 对 docker 有一定的支持，但我已经说了 Heroku 已死。你应该在 CoreOS 上运行容器。

OK，CoreOS 是啥？

—这是个你可以和 Docker 一起使用的宿主操作系统(Host OS)。靠，你甚至都不需要 Docker，你可以用 rkt。

Rocket？（译注：发音一样）

-不是，rkt。

对啊，Rocket。

-不是，r-k-t。完全不是一码事。这是另一种容器化格式，不像 Docker 一样被捆绑在一起，它要更容易组合。

rkt 好吗？

—当然好。可组合(Composability)是未来。

好吧，你怎么用它？

—我不知道。可能也没人用它吧。

摊手。你刚才提到了 CoreOS？

—是啊，CoreOS 是 Docker 的宿主操作系统。

宿主操作系统是啥？

-宿主操作系统运行所有容器。

运行我的容器？

—对，你得有东西来运行你的容器。比如你配置好一个 EC2 实例，把 CoreOS 放上面，然后运行 Docker 守护进程，再把 Docker 镜像部署到上面。

这里面哪个是容器？

—里面提到的所有东西都是容器。你看，你写好应用，再写一个 Dockerfile，在本地构建镜像，然后推送到 Docker host 上。

啊，就像 Heroku？

-不是 Heroku。我跟你说了，Heroku 已死。你现在可以用 Docker 来运行自己的云。

什么？

-嗯，非常简单。搜一下 #gifee。

Gify？（译注：发音一样，这篇文章有意思 2016, the year of GIFEE）

— ‘Google’s infrastructure for everyone else’的缩写，意思是大家都可以用的谷歌基础设施。你通过容器从中选择一些工具，就有了和谷歌一样的基础设施。

那我可以只用谷歌的东西啊。

—6 个月内你还用不上它。

好吧，没有人来托管这些东西吗？我真的不想自己来托管。

—你可以用亚马逊的 ECS，但你得写 XML 这种东西。

OpenStack 呢？

-额。

额？

-额。

我真的不想自己托管。

-不是，这很简单，你只要配置一个 Kubernetes 集群就可以了。

我需要一个集群？

-Kubernetes 集群。它会管理所有服务的部署。

我只有一个服务。

—什么意思？你有一个应用，对吧，所以你至少会有 8 到 12 个服务。

什么？不，只是一个应用。服务，什么东西。只是一个应用。

—不是，看看微服务。微服务就是未来。我们现在都这么做。把庞大的应用分解成服务，比如说 12 个。每个服务只做一件事。

似乎过头了。

—这是保证可靠性的唯一途径。假如你的验证服务宕了……

验证服务？我打算用以前一直在用的 gem。

—很好。用那个 gem，把它单独做成一个项目，加上 RESTful API，然后再让其他服务调用这些 API，优雅地处理错误等等。最后把它放到容器里，然后持续交付。

好吧，现在我有了十几个无法管理的服务，接下来呢？

—我不是说了 Kubernetes 嘛，它可以指挥所有这些服务。

指挥？

—对，既然你有了这些服务，而它们又必须可靠，你就得有这些服务的多个备份。Kubernetes 能确保你有足够的备份，而且分布在服务器 fleet（舰队）的多个 host 上，从而可以一直提供服务。

现在我需要一个 fleet 了？

—对，为了保证可靠性。不过 Kubernetes 会帮你管理。Kubernetes 肯定能行，因为它是谷歌出品，而且还是运行在 etcd 上。

etcd 是啥？

—是 RAFT 的一种实现。

RAFT 又是啥？

—就像 Paxos 一样。

天，这个链条啥时候能到头？我只是想发布一个应用。唉。靠。好吧，深呼吸。天啊。好吧，Paxos 是啥？

—Paxos 就像是上世纪 70 年代没人懂或理解的那种分布式一致性协议。

很好，谢谢你告诉我这一点。Raft 又是什么鬼？

—因为没人懂 Paxos，于是 Diego……

哦，你认识他？

—不认识，他在 CoreOS 工作。不管怎样，迪亚哥为了写博士论文打造了 Raft，因为 Paxos 太难了。真是个聪明的家伙。然后他写了 etcd 来实现 Raft。Aphyr 总算没说它是一坨屎。

Aphyr 是啥？

—Aphyr 就是那个写了“Call Me Maybe”的家伙，那个分布式系统和 BDSM 的家伙。

什么？你刚才说了 BDSM？

—嗯，BDSM。湾区的人都在用分布式系统和 BDSM。

好吧，他写了“Call Me Maybe”这首歌？

—没有，他写了一系列关于为什么所有数据库都没能打破 CAP 的博文。

CAP 是啥？

—CAP 定理，即任何分布式系统只能在一致性(Consitency)，可用性(Availability)和分区容忍性(Partition Tolerance)中三选二。

好吧，所有数据库都没能打破 CAP？这代表了什么？

—这说明它们都很垃圾，比如 Mongo。

我以为 Mongo 可扩展(scale)。

—没人这么想过。

好吧，etcd 呢？

—etcd 是一个分布式键值仓库。

噢，像 Redis。

—不，和 Redis 一点都不像。etcd 是分布式的。如果网络分区(network partition)，Redis 会丢失一半的写入。

好吧，etcd 是一个分布式键值仓库，为什么这一点很有用？

—Kubernetes 可以用 etcd 来配置一个标准的 5 节点集群作为 message bus。etcd 结合一些 Kubernetes 服务可以提供一个相当健壮的指挥系统。

5 个节点？我只有一个应用。我一共需要多少机器？

—唔，你大概需要 12 个服务，每个服务还要有一些冗余备份，一些负载均衡器，etcd 集群，数据库以及 Kubernetes 集群。大概 50 个容器吧。

靠！

—小事一桩！容器非常高效，你可以在大约 8 台机器上部署这些容器！是不是很神奇？

也许吧，有了这些服务，我总能部署我的应用了吧？

—当然，不过存储仍然是个问题，网络也会花很多功夫，但差不多就这样啦！

这样。好吧，我觉得我懂了。

—太好了！

谢谢你解释这些。

—没事。

我再说一遍，看我理解了没有。

—好的！

所以，我需要把一个简单的增删改查应用分解成 12 个微服务，每个微服务都要有自己的 API，还可以调用其他微服务的 API，并且能健壮地处理错误，接着把微服务放入 Docker 容器，启动 8 台运行 CoreOS 的 Docker 托管机器，用一个运行 etcd 的小 Kubernetes 集群来“指挥”它们，再解决网络和存储的问题，然后持续交付每个微服务的多个冗余备份到 8 台机器上。对吧？

—对！是不是很棒？

我还是滚回去用 Heroku 吧。

作者：管策

来源：知乎