2018的陰謀論？Docker公司與微服務(wù)之死！

作者：佚名 2018-01-31 09:55:28
云計算 月初，一篇題為《Docker 公司已死》的文章，預(yù)言了 Docker 公司將在 2018 年的某個時候不復(fù)存在。就這一觀點，緊接著出現(xiàn)了一篇《Docker 公司不會死》的文章進行了反駁。

成都創(chuàng)新互聯(lián)來電聯(lián)系：028-86922220，為您提供成都網(wǎng)站建設(shè)網(wǎng)頁設(shè)計及定制高端網(wǎng)站建設(shè)服務(wù)，成都創(chuàng)新互聯(lián)網(wǎng)頁制作領(lǐng)域十年，包括成都咖啡廳設(shè)計等多個領(lǐng)域擁有多年的網(wǎng)站運維經(jīng)驗，選擇成都創(chuàng)新互聯(lián)，為企業(yè)錦上添花！

月初，一篇題為《Docker 公司已死》的文章，預(yù)言了 Docker 公司將在 2018 年的某個時候不復(fù)存在。就這一觀點，緊接著出現(xiàn)了一篇《Docker 公司不會死》的文章進行了反駁。

Docker 公司已死 ！

Chris Short 在《Docker 公司已死》中寫道，對于 Docker 公司而言，將 2017 年形容為艱難的一年恐怕都有些輕描淡寫。

事實上，除了 Uber 之外，真的想不到其他哪家被沸沸揚揚的炒作新聞所包圍的硅谷初創(chuàng)企業(yè)會像 Docker 這樣經(jīng)歷糟糕透頂?shù)囊荒辍?/p>

未來的人們在回顧 Docker 公司的發(fā)展歷程時，會將 2017 年視為這家重要軟件公司被糟糕商業(yè)慣例所摧毀，并最終走向滅亡的起點。

Docker 是款好軟件

需要明確的是，Docker 公司確實在軟件開發(fā)的這一波革新當(dāng)中發(fā)揮了重要作用。能夠?qū)?cgroups、命名空間、進程隔離等 Linux 原語納入至同一工具當(dāng)中絕對是個了不起的成就。

Docker 的崛起使得開發(fā)環(huán)境最終轉(zhuǎn)化為一個簡單且具備版本控制能力的 Dockerfile。

它的工具鏈將 Packer、Vagrant、VirtualBox 以及其他多種基礎(chǔ)設(shè)施共同轉(zhuǎn)移至 Docker 陣營當(dāng)中。Docker UI 實際上也做得相當(dāng)出彩！

Docker 硅谷的新寵兒

Docker 公司的早期成功使其快速以產(chǎn)品為核心建立起一套龐大的社區(qū)。此外，快速發(fā)展同樣帶來了極為順利的資金流引入。

高盛、格雷洛克風(fēng)投、紅杉資本以及洞見風(fēng)投等紛紛為 Docker 公司提供大量資金。截至目前，Docker 公司的融資總額已經(jīng)達到 2.42 億到 2.5 億美元之間。

雖然產(chǎn)品本身的質(zhì)量值得肯定，但公司遭遇了一系列人力資源失誤。更遺憾的是，很多硅谷寵兒都存在這樣的問題，且顯然有必要作出改變。

Kubernetes 對 Docker 造成沖擊

隨著 Kubernete 的興起，Docker 公司的厄運可謂加速降臨。Docker 公司一直未能找到應(yīng)對開源社區(qū)容器編排新寵 Kubernetes 的好辦法。

Docker 公司旗下的 Docker Swarm 是其所擁有的唯一容器編排工具。盡管 Kubernetes 率先向 Docker 容器示好，但 Docker 仍然拿出了自己的競爭性方案。

而且根據(jù)記錄，Docker 方面曾在 2017 年年初通過文章、會議乃至其他大型活動對 Kubernetes 表達不滿。

但通過本屆于奧斯汀召開的 DockerCon 17 大會來看，Docker 方面突然決定全力支持 Kubernetes。

這種突然的變化顯然是承認了 Kubernetes 的崛起已經(jīng)不可阻擋。而 Docker 在 2017 年 KubeCon + CloudNativeCon 北美大會上再次陳述此項決定，無疑更進一步強調(diào)了這一結(jié)論。

