Twitter 下架部分微服務，是微服務錯了？

就在 Twitter 的部分微服務被新任 CEO 馬斯克勒令下架之際，部分用戶很快報告稱自己無法正常登錄軟件。此前，馬斯克曾將這些被關閉的微服務稱爲 “膨脹軟件”，但粗暴剔除使得一些用戶的雙因素身份驗證出了問題。Twitter 最終解決了問題，可微服務在 IT 架構中的作用因此受到了質疑。

在此次 Twitter 事件中，砍掉部分微服務就像是用力抽出纏結線團中的一個線頭，意外解開了幾個重要的結。但藉此機會，其他組織也想思考自己能不能不用微服務，還是說微服務架構已經與自身運營體系緊密綁定、一損俱損。

Pulumi 公司 CEO Joe Duffy 就微服務融入 IT 架構的態勢、帶來的助益，以及如何在 IT 管理者的疏忽下成爲新的遺留技術債務發表了觀點。

微服務在 IT 架構中處於什麼位置？

在我的腦海裏有這樣一道光譜，兩端分別是單體式架構和完全分佈式架構。微服務就處於這道光譜中更偏向完全分佈式架構的位置。雲計算的普及讓我們能夠以全新方式思考事物。想想真正的分佈式應用程序架構，我們就是從 “雙虛擬機加單數據庫” 的時代步步前行，通過託管服務、容器再到無服務器架構最終來到了完全分佈式的彼岸。而微服務無疑在其中扮演了重要角色。

現代雲確實加速了向這些架構的轉變，但不同架構其實各有利弊，絕不是越新越好。微服務雖然活動組件更多、複雜性更高，但也提供了一種將服務置於 API 邊界，藉此將複雜度控制在合理範圍內的辦法。

亞馬遜在這方面的早期探索最爲典型，因爲 Bezos 要求各團隊必須通過 API 進行通信。這就產生了一種觀念，即各個團隊分別運行不同的服務，而服務間由軟件連通——靠的是 API，而不再是人。這有助於不同團隊分別獨立行動，但又能協同達成約定的功能。不過可以想見，這樣的體系也往往會過度膨脹，而且底層的複雜性只是被掩蓋住了、並沒被真正消除。

一旦把這些麻煩藏在 API 背後，人們就很容易往那一丟、再也不管。現實情況就是，很多企業實際可能只需要 5 項微服務，但實際微服務數量卻成千上萬。這就是所謂過度膨脹，但我認爲還算是發展歷程中的正常階段。

微服務跟清晰分層、井井有條的傳統 IT 架構來比較，孰優孰劣？

微服務當然有自己的優勢，它能大大降低系統運行的門檻。它提供 API，所以一次 API 調用就能獲得所需功能。其實把功能抽象成微服務是件好事，意味着我們不再需要頻繁思考怎麼操作這些功能。只需要啓動、運行、調用，就這麼簡單。

微服務也可能成爲遺留系統、成爲不再增值的系統，但這同樣不是壞事——畢竟任何人的腦容量都是有限的，如果把這些已經固化的部分都塞進龐大的單一系統，那就根本沒法管理了。藉助微服務，我們可以對平臺的不同功能做明確劃分，然後分別放在 API 和微服務後面。當然，這種遺產或者說債務也確實會隨時間推移而不斷累積。

那有沒有人呼籲簡化微服務，嘗試解決這方面的難題？

其實跟任何事物一樣，微服務也有自己的 Gartner 炒作週期——先是期望過高的峯值，然後走向幻想破滅的低谷。微服務的低谷期應該已經過了，但整個發展歷程仍然值得一說。坦率地講，很多人其實是在不適合的場景中使用微服務，甚至是爲了微服務而微服務。

Kubernetes 那邊也有類似的狀況：每個人都想用一把 Kubernetes，卻沒有考慮到自己的需求規模到底有沒有必要。微服務在炒作週期中比 Kubernetes 中走得更遠，所以使用方式也更合理一點了。

要解答這個問題，我們可能需要退回一步，想想自己到底要讓這套系統實現什麼功能。比如說當我們手頭有上千項微服務，那就很容易迷失方向，搞不清當初到底想用它們實現什麼功能、系統構建的最優方法是什麼。另外，微服務在正常使用下也會保持有機增長。剛開始，我們創建服務、發佈服務、部署 API；接下來就是調用 API，再據此構建新的服務。這就創造出了一個相互依存、彼此關聯的微服務網絡。

如果單體式架構能夠滿足需求，那不妨優先採用。但隨着團隊規模的擴大，單體式架構往往開始成爲瓶頸。所以正確的答案在於權衡，不存在銀彈式的終極真理。

是否存在最適合的微服務應用場景？與之對應，有沒有明確不適用微服務架構的場景？

亞馬遜雲科技就是典型的微服務應用案例。看看他們的產品組合，400 多種不同且彼此獨立的服務堆疊起來，而且每項服務都有自己的 API。因此亞馬遜擁有獨特的內部組織方式，各團隊就是自己產品和服務的所有者。這種架構跟業務組織是高度統一的，如果不選擇這種運營方式，我很難想象他們能夠建立起如何龐大的雲服務平臺。

而相對比較複雜的是那種 “灰色” 區域，比如說 Stripe。Stripe 也屬於服務集合和產品集合。我敢肯定，其中的身份驗證服務跟信用卡計費和其他計量服務肯定彼此獨立，而報告跟分析服務又是額外的部分。作爲一家物流配送企業，Stripe 關注的是產品運輸中的實施細節，所以我估計他們肯定是找到了單體跟分佈之間的理想平衡。

總之，產品越簡單、本質越單一，就越沒必要把它拆分成多個彼此獨立的服務。

但如果一家企業深度擁抱微服務，但突然被迫放棄這條路，結果會怎麼樣？

其實這類架構決策不存在 “突然被迫放棄” 這種情況，它們反映的可是非常深刻的問題。微服務的優勢在於不同事物之間在物理上相互獨立，甚至各自運行在不同服務器上並由 API 連通。這些 API 肯定會影響性能。

所以要想放棄這樣的架構設計，肯定需要審慎考量，比如 “既然我們不需要這些服務，能不能直接關掉？” 但這並不是微服務特有的問題，只是在微服務架構中容易被忽略的問題。只要運行軟件，這樣的問題就總會存在。爲什麼你會有那麼多根本不需要的服務？要想保留並整合這麼多服務，本身就是會是個重大的架構變化，微不微服務都一樣。

作者：李斌

來源：分佈式實驗室

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/CZ_XUBCLG6l7arW9VbsM-A