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

[[218908]]

Docker 公司已死 ！

[[218909]]

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

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

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

Docker 是款好軟件

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

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

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

Docker 硅谷的新寵兒

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

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

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

Kubernetes 對 Docker 造成沖擊

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

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

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

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

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

Moby?

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

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

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

Kubernetes 的冰冷擁抱

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

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

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

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

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

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

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

Docker“生死”記，這條船還能開出去多遠(yuǎn)？

[[218910]]

Dylan Chris 在《Docker 公司不會(huì)死》中寫道：雖然 Chris Short 的一些觀點(diǎn)是對的，但 Docker 并不會(huì)這么快就退出舞臺(tái)。

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

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

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

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

Docker 有朋友

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

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

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

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

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

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

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

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

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

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

近期微服務(wù)的話題非?；鸨?，有時(shí)可謂非常“瘋狂”：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DevOps 的復(fù)雜性增加

以上兩點(diǎn)表示開發(fā)和運(yùn)營是分開進(jìn)行的，隨著 DevOps 的普及（我是 DevOps 的忠實(shí)粉絲），DevOps 能夠緩解這個(gè)問題嗎？

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

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

它需要資深專家

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

版本控制變難

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

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

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

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

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

分布式事務(wù)

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

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

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

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

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

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

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

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

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

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

• 點(diǎn)擊下載 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è)計(jì)無關(guān)。組件邊界仍然是工程系統(tǒng)中最重要的挑戰(zhàn)之一。

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