Moby?

沒人了解 Docker 在去年 4 月的 DockerCon 17 大會上到底為什么要宣布 Moby。

Moby 據(jù)稱屬于 Docker 項目的新上游，然而考慮到事前毫無先兆，因此當(dāng) Solomon Hykes 在 DockerCon 17 大會上加以宣布時引發(fā)了大范圍的震驚與爭議性情緒。

為了解決這波沖突，GitHub 方面的工作人員甚至選擇直接加以干預(yù)。Moby 部署的處理工作仍然困擾著從來者們，而 Docker 品牌亦可能因此受到損害。

Kubernetes 的冰冷擁抱

Docker 公司對于 Kubernetes 在***一刻才張開的遲到且尷尬的擁抱，代表著其即將遭遇崩潰。問題在于，Docker Swarm 還遠遠稱不上成熟。

事實上，Docker Swarm 產(chǎn)品團隊及其少數(shù)開源貢獻者根本無法跟上 Kubernetes 社區(qū)那迅猛的發(fā)展步伐。

而且與 Docker UI 一樣，Kubernetes UI 同樣非常出色。就目前來看，Docker 公司本身似乎正開始淪為一家容器領(lǐng)域中的邊緣咨詢企業(yè)。

陰謀論：Docker 公司知道自己已經(jīng)沒戲唱了。技術(shù)人員們決定大規(guī)模推出 Moby，并突然接納 Kubernetes，這些都是為了給自己爭取一點喘息之機。 #Docker #DevOps

——Chris Short (@ChrisShort) 2017年12月29日

Chris Short 最終得出結(jié)論：Docker 公司的真正問題在于缺乏連續(xù)的領(lǐng)導(dǎo)。在該公司當(dāng)中，每一任***都擁有自己的戰(zhàn)略重點設(shè)定。

這種斷代性雖然距離公司的核心越來越遠，但卻仍然存在。很明顯，Docker 是在自取滅亡。

Docker“生死”記，這條船還能開出去多遠？

Dylan Chris 在《Docker 公司不會死》中寫道：雖然 Chris Short 的一些觀點是對的，但 Docker 并不會這么快就退出舞臺。

Docker 當(dāng)然是款好軟件

將 cgroups、命名空間、進程隔離等 Linux 原語納入至同一工具當(dāng)中，Docker 絕對是個了不起的好軟件。

Docker 的簡單界面降低了非管理員的入門門檻，允許開發(fā)者社區(qū)隨手將其添加到他們的工作流程中。

Docker 發(fā)布了 EE / UCP，一些大型企業(yè)也加入進來。這對于開發(fā)人員、中小型企業(yè)和大型企業(yè)來說 Docker 都是一款很好用的軟件，而且 Docker 也不會放慢開發(fā)的速度。

Docker 有朋友

微軟 Kubernetes 的***工程師 Brendan Burns：“我很高興歡迎 Solomon 和 Docker 加入 Kubernetes 社區(qū)”。在談到 Docker 時很多人都會引用這個聲明，認為這對 Docker 來說是一個很大的打擊。

但談到這一點的真正目的是談?wù)摴局g的合作，并不是糾結(jié)于“到底是誰加入誰的社區(qū)”。

我們“需要一個村莊一起來養(yǎng)一個孩子”，這個村莊由來自世界上許多大公司的一些最聰明的工程師組成，他們都在努力使 Docker 變得更好。Docker 和 Kubernetes 的合作，對 Kubernetes 與 UCP 來說都非常有意義。

Docker 有業(yè)務(wù)

Docker 公司不會被收購或閉門。Docker 并不缺領(lǐng)導(dǎo)，也有大量的資金，營銷方面也不錯，所有的跡象都意味著這家公司正在迅速成長，正在進入企業(yè)市場。但成長得并不容易。他們的“現(xiàn)代化企業(yè)應(yīng)用”口號是***的。

這是一個基于 OSS 的公司，市場上有著大量的機遇。雖然 Iron 的其中一款產(chǎn)品是基于 Docker 的，但我們也會大量使用來自 OSS 公司的各種軟件，也很樂意為 OSS 軟件提供更高層次的支持和功能。

