[譯] Web 應用的未來：Heroku vs Docker

05-15

原文地址：Its The Future
原文作者：CircleCI
譯文出自：掘金翻譯計劃
本文永久鏈接：https://github.com/xitu/gold-miner/blob/master/TODO1/its-the-future.md
譯者：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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要查看更多優質譯文請持續關注掘金翻譯計劃、官方微博、知乎專欄。