[译] Web 应用的将来：Heroku vs Docker

• 原文地址：It's The Future
• 原文做者：CircleCI
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Hopsken
• 校对者：jasonxia23 Starrier

嗨，我老板让我跟你谈谈，据说你很懂 web 应用？

嗯，我对分布式系统确实挺了解的。我刚从 ContainerCamp 和 Gluecon 回来，下星期我还打算去参加 Dockercon。这个行业的发展方向使人兴奋，让全部事情都变得更简单，也更可靠。这就是将来！

666。我最近在作一个简单的 web 应用 —— 一个普通的基于 Rails 的 CRUD（译者注：增删查改）应用，准备搭建在 Heroku 上面。如今仍是这么作吗？

不不不，这已是老掉牙的作法了。Heroku 已死，没人再用这玩意儿了。如今你得用 Docker，这才是大势所趋。

额，好吧。不过，那是啥？

Docker 是实现容器化的新方案。它跟 LXC 差很少，不过它也是一种打包格式，一种分发平台，以及一套能够方便地构建分布式系统的工具。

哈？啥容器？LXE 又是啥？

是 LXC。它就像 chroot on steroids！

cher-oot 又是啥？

行吧。听着，Docker、容器化，这就是将来。跟虚拟化很相似，可是更快，也更经济。

哦，懂了，因此就跟 Vagrant 差很少咯？

不不不，Vagrant 已死。将来是容器化的天下。

好吧，因此如今我不必去了解的虚拟化了对吧？

不，你还得用到虚拟化，由于容器目前还不能提供完整的安全层级。因此，若是你但愿程序运行在多用户环境中，你得确保你不能跳出沙盒。

额，等等，我有点跟不上了。咱们来捋一捋，也就是说，有这么个东西，叫作容器，和虚拟化很像。并且我能够在 Heroku 上使用它？

这么说吧，Heroku 确实在某种程度上支持 Docker，可是我刚说了：Heroku 已死。你应该把容器运行在 CoreOS 上面。

好吧，那是啥？

那是个宿主操做系统，能够跟 Docker 结合使用。讲道理，你甚至不须要用 Docker，你能够用 rkt。

啥啥？Rocket？

不，是 rkt。

没错啊，Rocket。

不，我说的是 rkt。这彻底是两码事。它是另外一种容器化格式，没有 Docker 那么高的集成度，但也所以拥有更高的组件化程度。

因此这是件好事？

这固然是件好事，组件化就是将来。

好的吧，那要怎么用它？

不知道，我不认为有人在用这玩意。

行吧。你以前有提到 CoreOS？

哦，对，这是一个能够跟 Docker 搭配使用的宿主操做系统。

宿主操做系统是啥？

一个宿主操做系统能够运行你全部的容器。

运行个人容器？

没错，你总得把你的容器运行在某个东西上吧。这么说吧，先配置好一个实例，比方说 EC2，装好 CoreOS，而后运行 Docker 后台程序，再而后你就能够把 Docker 镜像部署上去了。

因此这里面哪一步是所谓的容器？

所有都是。这么说吧，你先准备好你的应用，写一个 Dockerfile，在本地把它们转成一个镜像，而后你就能够把它们推送到任何 Docker 主机上去了。

额，比方说，Heroku？

不对，不是 Heroku。我都跟你说了，Heroku 已死。如今，借助 Docker，你能够运行你本身云服务了。

哈？

没错，很容易作到。你查一下 #gifee 就知道了。

啥？Gify？

「Google’s infrastructure for everyone else.」你只须要取一些已有的工具和技术栈，借助容器技术，而后你就能够拥有和 Google 同样的架构了。

那我为啥不能直接使用 Google 的呢？

你认为半年内会出现吗？

好吧，那么还有其余提供此类托管服务的厂商吗？我实在是不想本身托管。

呃，Amazon 有提供 ECS 服务，可是你得去写一些 XML 或者其它乱七八糟的玩意。

那 OpenStack 呢？

呵呵。

啊？

呵呵。

讲真，我真心不想本身来托管服务。

别啊，这真的很简单。你只须要配置一个 Kubernetes 集群。

我还须要一个集群？

Kubernetes 集群。它会负责管理你全部服务的部署工做。

我只有一个服务。

你说啥呢？只有一个应用是没错，可是至少得有 8-12 个服务吧？

哈？不不，就一个应用。呃，服务...反正无论怎么说，就一个。

不不不，你再想一想微服务。对吧，这才是将来。如今你们都这么干。先拿到一个大型的应用，而后把它分红大约 12 个左右的服务，每个都只负责一部分工做。

这也太多了。