對于其他項目，我們經(jīng)常通過 Open Collective 捐贈來幫助維護人員和小型開發(fā)團隊。Docker 對 containerd 的捐贈是一個很好的舉措，這是一個完全符合 CNCF 章程的項目。

雖然 Docker 正在向“上流社會”移動，但他們并沒有拋棄真正的用戶：開發(fā)人員?？傊?，Docker 公司有很大的增長空間，而在 2018 年，它將持續(xù)實現(xiàn)增長。

隨后近期又出現(xiàn)了一篇“2018 瘋狂微服務(wù)之死”的陰謀論文章，詳細內(nèi)容如下：

2018 瘋狂微服務(wù)之死

近期微服務(wù)的話題非?；鸨?，有時可謂非?！隘偪瘛保?/p>

Netflix 在 DevOps 上做得很棒，同時 Netfix 也采用微服務(wù)。因此：如果我也用微服務(wù)，那么我也可以在 DevOps 方面做得很好。

很多情況下，為了解決手頭的問題，我們付出了巨大的努力采用微服務(wù)模式，但是并不清楚它的成本和收益。

接下來我將詳細介紹什么是微服務(wù)，這種模式吸引人的原因，以及它所面臨的主要挑戰(zhàn)。

如果你正在考慮微服務(wù)是否適合你的模式，我會在文章的***用一系列簡單的問題來幫你做出選擇。

微服務(wù)為什么如此受歡迎？

什么是微服務(wù)，它為什么如此受歡迎？首先從最基本的開始了解。下圖是一個假想的視頻共享平臺的實現(xiàn)方式，左側(cè)是傳統(tǒng)的整體式架構(gòu)（單個巨型單元），右側(cè)則是微服務(wù)：

兩種模式的區(qū)別在于***種是整體式架構(gòu)，只有一個大單元。第二種則由多個小單元構(gòu)成，每個小單元都是獨立的服務(wù)。上圖已足夠細致，從中很容易找到微服務(wù)模式的吸引力所在。

以下是微服務(wù)架構(gòu)的具體好處：

• 獨立開發(fā)：小型的獨立組件可由小型的獨立團隊構(gòu)建。一個小組可以專門負責(zé)開發(fā)“Upload”服務(wù)，不用去管其他服務(wù)。每個組件的功能變得簡單，這樣一來，開發(fā)人員了解組件的時間大大減少，更容易開發(fā)新功能。
• 獨立部署：每個單獨的組件都可以獨立部署。這樣一來發(fā)布新功能的速度就更快，風(fēng)險也更小。假設(shè)“Streaming”組件修復(fù)了 Bug 或者新增了功能，那么部署時并不會影響其他組件。
• 獨立擴展：每個組件可以獨立地進行擴展。在新節(jié)目剛發(fā)布的繁忙時期，可以擴展“Download”組件，以支持增加的負載，而不必擴展所有組件，這樣一來擴展更具彈性并且降低了成本。
• 可重用性：每個組件各自實現(xiàn)一個小的、特定的功能。這意味著它們可以很容易地適用于其他系統(tǒng)、服務(wù)或者產(chǎn)品?！癟ranscode”組件可以被其他業(yè)務(wù)單元使用，甚至可以改寫成一個新的業(yè)務(wù)，從而為其他組提供轉(zhuǎn)碼服務(wù)。

從以上細節(jié)層面可見，微服務(wù)模式相比整體式架構(gòu)的好處顯而易見。如果確實是這樣的話——那為什么這種模式最近才開始流行呢？

微服務(wù)為什么沒有很早就開始流行？

既然微服務(wù)好處多多，為什么沒有很早就開始流行呢？原因有二：

• 它提升了我們的技術(shù)能力。
• 最近的技術(shù)進步讓我們能夠把它帶到一個新的水平。

當(dāng)我開始寫這個問題的答案時，發(fā)現(xiàn)一兩句話無法解釋清楚，所以實際上我把它分成了另外一篇文章，稍后再發(fā)表。

