[譯] 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、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。