2018的陰謀論？Docker公司與微服務之死！
月初，一篇題為《Docker 公司已死》的文章，預言了 Docker 公司將在 2018 年的某個時候不復存在。就這一觀點，緊接著出現了一篇《Docker 公司不會死》的文章進行了反駁。
Docker 公司已死 ！
Chris Short 在《Docker 公司已死》中寫道，對于 Docker 公司而言，將 2017 年形容為艱難的一年恐怕都有些輕描淡寫。
事實上，除了 Uber 之外，真的想不到其他哪家被沸沸揚揚的炒作新聞所包圍的硅谷初創企業會像 Docker 這樣經歷糟糕透頂的一年。
未來的人們在回顧 Docker 公司的發展歷程時，會將 2017 年視為這家重要軟件公司被糟糕商業慣例所摧毀，并最終走向滅亡的起點。
Docker 是款好軟件
需要明確的是，Docker 公司確實在軟件開發的這一波革新當中發揮了重要作用。能夠將 cgroups、命名空間、進程隔離等 Linux 原語納入至同一工具當中絕對是個了不起的成就。
Docker 的崛起使得開發環境最終轉化為一個簡單且具備版本控制能力的 Dockerfile。
它的工具鏈將 Packer、Vagrant、VirtualBox 以及其他多種基礎設施共同轉移至 Docker 陣營當中。Docker UI 實際上也做得相當出彩！
Docker 硅谷的新寵兒
Docker 公司的早期成功使其快速以產品為核心建立起一套龐大的社區。此外，快速發展同樣帶來了極為順利的資金流引入。
高盛、格雷洛克風投、紅杉資本以及洞見風投等紛紛為 Docker 公司提供大量資金。截至目前，Docker 公司的融資總額已經達到 2.42 億到 2.5 億美元之間。
雖然產品本身的質量值得肯定，但公司遭遇了一系列人力資源失誤。更遺憾的是，很多硅谷寵兒都存在這樣的問題，且顯然有必要作出改變。
Kubernetes 對 Docker 造成沖擊
隨著 Kubernete 的興起，Docker 公司的厄運可謂加速降臨。Docker 公司一直未能找到應對開源社區容器編排新寵 Kubernetes 的好辦法。
Docker 公司旗下的 Docker Swarm 是其所擁有的唯一容器編排工具。盡管 Kubernetes 率先向 Docker 容器示好，但 Docker 仍然拿出了自己的競爭性方案。
而且根據記錄，Docker 方面曾在 2017 年年初通過文章、會議乃至其他大型活動對 Kubernetes 表達不滿。
但通過本屆于奧斯汀召開的 DockerCon 17 大會來看，Docker 方面突然決定全力支持 Kubernetes。
這種突然的變化顯然是承認了 Kubernetes 的崛起已經不可阻擋。而 Docker 在 2017 年 KubeCon + CloudNativeCon 北美大會上再次陳述此項決定，無疑更進一步強調了這一結論。
Moby?
沒人了解 Docker 在去年 4 月的 DockerCon 17 大會上到底為什么要宣布 Moby。
Moby 據稱屬于 Docker 項目的新上游，然而考慮到事前毫無先兆，因此當 Solomon Hykes 在 DockerCon 17 大會上加以宣布時引發了大范圍的震驚與爭議性情緒。
為了解決這波沖突，GitHub 方面的工作人員甚至選擇直接加以干預。Moby 部署的處理工作仍然困擾著從來者們，而 Docker 品牌亦可能因此受到損害。
Kubernetes 的冰冷擁抱
Docker 公司對于 Kubernetes 在***一刻才張開的遲到且尷尬的擁抱，代表著其即將遭遇崩潰。問題在于，Docker Swarm 還遠遠稱不上成熟。
事實上，Docker Swarm 產品團隊及其少數開源貢獻者根本無法跟上 Kubernetes 社區那迅猛的發展步伐。
而且與 Docker UI 一樣，Kubernetes UI 同樣非常出色。就目前來看，Docker 公司本身似乎正開始淪為一家容器領域中的邊緣咨詢企業。
陰謀論：Docker 公司知道自己已經沒戲唱了。技術人員們決定大規模推出 Moby，并突然接納 Kubernetes，這些都是為了給自己爭取一點喘息之機。 #Docker #DevOps
——Chris Short (@ChrisShort) 2017年12月29日
Chris Short 最終得出結論：Docker 公司的真正問題在于缺乏連續的領導。在該公司當中，每一任***都擁有自己的戰略重點設定。
這種斷代性雖然距離公司的核心越來越遠，但卻仍然存在。很明顯，Docker 是在自取滅亡。
Docker“生死”記，這條船還能開出去多遠？
Dylan Chris 在《Docker 公司不會死》中寫道：雖然 Chris Short 的一些觀點是對的，但 Docker 并不會這么快就退出舞臺。
Docker 當然是款好軟件
將 cgroups、命名空間、進程隔離等 Linux 原語納入至同一工具當中，Docker 絕對是個了不起的好軟件。
Docker 的簡單界面降低了非管理員的入門門檻，允許開發者社區隨手將其添加到他們的工作流程中。
Docker 發布了 EE / UCP，一些大型企業也加入進來。這對于開發人員、中小型企業和大型企業來說 Docker 都是一款很好用的軟件，而且 Docker 也不會放慢開發的速度。
Docker 有朋友
微軟 Kubernetes 的***工程師 Brendan Burns：“我很高興歡迎 Solomon 和 Docker 加入 Kubernetes 社區”。在談到 Docker 時很多人都會引用這個聲明，認為這對 Docker 來說是一個很大的打擊。
但談到這一點的真正目的是談論公司之間的合作，并不是糾結于“到底是誰加入誰的社區”。
我們“需要一個村莊一起來養一個孩子”，這個村莊由來自世界上許多大公司的一些最聰明的工程師組成，他們都在努力使 Docker 變得更好。Docker 和 Kubernetes 的合作，對 Kubernetes 與 UCP 來說都非常有意義。
Docker 有業務
Docker 公司不會被收購或閉門。Docker 并不缺領導，也有大量的資金，營銷方面也不錯，所有的跡象都意味著這家公司正在迅速成長，正在進入企業市場。但成長得并不容易。他們的“現代化企業應用”口號是***的。
這是一個基于 OSS 的公司，市場上有著大量的機遇。雖然 Iron 的其中一款產品是基于 Docker 的，但我們也會大量使用來自 OSS 公司的各種軟件，也很樂意為 OSS 軟件提供更高層次的支持和功能。
對于其他項目，我們經常通過 Open Collective 捐贈來幫助維護人員和小型開發團隊。Docker 對 containerd 的捐贈是一個很好的舉措，這是一個完全符合 CNCF 章程的項目。
雖然 Docker 正在向“上流社會”移動，但他們并沒有拋棄真正的用戶：開發人員。總之，Docker 公司有很大的增長空間，而在 2018 年，它將持續實現增長。
隨后近期又出現了一篇“2018 瘋狂微服務之死”的陰謀論文章，詳細內容如下：
2018 瘋狂微服務之死
近期微服務的話題非常火爆，有時可謂非常“瘋狂”：
Netflix 在 DevOps 上做得很棒，同時 Netfix 也采用微服務。因此：如果我也用微服務，那么我也可以在 DevOps 方面做得很好。
很多情況下，為了解決手頭的問題，我們付出了巨大的努力采用微服務模式，但是并不清楚它的成本和收益。
接下來我將詳細介紹什么是微服務，這種模式吸引人的原因，以及它所面臨的主要挑戰。
如果你正在考慮微服務是否適合你的模式，我會在文章的***用一系列簡單的問題來幫你做出選擇。
微服務為什么如此受歡迎？
什么是微服務，它為什么如此受歡迎？首先從最基本的開始了解。下圖是一個假想的視頻共享平臺的實現方式，左側是傳統的整體式架構（單個巨型單元），右側則是微服務：
兩種模式的區別在于***種是整體式架構，只有一個大單元。第二種則由多個小單元構成，每個小單元都是獨立的服務。上圖已足夠細致，從中很容易找到微服務模式的吸引力所在。
以下是微服務架構的具體好處：
- 獨立開發：小型的獨立組件可由小型的獨立團隊構建。一個小組可以專門負責開發“Upload”服務，不用去管其他服務。每個組件的功能變得簡單，這樣一來，開發人員了解組件的時間大大減少，更容易開發新功能。
- 獨立部署：每個單獨的組件都可以獨立部署。這樣一來發布新功能的速度就更快，風險也更小。假設“Streaming”組件修復了 Bug 或者新增了功能，那么部署時并不會影響其他組件。
- 獨立擴展：每個組件可以獨立地進行擴展。在新節目剛發布的繁忙時期，可以擴展“Download”組件，以支持增加的負載，而不必擴展所有組件，這樣一來擴展更具彈性并且降低了成本。
- 可重用性：每個組件各自實現一個小的、特定的功能。這意味著它們可以很容易地適用于其他系統、服務或者產品。“Transcode”組件可以被其他業務單元使用，甚至可以改寫成一個新的業務，從而為其他組提供轉碼服務。
從以上細節層面可見，微服務模式相比整體式架構的好處顯而易見。如果確實是這樣的話——那為什么這種模式最近才開始流行呢？
微服務為什么沒有很早就開始流行？
既然微服務好處多多，為什么沒有很早就開始流行呢？原因有二：
- 它提升了我們的技術能力。
- 最近的技術進步讓我們能夠把它帶到一個新的水平。
當我開始寫這個問題的答案時，發現一兩句話無法解釋清楚，所以實際上我把它分成了另外一篇文章，稍后再發表。
因此在本文中，我將跳過從單個程序到多個程序的過程，忽略 ESBs 和面向服務的體系結構、組件設計以及有限的上下文等內容。
在很多方面我們已經開始使用微服務，隨著近期容器技術（特別是 Docker）和集群技術（如 Kubernetes、Mesos、Consul 等等）的普及，從技術的角度來看，微服務模式變得更加可行。
如果我們打算實施微服務，那么在開始之前需要想清楚。從理論的角度我們看到了它的優點，那么它有沒有弊端呢？
微服務有什么問題？
微服務模式優點多多，那么它的缺點是什么呢？據我所知它主要有下列問題。
開發的復雜性增加
對于開發者來說事情會變得更加困難。當開發人員開發一個新功能時，如果該功能依賴其他服務的話，那么開發人員不得不在他們的機器上運行所有服務，或者連接到這些服務。這通常比簡單地運行單個程序更加復雜。
這個問題可以通過一些工具得到部分緩解，但隨著構成系統的服務數量的增加，開發人員在整個系統運行時面臨的挑戰也越來越多。
運營的復雜性增加
對于維護服務的團隊來說，潛在的復雜性是一個巨大的挑戰。他們管理的服務不是簡單的幾個，而是數十、數百甚至數千個正在運行的服務。服務數量越多，通信鏈路就越多，那么出錯的可能性就會變大。
DevOps 的復雜性增加
以上兩點表示開發和運營是分開進行的，隨著 DevOps 的普及（我是 DevOps 的忠實粉絲），DevOps 能夠緩解這個問題嗎？
如今有許多組織仍然依靠獨立的開發和運營團隊來工作，而也有一些組織更傾向于采用微服務。
對于已經采用了 DevOps 的組織來說，這仍然很難。既是開發者又是運營者已經非常艱難（但是要建立好的軟件卻很關鍵）了，還得了解集群容器系統的細微差別，特別是快速發展的系統，那就更困難了。
它需要資深專家
如果開發團隊成員都是專家級別，那么結果可能會很好。但想象一下，一個使用單一的整體式系統運行的不是很順暢。如果增加系統的數量，就會增加運行的復雜性。
通過有效的自動化、監控和集群等技術可以做到。但瓶頸很少在于技術本身，而在于找到能夠有效使用這些技術的人。目前這些技能需求非常高，可能很難找到。
真實世界的系統往往界限不清
當我們描述微服務的好處時，經常談到獨立的組件。但是在很多情況下，組件并不是獨立的。在論文中，某些領域可能看起來有限，但是當你深入細節時，你會發現他們比你預期的更具挑戰性。
事情變得非常復雜。如果你的界限沒有明確的定義，那么即使理論上的服務可以單獨部署，你也會發現，由于服務之間的相互依存關系，你必須部署一組服務。
這意味著你需要一系列管理協同工作的服務版本，這些服務版本之間的協作需要通過驗證和測試，你實際上沒有可獨立部署的系統，為了部署新功能，你需要仔細編排并同時部署許多服務。
狀態的復雜性往往被忽略
在前面的例子中，我提到一個功能的部署可能需要同時部署多個版本的多個服務。
假設合理的部署技術可以緩解這種情況，例如 blue/green 部署（大多數服務編排平臺可輕松應對），或者并行運行的多個服務版本，以及決定使用哪個版本的通道。
如果服務是無狀態的，這些技術可以緩解大量的挑戰。但是無狀態服務非常容易處理。事實上，如果你有無狀態的服務，那么我會傾向于考慮跳過微服務，而考慮使用無服務器模型。
實際上，大多數服務都需要狀態。比如我們的視頻共享平臺例子中的訂閱服務。新版的訂閱服務可以用新的形式將數據存儲在訂閱數據庫中。
如果你并行運行兩個服務，則一次運行了兩個模式的系統。如果你進行了 blue green 部署，而其他服務依賴于新的數據，那么必須同時更新這些服務，如果訂閱服務部署失敗并回滾，則需要層級回滾。
你可能會認為在 NoSQL 數據庫中這些問題不存在，但事實并非如此。不強制執行模式的數據庫并不意味著它是無模式系統。
它僅僅意味著模式在應用級而不是數據庫級進行管理。理解數據的形狀及其演變過程的挑戰依然存在。
通信的復雜性往往被忽略
當你建立一個相互依賴的大型網絡服務時，可能會涉及到很多服務間的通信，挑戰隨之而來。
首先，潛在的失敗無處不在。假設網絡調用失敗了，那么當一個服務調用另一個服務失敗時，它至少應當重試幾次。服務之間的調用關系越多，那么情況將變得愈加復雜。
假設用戶上傳視頻到共享服務中。那么我們需要運行上傳服務，然后將數據傳遞到轉碼服務，此外，還得更新訂閱和推薦服務。所有這些調用都需要一定程度的協調，如果失敗，就得重試。
而重試邏輯可能很難管理。同步運行往往不是很穩定，很容易失敗。在這種情況下，更可靠的解決方案是使用異步模式來處理通信。
此處面臨的挑戰是異步模式會使系統具有狀態性。如前所述，分布式系統和狀態系統很難處理。
當一個微服務系統使用消息隊列進行服務內通信時，基本上會有一個大的數據庫（消息隊列或代理）將這些服務粘合在一起。雖然起初看起來似乎沒什么問題，但模式始終是一個隱患。
新版本的服務可能會寫入新的格式的消息，當發送服務更改發送消息的詳細信息時，依賴于該消息的服務也需要更新。
當然可以擁有多個不同格式的消息處理服務，但數量一多就很難管理。當部署一個新版本的服務時，兩個不同版本的服務可能會處理來自同一隊列的消息，盡管消息來自不同版本的發送服務，這可能會導致復雜的邊緣情況。
為了避免這些邊緣情況的產生，***是只允許特定版本的消息存在，這意味著你需要將一組服務的版本作為一個整體來部署，以確保先前版本的消息被適當地排除。
這再次表明，當你深入細節時會發現獨立部署的想法可能與預期的有所差異。
版本控制變難
為了緩解前面提到的問題，我們需要謹慎管理版本。遵循像 Semver 這樣的標準能夠解決這個問題嗎？答案是否定的。
Semver 是一個利器，但是你仍然需要跟蹤協同工作的服務和 API 的版本。
這件事頗具挑戰，你可能自己都搞混，不知道哪個版本的服務可以一起正常工作。
在軟件系統中管理依賴關系是非常困難的，無論是節點模塊、Java 模塊、C 庫還是其他東西。獨立組件和單一整體之間的沖突很難處理。
當依賴關系是靜態，并且能夠進行修補、更新、編輯的時候，挑戰在所難免。但是如果依賴關系本身是實時服務，那么你可能無法僅僅更新它們 - 你可能需要運行許多版本，或者直到整個系統得到修復。
分布式事務
在需要跨操作交易完整性的情況下，微服務可能會非常痛苦。分布式狀態很難處理，很多小的失敗單元可能會很難進行集群操作。
可以通過操作冪等性、重試機制等方法來避免這個問題，這些手段在許多情況下能夠起作用。
但有些情況你需要保證操作的事務性，要么成功，要么失敗，而不能處于失敗和成功的中間狀態。在微服務模型中想要解決這個問題或者實現事務難度是很大的。
微服務可能是一種變相的整體式模型
單獨的服務和組件可以獨立部署，但是在大多數情況下，你將不得不運行某種集群平臺，比如 Kubernetes。
如果你使用谷歌的 GKE 或者亞馬遜的 EKS 這樣的托管服務，它們會幫你完成復雜的集群管理。
但是，如果你自己管理集群的話，那么面對的是一個龐大而復雜的系統。雖然單個服務擁有前文提到的大量優點，但是你依然需要非常小心。這個系統的部署、更新、故障轉移等等操作起來都不是那么簡單。
在大多數情況下，優點能夠得到體現，但是仍然不要輕視或低估管理一個龐大而復雜的系統的難度。托管服務可能會有所幫助，但這些服務大都剛剛新起（例如，亞馬遜的 EKS 在 2017 年底才發布）。
微服務的狂熱將開始降溫
仔細考慮避免加入對微服務的狂熱追捧。為了幫助解決這個問題，我已經注意到了一些你可能想問自己的問題，并列舉了問題的答案：
- 點擊下載 PDF 版本：microservice-questions.pdf（https://github.com/dwmkerr/blog/raw/master/2018/microservice-madness/images/microservice-questions.pdf）
不要把微服務和架構混淆
沒有微服務架構一說。微服務只是組件的另一種模式或實現。不論微服務是否在系統中使用，它都與架構無關。
微服務在許多方面與打包和操作的技術過程有關，而與系統設計無關。組件邊界仍然是工程系統中最重要的挑戰之一。
無論你的服務體量有多大，是否在 Docker 容器中，你都需要仔細考慮如何將系統放在一起。這里沒有標準答案，只是多一個選擇而已。