因此在本文中，我將跳過從單個程序到多個程序的過程，忽略 ESBs 和面向服務(wù)的體系結(jié)構(gòu)、組件設(shè)計以及有限的上下文等內(nèi)容。

在很多方面我們已經(jīng)開始使用微服務(wù)，隨著近期容器技術(shù)（特別是 Docker）和集群技術(shù)（如 Kubernetes、Mesos、Consul 等等）的普及，從技術(shù)的角度來看，微服務(wù)模式變得更加可行。

如果我們打算實施微服務(wù)，那么在開始之前需要想清楚。從理論的角度我們看到了它的優(yōu)點，那么它有沒有弊端呢？

微服務(wù)有什么問題？

微服務(wù)模式優(yōu)點多多，那么它的缺點是什么呢？據(jù)我所知它主要有下列問題。

開發(fā)的復(fù)雜性增加

對于開發(fā)者來說事情會變得更加困難。當(dāng)開發(fā)人員開發(fā)一個新功能時，如果該功能依賴其他服務(wù)的話，那么開發(fā)人員不得不在他們的機器上運行所有服務(wù)，或者連接到這些服務(wù)。這通常比簡單地運行單個程序更加復(fù)雜。

這個問題可以通過一些工具得到部分緩解，但隨著構(gòu)成系統(tǒng)的服務(wù)數(shù)量的增加，開發(fā)人員在整個系統(tǒng)運行時面臨的挑戰(zhàn)也越來越多。

運營的復(fù)雜性增加

對于維護服務(wù)的團隊來說，潛在的復(fù)雜性是一個巨大的挑戰(zhàn)。他們管理的服務(wù)不是簡單的幾個，而是數(shù)十、數(shù)百甚至數(shù)千個正在運行的服務(wù)。服務(wù)數(shù)量越多，通信鏈路就越多，那么出錯的可能性就會變大。

DevOps 的復(fù)雜性增加

以上兩點表示開發(fā)和運營是分開進行的，隨著 DevOps 的普及（我是 DevOps 的忠實粉絲），DevOps 能夠緩解這個問題嗎？

如今有許多組織仍然依靠獨立的開發(fā)和運營團隊來工作，而也有一些組織更傾向于采用微服務(wù)。

對于已經(jīng)采用了 DevOps 的組織來說，這仍然很難。既是開發(fā)者又是運營者已經(jīng)非常艱難（但是要建立好的軟件卻很關(guān)鍵）了，還得了解集群容器系統(tǒng)的細微差別，特別是快速發(fā)展的系統(tǒng)，那就更困難了。

它需要資深專家

如果開發(fā)團隊成員都是專家級別，那么結(jié)果可能會很好。但想象一下，一個使用單一的整體式系統(tǒng)運行的不是很順暢。如果增加系統(tǒng)的數(shù)量，就會增加運行的復(fù)雜性。

通過有效的自動化、監(jiān)控和集群等技術(shù)可以做到。但瓶頸很少在于技術(shù)本身，而在于找到能夠有效使用這些技術(shù)的人。目前這些技能需求非常高，可能很難找到。

真實世界的系統(tǒng)往往界限不清

當(dāng)我們描述微服務(wù)的好處時，經(jīng)常談到獨立的組件。但是在很多情況下，組件并不是獨立的。在論文中，某些領(lǐng)域可能看起來有限，但是當(dāng)你深入細節(jié)時，你會發(fā)現(xiàn)他們比你預(yù)期的更具挑戰(zhàn)性。

事情變得非常復(fù)雜。如果你的界限沒有明確的定義，那么即使理論上的服務(wù)可以單獨部署，你也會發(fā)現(xiàn)，由于服務(wù)之間的相互依存關(guān)系，你必須部署一組服務(wù)。

這意味著你需要一系列管理協(xié)同工作的服務(wù)版本，這些服務(wù)版本之間的協(xié)作需要通過驗證和測試，你實際上沒有可獨立部署的系統(tǒng)，為了部署新功能，你需要仔細編排并同時部署許多服務(wù)。

狀態(tài)的復(fù)雜性往往被忽略

在前面的例子中，我提到一個功能的部署可能需要同時部署多個版本的多個服務(wù)。

