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