这是确保可用性的惟一方法。这样当你的认证服务下线的时候...

认证服务？我只是打算用我以前用过的 gem 而已。

没错。使用那个 gem，把它放到它自己的项目中，再给它写一个 RESTful API。这样你的其它服务就能够调用那个 API，从而优雅地处理错误和事务。把它放到一个容器中，而后持续交付它们。

行吧，那么既然我已经有了十多个没有被管理的服务，如今该怎么办？

我刚提到了 Kubernetes，对吧。它容许你将你全部的服务协同到一块儿。

协同起来？

没错。如今你已经有了若干服务，而且它们得保持可用性，因此你须要多拷贝几份服务出来。Kubernetes 能够确保你有足够多的相同服务，把它们分布到位于服务器群上的多个主机上，这样，这些服务就能够一直都能被访问啦。

我如今又须要一个服务器群了？

没错，为了可靠性。可是 Kubernetes 能够替你管好这些。并且，你知道，Kubernetes 确定是有用的，由于是 Google 打造了它，而且它是运行在 etcd 上的。

etcd 是啥？

它是 RAFT 的一种实现。

好吧，那么问题来了，RAFT 又是啥？

相似于 Paxos。

天啦噜，咱们究竟要在这条路上走多远啊？我只是想运行一个应用而已啊。哎，奶奶个腿的，OK，冷静，深呼吸。苍天呐。行吧，Paxos 又是啥？

Paxos 算是个 70 年代就提出的古老的分布式协议，可是没人真正理解，也没人去用。

太好了，谢谢你告诉我这些。因此 Raft 是啥？

既然没人能理解 Paxos，有个叫作 Diego 的人...

哦，你认识他？

没，他在 CoreOS 工做。总之，Diego 为了他的博士论文打造了 Raft，由于 Paxos 实在是太难了。聪明的家伙。而后他实现了 Raft，写出了 etcd。再而后，Aphyr 说这玩意还不赖。

Aphyr 是谁？

Aphyr 就是那个写了『Call Me Maybe』的人。就是那个分布式系统和 BDSM 的？

哈？你刚是否是说了『BDSM』？

没错，BDSM。这但是旧金山，全部人都懂分布式系统和 BDSM。

好的吧。因此是他写了 Katy Parry 的那首歌？

没，他写了一系列博客解释为何全部的数据库都不符合 CAP。

CAP 是啥？

就是 CAP 定理。定理说，在连贯性、可访问性和可分割性这三个中你只能保证其中两个。

行吧。因此说，全部的数据库都不符合 CAP 定理？那是什么意思？

这意味，它们都是垃圾。比方说 Mongo。

我原觉得 Mongo 是 web 层面上的？

没人这么认为。

好吧，因此 etcd 是啥？

etcd 是一种分布式的键值对仓库。

哦，就像 Redis。

不，一点都不像。etcd 是分布式的，而一旦网络被断开，Redis 就丧失了一半的写入能力。

好吧，因此这是个分布式的键值对仓库。这有啥用？

Kubernetes 具备一个标准的 5 节点的集群，使用 etcd 做为消息总线。它会整合 Kubernetes 自带一些服务来提供很是具备弹性的协同系统。

5 个节点？我只有一个应用啊。这样我须要多少设备啊？

这样，你大约要有 12 个服务，固然对于每个你还须要一些冗余服务做为拷贝，一些用于负载均衡，一些 etcd 集群，数据库，还有 Kubernetes 集群，这些加起来差很少要 50 个容器。

什么！

这没什么！容器是很是高效的，因此你应该能够把它们分布到 8 台设备上！是否是很厉害？

话是这么说。因此有了这些，我就能够部署个人应用了？

固然。我是说，对于 Docker 和 Kubernetes，仍然存在一个开放性的存储问题。关于网络通讯也须要花些功夫，不过差很少就是这样了。

我懂了。我想我理解你的意思了。

棒极了！

谢谢你解释这么多。

不用谢。

让我回顾一遍，看看我理解的对不对。

没问题！

因此，我只须要把我这个简单的 CRUD 应用划分红 12 个微服务，每个都有它们独立的 API，这些 API 互相之间能够调用，且能够弹性地处理问题，把它们整合到 Docker 容器中，启动一个拥有 8 个运行着 CoreOS 的设备集群做为 Docker 主机，使用运行着 etcd 的一个小 Kubernetes 集群来协同管理它们，解决好网络和存储这些『开放性』问题，最后把每一个微服务的多份冗余拷贝持续交付到个人服务器集群上。是这样吧？

对！是否是酷炫？

我仍是滚回去用 Heroku 吧。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。