假設(shè)合理的部署技術(shù)可以緩解這種情況，例如 blue/green 部署（大多數(shù)服務(wù)編排平臺可輕松應(yīng)對），或者并行運行的多個服務(wù)版本，以及決定使用哪個版本的通道。

如果服務(wù)是無狀態(tài)的，這些技術(shù)可以緩解大量的挑戰(zhàn)。但是無狀態(tài)服務(wù)非常容易處理。事實上，如果你有無狀態(tài)的服務(wù)，那么我會傾向于考慮跳過微服務(wù)，而考慮使用無服務(wù)器模型。

實際上，大多數(shù)服務(wù)都需要狀態(tài)。比如我們的視頻共享平臺例子中的訂閱服務(wù)。新版的訂閱服務(wù)可以用新的形式將數(shù)據(jù)存儲在訂閱數(shù)據(jù)庫中。

如果你并行運行兩個服務(wù)，則一次運行了兩個模式的系統(tǒng)。如果你進行了 blue green 部署，而其他服務(wù)依賴于新的數(shù)據(jù)，那么必須同時更新這些服務(wù)，如果訂閱服務(wù)部署失敗并回滾，則需要層級回滾。

你可能會認為在 NoSQL 數(shù)據(jù)庫中這些問題不存在，但事實并非如此。不強制執(zhí)行模式的數(shù)據(jù)庫并不意味著它是無模式系統(tǒng)。

它僅僅意味著模式在應(yīng)用級而不是數(shù)據(jù)庫級進行管理。理解數(shù)據(jù)的形狀及其演變過程的挑戰(zhàn)依然存在。

通信的復(fù)雜性往往被忽略

當(dāng)你建立一個相互依賴的大型網(wǎng)絡(luò)服務(wù)時，可能會涉及到很多服務(wù)間的通信，挑戰(zhàn)隨之而來。

首先，潛在的失敗無處不在。假設(shè)網(wǎng)絡(luò)調(diào)用失敗了，那么當(dāng)一個服務(wù)調(diào)用另一個服務(wù)失敗時，它至少應(yīng)當(dāng)重試幾次。服務(wù)之間的調(diào)用關(guān)系越多，那么情況將變得愈加復(fù)雜。

假設(shè)用戶上傳視頻到共享服務(wù)中。那么我們需要運行上傳服務(wù)，然后將數(shù)據(jù)傳遞到轉(zhuǎn)碼服務(wù)，此外，還得更新訂閱和推薦服務(wù)。所有這些調(diào)用都需要一定程度的協(xié)調(diào)，如果失敗，就得重試。

而重試邏輯可能很難管理。同步運行往往不是很穩(wěn)定，很容易失敗。在這種情況下，更可靠的解決方案是使用異步模式來處理通信。

此處面臨的挑戰(zhàn)是異步模式會使系統(tǒng)具有狀態(tài)性。如前所述，分布式系統(tǒng)和狀態(tài)系統(tǒng)很難處理。

當(dāng)一個微服務(wù)系統(tǒng)使用消息隊列進行服務(wù)內(nèi)通信時，基本上會有一個大的數(shù)據(jù)庫（消息隊列或代理）將這些服務(wù)粘合在一起。雖然起初看起來似乎沒什么問題，但模式始終是一個隱患。

新版本的服務(wù)可能會寫入新的格式的消息，當(dāng)發(fā)送服務(wù)更改發(fā)送消息的詳細信息時，依賴于該消息的服務(wù)也需要更新。

當(dāng)然可以擁有多個不同格式的消息處理服務(wù)，但數(shù)量一多就很難管理。當(dāng)部署一個新版本的服務(wù)時，兩個不同版本的服務(wù)可能會處理來自同一隊列的消息，盡管消息來自不同版本的發(fā)送服務(wù)，這可能會導(dǎo)致復(fù)雜的邊緣情況。

為了避免這些邊緣情況的產(chǎn)生，***是只允許特定版本的消息存在，這意味著你需要將一組服務(wù)的版本作為一個整體來部署，以確保先前版本的消息被適當(dāng)?shù)嘏懦?/p>

