我們公司放棄了微服務(wù)，重回單體架構(gòu)
每當(dāng)我們將 InVision 的一個微服務(wù)合并回單體的時候，我都會發(fā)一條慶祝的推文。在這些推文中，我都喜歡包含一張關(guān)于滅霸的動圖，這張動圖就是滅霸將最后一顆無限寶石放到無限手套中。我覺得這張動圖非常合適，因為集齊寶石給了滅霸巨大的能量，就像重新整合微服務(wù)給了我和團隊力量一樣。
曾經(jīng)有多次，許多人問我為何要干掉微服務(wù)。所以，我想和大家分享在 Web 開發(fā)領(lǐng)域這一段旅程的特殊見解。
開篇，澄清一下，我并不是反微服務(wù)。
我將服務(wù)重新合并成單體并不意味著要將微服務(wù)從生活中徹底驅(qū)趕出去。這個任務(wù)的目標(biāo)是 “調(diào)整”單體的大小。這樣做是為了解決團隊的痛點。如果不能減少沖突，那么我就不會花費 那么多的時間（和機會成本） 來提升、轉(zhuǎn)移和重構(gòu)舊的代碼。
每當(dāng)這樣做的時候，我都冒著引入新 bug 和破壞用戶體驗的風(fēng)險。將微服務(wù)合并成單體架構(gòu)的過程中，雖然有時候很令人興奮，但總體還是令人感到恐懼的，而且需要大師級的規(guī)劃、風(fēng)險控制和測試。再次強調(diào)一遍，如果它不值得做的話，我就不會做了。
為了理解我為何要銷毀一些微服務(wù)，首先很重要的一點就是要理解為什么一開始要創(chuàng)建這些微服務(wù)。
微服務(wù)解決的是兩種類型的問題，也就是 技術(shù)的問題 和 人的問題。
技術(shù)的問題 在于應(yīng)用程序的某個方面給基礎(chǔ)設(shè)施帶來了過重負(fù)擔(dān)，這反過來又很可能會導(dǎo)致糟糕的用戶體驗（UX）。例如，圖像處理需要大量的 CPU。如果 CPU 的負(fù)載變得非常高，這將會導(dǎo)致應(yīng)用其他處理資源的餓死現(xiàn)象。這會影響系統(tǒng)的延遲。而且，如果更糟糕的話，那么這會影響系統(tǒng)的可用性。
另一方面，人的問題 與應(yīng)用的關(guān)系并不大，它關(guān)系到你會如何組織團隊。在應(yīng)用程序的特定部分，投入工作的人越多，開發(fā)和部署就會越慢，而且越容易出錯。例如，如果你有 30 個工程師都在競爭“持續(xù)部署（CD）”同一個服務(wù)，就會出現(xiàn)很多排隊的現(xiàn)象，這意味著很多本可以交付產(chǎn)品的工程師只能坐等輪到他們進(jìn)行部署。
自 8 年前成立以來，InVision] 一直都是一個單體系統(tǒng)，當(dāng)時只有3 個工程師。隨著公司的成長和發(fā)展，系統(tǒng)的數(shù)量幾乎沒有增加，但是工程團隊的規(guī)模卻在快速擴張。幾年的時間，我們有了幾十名工程師，包括前端和后端，他們在同一個代碼庫上開展工作，所有的部署都會到同一個服務(wù)隊列中。
如前文所述，大量的人在同一個地方工作會產(chǎn)生很大的問題。不僅各種團隊會競爭相同的部署資源，而且每當(dāng)遇到“緊急事件”的時候，多個團隊的代碼都需要回滾。而且，在處理事件的時候，所有團隊都不能進(jìn)行部署。可以想象，這會在整個組織造成很多摩擦，對工程團隊和產(chǎn)品團隊均是如此。
同時，“微服務(wù)”的出現(xiàn)是解決“人的問題”的。一群選定的工程師圍繞他們認(rèn)為的與團隊邊界相對應(yīng)的應(yīng)用組成部分開始劃分邊界。這樣做的目的是為了讓團隊能更加獨立地工作，獨立地部署，從而發(fā)布更多產(chǎn)品。早期的 InVision 微服務(wù)幾乎與解決技術(shù)問題毫無關(guān)系。
如果你從事微服務(wù)的話，那么肯定聽說過“康威定律”，它是由 Melvin Conway 在 1967 年提出的：
任何設(shè)計系統(tǒng)（廣義定義）的組織，必然會產(chǎn)生以下設(shè)計結(jié)果：即其系統(tǒng)的結(jié)構(gòu)就是該組織溝通結(jié)構(gòu)的寫照。
該定律通常以“編譯器”為樣例進(jìn)行說明：
如果有四個組在從事一個編譯器相關(guān)的工作，那么這個編譯器肯定是要分四個步驟的。
這里的觀點在于，解決方案是圍繞團隊結(jié)構(gòu)（和團隊通信開銷）進(jìn)行“優(yōu)化”的，而不一定是為了解決特定的技術(shù)或性能問題。
在微服務(wù)出現(xiàn)之前，康威定律一般都是以負(fù)面的角度來進(jìn)行討論的。比如，康威定律代表著你的應(yīng)用規(guī)劃和組織比較糟糕。但是，在后微服務(wù)時代，康威定律有了更多的維度。因為事實證明，如果你能將系統(tǒng)分解為一組具有 內(nèi)聚邊界 的 獨立服務(wù)，那么就能以更少的 bug 發(fā)布產(chǎn)品，因為你所創(chuàng)建的團隊更專注于一組服務(wù)，而這些服務(wù)具備更窄小的職責(zé)范圍。
當(dāng)然，康威定律的收益在很大程度上依賴于在哪里劃分邊界以及這些邊界 隨時間的推移該如何變化。這也就是我和我的 Rainbow 團隊的職責(zé)所在。
多年來，InVision 必須要從組織和基礎(chǔ)設(shè)施方面進(jìn)行發(fā)展。這意味著，在其背后，有一個較老的“遺留”平臺和一個不斷發(fā)展的“現(xiàn)代”平臺。隨著越來越多的團隊遷移至“現(xiàn)代”平臺，這些團隊之前負(fù)責(zé)的服務(wù)則要移交給剩下的“遺留”團隊。
如今，我的團隊就是遺留團隊。這個團隊已經(jīng)緩慢，但穩(wěn)定地負(fù)責(zé)越來越多的服務(wù)。這意味著：人數(shù)變少了，但是代碼倉庫變多了，編程語言變多了，數(shù)據(jù)庫變多了，監(jiān)控儀表盤變多了，錯誤日志變多了。
簡而言之，康威定律為組織帶來的所有收益，隨著時間的推移，都變成“遺留”團隊的負(fù)債。所以，我們一直在努力“調(diào)整”責(zé)任域，讓平衡回歸康威定律?；蛘撸瑩Q句話說，我們在嘗試改變服務(wù)邊界以匹配團隊的邊界。這意味著，將微服務(wù)重新合并為單體架構(gòu)。
也許，微服務(wù)架構(gòu)最糟糕的事情就是用了“微”這個字?！拔ⅰ笔且粋€毫無意義，但具有沉重負(fù)擔(dān)的術(shù)語，它實際上代表了歷史原因和人們的偏見。更合適的術(shù)語應(yīng)該是“合適的大小”。微服務(wù)的目的從來不是成為“小的服務(wù)”，而是成為“大小合適”的服務(wù)。
“微”這個術(shù)語毫無意義，不代表任何實際的內(nèi)容。而“合適的大小”意味著服務(wù)經(jīng)過了 恰當(dāng)?shù)卦O(shè)計，以滿足其需求：它負(fù)責(zé)“合適數(shù)量”的功能。而且，至于什么是“合適”并不是一個靜態(tài)的概念，它取決于團隊，即團隊的技能集、組織的狀態(tài)、投資回報率（return-on-investment，ROI）的計算、持有成本以及該服務(wù)運行的時間點。
對我的團隊來說，“合適的大小”意味著更少的代碼倉庫，更少的部署隊列，更少的語言以及更少的運維儀表盤。對于這個非常小的團隊來說，“合適的大小”更多的是關(guān)于“人”，而不是關(guān)于“技術(shù)”。所以，就像 InVision 最初引入微服務(wù)是解決“人的問題”一樣，我們團隊現(xiàn)在摧毀這些微服務(wù)也是為了解決“人的問題”。
姿態(tài)是一樣的，只是表現(xiàn)形式有所不同。
我為團隊在遺留平臺上所付出的努力而感到自豪。雖然團隊規(guī)模不大，但是我們利用自己所擁有的東西完成了很多的工作。我把這種成功歸功于我們對遺留平臺的深入了解，積極的實用主義，以及不斷努力設(shè)計一個能對應(yīng)我們能力的系統(tǒng)，而不是試圖擴大我們的能力以滿足系統(tǒng)需求。這可能聽起來很狹隘，但是，這是我們團隊及其所擁有的資源在這個時刻唯一可行的方法。
支撐創(chuàng)建獨立服務(wù)的論據(jù)之一就是這些服務(wù)是可以“獨立擴展”的。也就是說，可以更有針對性地提供服務(wù)器和數(shù)據(jù)庫，以滿足服務(wù)的需求。因此，與其創(chuàng)建大型的服務(wù)卻只擴展其中一部分功能，我們能夠在獨立擴展其他服務(wù)的同時，讓某些服務(wù)保持規(guī)模很小的狀態(tài)。
在所有關(guān)于為什么說獨立服務(wù)是一件“好事”的理由中，這個理由經(jīng)常被提及，但是在我（有限的經(jīng)驗）看來，這通常是不成立的。除非某項功能是 CPU 密集、IO 密集 或 內(nèi)存密集 的，否則獨立的可擴展性可能并不是你需要擔(dān)心的“能力”。很多時候，你的服務(wù)器都在等著做事情，為一個應(yīng)用程序添加“更多的 HTTP 路由處理程序”并不會突然耗盡它所有的資源。
如果我能回到過去，重新嘗試我們的微服務(wù)，我 100% 會先關(guān)注所有 “CPU 密集”的功能：圖像處理和調(diào)整大小、縮略圖生成、PDF 導(dǎo)出、PDF 導(dǎo)入、使用rdiff的文件版本管理、ZIP 壓縮文件生成。
我會沿著這些邊界組織團隊，讓他們創(chuàng)建“純的”服務(wù)，只處理輸入和輸出（即，沒有“集成數(shù)據(jù)庫”，也沒有“共享文件系統(tǒng)”），這樣其他所有的服務(wù)都可以使用它們，同時保持了松耦合。
我并不是說這樣就能解決我們所有的問題 -- 畢竟我們的“人的問題”比 “技術(shù)的問題”要多。但是，它可以解決一些“合適性”的問題，從長遠(yuǎn)來看，這可能會讓生活變得更輕松一些。
服務(wù)并不是在抽象地運行：它們要在服務(wù)器上運行，與數(shù)據(jù)庫通信，報告度量指標(biāo)并且還會生成日志條目。所有的這些都需要真正的經(jīng)濟成本。所以，盡管“l(fā)ambda 函數(shù)”在我們不使用它們的時候，不會花掉我們的錢，但是大多數(shù)“微服務(wù)”肯定還是會花錢的。特別是當(dāng)我們?yōu)榱藙?chuàng)建一個“高可用”的系統(tǒng)而需要維護(hù)冗余的時候。
我的團隊將微服務(wù)重新合并成單體架構(gòu)對業(yè)務(wù)帶來了切實的經(jīng)濟影響（這種影響是正面的）。這種影響并不巨大，我們只是在談?wù)撘恍┬⌒偷姆?wù)，但也不是微乎其微。所以，在將系統(tǒng)合并之后，我們不僅得到了“人”的方面的收益，還得到了實際的經(jīng)濟收益。
原文鏈接：https://www.bennadel.com/blog/3944-why-ive-been-merging-microservices-back-into-the-monolith-at-invision.htm
企業(yè)級微服務(wù)架構(gòu)統(tǒng)一安全認(rèn)證設(shè)計與實踐！
我在一個公司死磕了10年??！
