放棄了無服務(wù)器和微服務(wù)架構(gòu)的亞馬遜，降低了 90% 的成本，這在業(yè)界了不小的轟動，也讓其他企業(yè)開始思考，是否 應(yīng)該效仿。
作者 | DAVID HEINEMEIER HANSSON
譯者 | 彎月 責(zé)編 | 鄭麗媛
出品 | CSDN（ID：CSDNnews）
最近，亞馬遜的 Prime Video 團隊發(fā)布了一則案例研究，說他們決定放棄無服務(wù)器、微服務(wù)架構(gòu)，并用單體取而代之——此舉為他們節(jié)省了 90%（震驚！）的運營成本，并簡化了系統(tǒng)。
除了為他們的明智之舉點贊外，我認(rèn)為整個行業(yè)都能從這個故事中學(xué)到一個重要的經(jīng)驗教訓(xùn)：
“我們最初的解決方案采用了無服務(wù)器組件的分布式系統(tǒng)……理論上，我們能夠獨立擴展每個服務(wù)組件。但是，我們使用某些組件的方式，導(dǎo)致服務(wù)在負(fù)荷僅為預(yù)期值的 5% 時就達到了瓶頸。”
他們的這番話總結(jié)了長期以來席卷科技行業(yè)的微服務(wù)熱潮：理論上。
如今我們看到了所有這些理論的真實結(jié)果：很明顯，在實踐中，微服務(wù)是一種致命的誘惑，會為系統(tǒng)帶來不必要的復(fù)雜性。而無服務(wù)器只會令情況進一步惡化。
這個故事的獨特之處還在于，亞馬遜是最早的一批采用面向服務(wù)架構(gòu)的典型代表。面向服務(wù)架構(gòu)遠(yuǎn)比微服務(wù)更合理，這是一種組織架構(gòu)模式，用于處理公司內(nèi)部的海量通信，遠(yuǎn)遠(yuǎn)優(yōu)于定期的協(xié)調(diào)會議。
對于亞馬遜的規(guī)模來說，采用 SOA 更合適，因為沒有任何一個團隊能掌握 駕駛這樣一支 “超級油輪艦 隊”所需的一切。相比之下，團隊之間的協(xié)調(diào)依賴于 API 是一種天才之舉。
然而，與許多優(yōu)秀的想法一樣，這種模式一旦在原有的環(huán)境之外采用就會“變質(zhì)”，甚至一旦被推入單一應(yīng)用程序架構(gòu)的內(nèi)部，就會造成嚴(yán)重破壞——而這恰好就是我們使用微服務(wù)的方式。
從許多方面來看，微服務(wù)是一種早已入土的架構(gòu)、一種拒絕死亡的知識傳播“ 病菌”。從 J2EE 的黑暗時代開始，這種 “病菌”就消耗了大量的人力物力，如今又蔓延到了微服務(wù)和無服務(wù)器。
但如今這第三波浪潮似乎達到了巔峰，Kube.NETes 背后的主要推動力量之一 Kelsey Hightower 在 2020 年曾表示：
“我們要打破單體服務(wù)，并以某種方式找到我們從未有過的工程原則……如今我們從編寫糟糕的代碼轉(zhuǎn)變成了構(gòu)建糟糕的基礎(chǔ)設(shè)施。
因為基礎(chǔ)設(shè)施帶來了很多新的支出，因此我們需要更多人手……很多人沉迷于資本和營銷帶來的繁榮，而實際上這只是一種營銷手段，無法解決根本問題。”
無論在何種情況下，將某個團隊和應(yīng)用程序中的方法調(diào)用和模塊分離換成網(wǎng)絡(luò)調(diào)用和服務(wù)分區(qū)，都是一種瘋狂的舉動。
我很高興，我們能夠在第三次熱潮中擊敗這種可怕的僵尸襲擊，但我們?nèi)孕璞３志瑁灰氐父厕H，有些壞點子是無論殺多少次都死不了的。你所能做的是，看清楚它們何時死灰復(fù)燃，然后拿到武器，裝好彈藥，準(zhǔn)備射擊。