這再次表明，當(dāng)你深入細節(jié)時會發(fā)現(xiàn)獨立部署的想法可能與預(yù)期的有所差異。

版本控制變難

為了緩解前面提到的問題，我們需要謹(jǐn)慎管理版本。遵循像 Semver 這樣的標(biāo)準(zhǔn)能夠解決這個問題嗎？答案是否定的。

Semver 是一個利器，但是你仍然需要跟蹤協(xié)同工作的服務(wù)和 API 的版本。

這件事頗具挑戰(zhàn)，你可能自己都搞混，不知道哪個版本的服務(wù)可以一起正常工作。

在軟件系統(tǒng)中管理依賴關(guān)系是非常困難的，無論是節(jié)點模塊、Java 模塊、C 庫還是其他東西。獨立組件和單一整體之間的沖突很難處理。

當(dāng)依賴關(guān)系是靜態(tài)，并且能夠進行修補、更新、編輯的時候，挑戰(zhàn)在所難免。但是如果依賴關(guān)系本身是實時服務(wù)，那么你可能無法僅僅更新它們 - 你可能需要運行許多版本，或者直到整個系統(tǒng)得到修復(fù)。

分布式事務(wù)

在需要跨操作交易完整性的情況下，微服務(wù)可能會非常痛苦。分布式狀態(tài)很難處理，很多小的失敗單元可能會很難進行集群操作。

可以通過操作冪等性、重試機制等方法來避免這個問題，這些手段在許多情況下能夠起作用。

但有些情況你需要保證操作的事務(wù)性，要么成功，要么失敗，而不能處于失敗和成功的中間狀態(tài)。在微服務(wù)模型中想要解決這個問題或者實現(xiàn)事務(wù)難度是很大的。

微服務(wù)可能是一種變相的整體式模型

單獨的服務(wù)和組件可以獨立部署，但是在大多數(shù)情況下，你將不得不運行某種集群平臺，比如 Kubernetes。

如果你使用谷歌的 GKE 或者亞馬遜的 EKS 這樣的托管服務(wù)，它們會幫你完成復(fù)雜的集群管理。

但是，如果你自己管理集群的話，那么面對的是一個龐大而復(fù)雜的系統(tǒng)。雖然單個服務(wù)擁有前文提到的大量優(yōu)點，但是你依然需要非常小心。這個系統(tǒng)的部署、更新、故障轉(zhuǎn)移等等操作起來都不是那么簡單。

在大多數(shù)情況下，優(yōu)點能夠得到體現(xiàn)，但是仍然不要輕視或低估管理一個龐大而復(fù)雜的系統(tǒng)的難度。托管服務(wù)可能會有所幫助，但這些服務(wù)大都剛剛新起（例如，亞馬遜的 EKS 在 2017 年底才發(fā)布）。

微服務(wù)的狂熱將開始降溫

仔細考慮避免加入對微服務(wù)的狂熱追捧。為了幫助解決這個問題，我已經(jīng)注意到了一些你可能想問自己的問題，并列舉了問題的答案：

• 點擊下載 PDF 版本：microservice-questions.pdf（https://github.com/dwmkerr/blog/raw/master/2018/microservice-madness/images/microservice-questions.pdf）

不要把微服務(wù)和架構(gòu)混淆

沒有微服務(wù)架構(gòu)一說。微服務(wù)只是組件的另一種模式或?qū)崿F(xiàn)。不論微服務(wù)是否在系統(tǒng)中使用，它都與架構(gòu)無關(guān)。

微服務(wù)在許多方面與打包和操作的技術(shù)過程有關(guān)，而與系統(tǒng)設(shè)計無關(guān)。組件邊界仍然是工程系統(tǒng)中最重要的挑戰(zhàn)之一。

無論你的服務(wù)體量有多大，是否在 Docker 容器中，你都需要仔細考慮如何將系統(tǒng)放在一起。這里沒有標(biāo)準(zhǔn)答案，只是多一個選擇而已。

當(dāng)前文章：2018的陰謀論？Docker公司與微服務(wù)之死！
網(wǎng)站網(wǎng)址：http://www.fisionsoft.com.cn/article/cooehoc.html