架構(gòu)有時(shí)很難——人們不斷提出一些新想法，這些想法很快成為主流的“做事方式”，微服務(wù)是最新的趨勢(shì)，現(xiàn)在是我們剖析這個(gè)想法并找到正在發(fā)生的事情的真正根源的時(shí)候了。

在微服務(wù) 的核心，我們被告知我們會(huì)發(fā)現(xiàn)…… ...

很多好東西 (TM)！

• “可擴(kuò)展性”：“代碼可以分解成更小的部分，可以獨(dú)立開發(fā)、測(cè)試、部署和更新?！?/li>
• “Focus”：“……開發(fā)人員專注于解決業(yè)務(wù)問題和業(yè)務(wù)邏輯?！?/li>
• “可用性”：“后端數(shù)據(jù)必須始終可用于各種設(shè)備……”
• “簡(jiǎn)單性”：“提供了大型企業(yè)級(jí)應(yīng)用程序的簡(jiǎn)化開發(fā)。”
• “響應(yīng)能力”：“......使分布式應(yīng)用程序能夠擴(kuò)展是對(duì)不斷變化的事務(wù)負(fù)載的響應(yīng)......”
• “可靠性”：“通過提供可在發(fā)生故障時(shí)繼續(xù)運(yùn)行的復(fù)制服務(wù)器組來確保沒有單點(diǎn)故障。在發(fā)生故障后將正在運(yùn)行的應(yīng)用程序恢復(fù)到良好狀態(tài)。”

這些聽起來都比較熟悉，我想，但是關(guān)于這六個(gè)引用的有趣部分是兩個(gè)來自微服務(wù)文獻(xiàn)（博客文章、論文等），兩個(gè)來自 20 年前的 EJB 文獻(xiàn)，兩個(gè)來自 Oracle，這是四十多年前的技術(shù)。在這個(gè)行業(yè)中，我們傾向于一遍又一遍地重復(fù)使用我們的炒作點(diǎn)。

關(guān)于微服務(wù)炒作，一家公司的博客文章[1]提供了10 個(gè)采用微服務(wù)的理由：

1. 他們推廣大數(shù)據(jù)最佳實(shí)踐。微服務(wù)自然適合面向數(shù)據(jù)管道的架構(gòu)，該架構(gòu)符合大數(shù)據(jù)的收集、攝取、處理和交付方式。數(shù)據(jù)管道中的每個(gè)步驟都以微服務(wù)的形式處理一個(gè)小任務(wù)。
2. 它們相對(duì)容易構(gòu)建和維護(hù)。它們的單一用途設(shè)計(jì)意味著它們可以由較小的團(tuán)隊(duì)構(gòu)建和維護(hù)。每個(gè)團(tuán)隊(duì)都可以是跨職能的，同時(shí)也可以專注于解決方案中的微服務(wù)子集。
3. 它們支持更高質(zhì)量的代碼。將整體解決方案模塊化為離散組件有助于應(yīng)用程序開發(fā)團(tuán)隊(duì)一次專注于一小部分。這簡(jiǎn)化了整個(gè)編碼和測(cè)試過程。
4. 它們簡(jiǎn)化了跨團(tuán)隊(duì)的協(xié)調(diào)。與通常涉及重量級(jí)進(jìn)程間通信協(xié)議的傳統(tǒng)面向服務(wù)架構(gòu) (SOA) 不同，微服務(wù)使用事件流技術(shù)來實(shí)現(xiàn)更輕松的集成。
5. 它們支持實(shí)時(shí)處理。微服務(wù)架構(gòu)的核心是發(fā)布-訂閱框架，支持實(shí)時(shí)數(shù)據(jù)處理以提供即時(shí)輸出和洞察。
6. 它們促進(jìn)快速增長(zhǎng)。微服務(wù)使代碼和數(shù)據(jù)重用模塊化架構(gòu)，更容易部署更多數(shù)據(jù)驅(qū)動(dòng)的用例和解決方案以增加業(yè)務(wù)價(jià)值。
7. 它們可以實(shí)現(xiàn)更多輸出。數(shù)據(jù)集通常以不同的方式呈現(xiàn)給不同的受眾；微服務(wù)簡(jiǎn)化了為各種最終用戶提取數(shù)據(jù)的方式。
8. 更容易評(píng)估應(yīng)用程序生命周期中的更新。高級(jí)分析環(huán)境，包括那些用于機(jī)器學(xué)習(xí)的分析環(huán)境，需要一些方法來根據(jù)新創(chuàng)建的模型評(píng)估現(xiàn)有的計(jì)算模型。微服務(wù)架構(gòu)中的 AB 和多變量測(cè)試使用戶能夠驗(yàn)證他們更新的模型。
9. 它們使規(guī)模成為可能?？缮炜s性不僅僅是處理更多容量的能力。這也與所涉及的努力有關(guān)。微服務(wù)可以更輕松地識(shí)別擴(kuò)展瓶頸，然后在每個(gè)微服務(wù)級(jí)別解決這些瓶頸。
10. 許多流行的工具都可用。大數(shù)據(jù)世界中的各種技術(shù)（包括開源社區(qū)）在微服務(wù)架構(gòu)中運(yùn)行良好。Apache Hadoop、Apache Spark、NoSQL 數(shù)據(jù)庫和許多流分析工具可用于微服務(wù)。

讓我們花點(diǎn)時(shí)間檢查一下其中的每一個(gè)，但這次是根據(jù)現(xiàn)有技術(shù)：

• 他們推廣大數(shù)據(jù)最佳實(shí)踐。自 70 年代以來，管道和過濾器架構(gòu)[2]一直是軟件領(lǐng)域的一部分，當(dāng)時(shí)Unixes 提出了幾個(gè)想法[3]：

  • 讓每個(gè)程序做好一件事。要完成一項(xiàng)新工作，請(qǐng)重新構(gòu)建而不是通過添加新“功能”使舊程序復(fù)雜化。
  • 期望每個(gè)程序的輸出成為另一個(gè)未知程序的輸入。不要用無關(guān)信息混淆輸出。嚴(yán)格避免列式或二進(jìn)制輸入格式。不要堅(jiān)持交互式輸入。

• 它們相對(duì)容易構(gòu)建和維護(hù)。請(qǐng)參閱上面的 Unix 哲學(xué)。

• 它們支持更高質(zhì)量的代碼。如果一次專注于一小部分有助于提高質(zhì)量，那么請(qǐng)參閱上面的 Unix 哲學(xué)。

• 它們簡(jiǎn)化了跨團(tuán)隊(duì)的協(xié)調(diào)。這個(gè)很有趣；它表明“面向服務(wù)的體系結(jié)構(gòu)（SOA）……通常涉及重量級(jí)進(jìn)程間通信協(xié)議”——比如 JSON over HTTP？或者這是否意味著所有 SOA 都需要 SOAP、WSDL、XML Schema 和 WS-* 規(guī)范的完整集合？具有諷刺意味的是，微服務(wù)并沒有以任何方式阻止它使用任何這些“重量級(jí)”協(xié)議，并且一些微服務(wù)甚至建議使用 gRPC，這是一種與 IIOP 更相似的二進(jìn)制協(xié)議，來自 CORBA，它是“重量級(jí)”協(xié)議”的前身...... SOAP、WSDL、XML Schema 和 WS-* 規(guī)范的完整集合。

• 它們支持實(shí)時(shí)處理。實(shí)時(shí)處理實(shí)際上已經(jīng)存在了很長(zhǎng)一段時(shí)間，雖然許多此類系統(tǒng)使用發(fā)布-訂閱或“事件總線”模型來完成它，但它幾乎不需要微服務(wù)來完成。

• 它們促進(jìn)快速增長(zhǎng)?！皬?fù)用模塊化架構(gòu)”——我們算過有多少不同的東西都以“復(fù)用”為賣點(diǎn)？語言當(dāng)然已經(jīng)做到了（OOP、功能語言、過程語言）、庫、框架……有一天我想看到一些大肆宣傳的東西，明確地說“能否重用？我們不關(guān)心?！?/p>

• 它們可以實(shí)現(xiàn)更多輸出?！皵?shù)據(jù)集通常以不同的方式呈現(xiàn)給不同的受眾”——這聽起來很像Crystal Reports[4]的主頁。

• 更容易評(píng)估應(yīng)用程序生命周期中的更新。機(jī)器學(xué)習(xí)和高級(jí)分析環(huán)境需要“根據(jù)新創(chuàng)建的模型評(píng)估現(xiàn)有的計(jì)算模型”……聽起來像是一大堆動(dòng)作詞，但背后幾乎沒有實(shí)質(zhì)內(nèi)容。

• 它們使規(guī)模成為可能。多么有趣——EJB、事務(wù)性中間件處理（類似 Tuxedo）和大型機(jī)也是如此。

• 許多流行的工具都可用。我不認(rèn)為我必須非常努力地指出工具總是可以用于我們行業(yè)的每一次重大炒作——尤其是在炒作扎根一段時(shí)間之后。大多數(shù)讀者的年齡甚至不足以記住CASE 工具[5]，但也許他們會(huì)記住UML。

但眼光敏銳的讀者會(huì)注意到，上面大約一半的觀點(diǎn)有一個(gè)非常共同的主題——?jiǎng)?chuàng)建和維護(hù)小的、獨(dú)立的代碼和數(shù)據(jù)“塊”的想法，彼此版本化，使用共同的輸入和輸出以實(shí)現(xiàn)更大的系統(tǒng)集成。就好像……

在微服務(wù)的核心，我們發(fā)現(xiàn)…… ...

模塊！

是的，低級(jí)的“模塊”，這個(gè)核心概念自 1970 年代以來一直是大多數(shù)編程語言的核心。（甚至更早，盡管使用未將模塊作為一流核心概念的舊語言更難處理。）在 CLR（C#、F#、Visual Basic 等）中稱它們?yōu)椤俺绦蚣保?JVM（Java、Kotlin、Clojure、Scala、Groovy 等）上的“JAR”或“包”，或來自您最喜歡的操作系統(tǒng)的動(dòng)態(tài)鏈接庫（Windows 上的 DLL， *nixes 上so的 s 或as，以及當(dāng)然 macOS 將“框架”隱藏在 /Library 目錄中），但在概念層面上，它們都是模塊。每個(gè)都有不同的內(nèi)部格式，但每個(gè)都有相同的基本目的：一個(gè)獨(dú)立構(gòu)建、管理、版本化、

考慮模塊的這個(gè)工作定義，引用自計(jì)算機(jī)科學(xué)的一篇基礎(chǔ)論文：

“項(xiàng)目工作的明確定義的細(xì)分確保了系統(tǒng)模塊化。每個(gè)任務(wù)形成一個(gè)單獨(dú)的、不同的程序模塊。在實(shí)施時(shí)每個(gè)模塊及其輸入和輸出都是明確定義的，與其他系統(tǒng)的預(yù)期接口沒有混淆模塊。在結(jié)帳時(shí)獨(dú)立測(cè)試模塊的完整性；在結(jié)帳開始之前同步完成多個(gè)任務(wù)幾乎沒有調(diào)度問題。最后，系統(tǒng)以模塊化方式維護(hù)；系統(tǒng)錯(cuò)誤和缺陷可以追溯到特定的系統(tǒng)模塊，從而限制了詳細(xì)錯(cuò)誤搜索的范圍?！?/p>

這來自 David Parnas 的開創(chuàng)性論文“On the Criteria To Be Used in Decomposing Systems into Modules”[6]，該論文寫于 1971 年——距撰寫本文時(shí)已有 50 多年的歷史。

定義明確的“獨(dú)立的、不同的程序模塊”涵蓋了微服務(wù)建議的大約一半好處，我們已經(jīng)這樣做了 50 年。

那么為什么要炒作微服務(wù)呢？

因?yàn)槲⒎?wù)真的與微服務(wù)、服務(wù)甚至分布式系統(tǒng)無關(guān)。

在微服務(wù)的核心，我們應(yīng)該找到…… ... 組織清晰度！

Amazon 是最早公開討論微服務(wù)概念的公司之一，實(shí)際上并沒有像他們?cè)噲D推動(dòng)獨(dú)立開發(fā)團(tuán)隊(duì)的想法那樣努力推動(dòng)架構(gòu)原則，其阻礙者很少。等待 DBA 團(tuán)隊(duì)進(jìn)行架構(gòu)更改？QA 需要構(gòu)建來測(cè)試以便他們可以發(fā)現(xiàn)錯(cuò)誤？還是我們?cè)诘却A(chǔ)架構(gòu)團(tuán)隊(duì)采購服務(wù)器？還是 UX 團(tuán)隊(duì)為演示創(chuàng)建原型？

SCHHHLLLUURRRRRRRPPPPpppp...

你聽到的聲音是開發(fā)團(tuán)隊(duì)聚集了所有可能（并且經(jīng)常會(huì)）阻止他們前進(jìn)的依賴項(xiàng)的所有權(quán)。

• 這意味著這些團(tuán)隊(duì)是普通 IT 團(tuán)隊(duì)各個(gè)部分（分析、開發(fā)、設(shè)計(jì)、測(cè)試、數(shù)據(jù)管理、部署、管理等）的一個(gè)小縮影。
• 這確實(shí)意味著現(xiàn)在團(tuán)隊(duì)要么必須由各種不同的技能集組成，要么我們必須要求每個(gè)團(tuán)隊(duì)成員都具備完整的技能集（所謂的“全棧開發(fā)人員”），這意味著雇用這些人們變得更加狡猾。
• 這也意味著現(xiàn)在團(tuán)隊(duì)要為自己的生產(chǎn)中斷負(fù)責(zé)，這意味著團(tuán)隊(duì)本身現(xiàn)在必須承擔(dān)隨叫隨到的責(zé)任（以及相應(yīng)的工資單和隨之而來的法律影響）。

但是，當(dāng)所有這一切都被駕馭后，這意味著每個(gè)團(tuán)隊(duì)都可以獨(dú)立地建造他們的藝術(shù)品，除了時(shí)間和手指在鍵盤上飛舞的速度的物理學(xué)限制外，沒有其他限制。

在微服務(wù)的核心，我們經(jīng)常發(fā)現(xiàn)...... 分布式計(jì)算的謬誤！

對(duì)于那些不熟悉這些謬論的人來說，這些謬論是Peter Deutsch在80年代給他在Sun公司的同行們的一次演講中首次提出的。他們?cè)?994年由Ann Wolrath和Jim Waldo撰寫的開創(chuàng)性論文 "A Note on Distributed Computing "中再次出現(xiàn)，它們基本上都說了同樣的話。"使分布式系統(tǒng)正確--性能、可靠性、可擴(kuò)展性，無論 "正確 "意味著什么--都是困難的。"(松散的轉(zhuǎn)述)

當(dāng)我們把系統(tǒng)分解成在單個(gè)操作系統(tǒng)節(jié)點(diǎn)上運(yùn)行的內(nèi)存模塊時(shí)，即使在五十年前，跨進(jìn)程或庫邊界傳遞數(shù)據(jù)的成本也是可忽略的。然而，當(dāng)跨越網(wǎng)絡(luò)線路傳遞數(shù)據(jù)時(shí)--就像大多數(shù)微服務(wù)所做的那樣--會(huì)給通信增加五到七個(gè)數(shù)量級(jí)的延遲。這不是我們可以通過在網(wǎng)絡(luò)上添加更多的節(jié)點(diǎn)來 "消除 "的，這實(shí)際上使問題變得更糟。

是的，通過將微服務(wù)托管在同一臺(tái)機(jī)器上，通常是將它們加載到運(yùn)行獨(dú)立微服務(wù)的容器化鏡像的虛擬機(jī)集群中，可以使其中的一些問題變得不那么重要。(如使用Docker Compose或Kubernetes來托管Docker容器的集合）。然而，這樣做會(huì)增加虛擬機(jī)進(jìn)程邊界之間的延遲（因?yàn)槲覀儽仨毎凑掌邔幽Ｐ偷囊?guī)則，在虛擬網(wǎng)絡(luò)堆棧中上下移動(dòng)數(shù)據(jù)，即使其中一些層被完全模擬），并且仍然會(huì)產(chǎn)生在單個(gè)節(jié)點(diǎn)上運(yùn)行的可靠性問題。

更糟糕的是，即使我們開始與分布式計(jì)算的謬誤作斗爭(zhēng)，我們也開始遇到了一個(gè)相關(guān)的、但獨(dú)立的問題集 ：The Fallacies of Enterprise[7]

在微服務(wù)的核心，我們需要......

開始重新思考我們真正需要什么！

你是否需要將問題分解成獨(dú)立的實(shí)體？你可以通過接受托管在Docker容器中的獨(dú)立進(jìn)程來做到這一點(diǎn)，或者你可以通過接受應(yīng)用服務(wù)器中服從標(biāo)準(zhǔn)化API慣例的獨(dú)立模塊來做到這一點(diǎn)，或者其他各種選擇。這不是一個(gè)需要放棄任何已經(jīng)建立的技術(shù)問題--它可以使用過去20年中任何地方的技術(shù)，包括servlets、ASP.NET、Ruby、Python、C++，甚至可能是顫抖的Perl。關(guān)鍵是要建立一個(gè)共同的架構(gòu)背板，并有公認(rèn)的集成和通信慣例，無論你想或需要它是什么。

你是否需要減少你的開發(fā)團(tuán)隊(duì)所面臨的依賴性？那就從研究這些依賴性開始，與合作伙伴一起確定哪些依賴性你可以帶入團(tuán)隊(duì)的輪子里。如果企業(yè)不想正式打破組織結(jié)構(gòu)圖中 "以技能為中心 "的本體（意味著你有一個(gè) "數(shù)據(jù)庫 "小組、一個(gè) "基礎(chǔ)設(shè)施 "小組和一個(gè) "QA "小組作為 "開發(fā) "小組的同行），那么與高級(jí)管理人員合作，至少允許一個(gè) "點(diǎn)線 "報(bào)告結(jié)構(gòu)，這樣每個(gè)小組都有個(gè)人現(xiàn)在被 "矩陣 "在一個(gè)團(tuán)隊(duì)中了。

但是，最重要的是，確保這個(gè)團(tuán)隊(duì)對(duì)他們要建立的東西有一個(gè)清晰的愿景，而且他們可以自信地對(duì)街上隨便走過的陌生人描述他們的服務(wù)/微服務(wù)/模塊的核心。

關(guān)鍵是要給團(tuán)隊(duì)以方向和目標(biāo)，給他們完成目標(biāo)的自主權(quán)，并發(fā)出完成目標(biāo)的號(hào)角。

（banq注：這篇文章忽視了軟件工程中最重要原則：組織架構(gòu)決定了軟件架構(gòu)，當(dāng)然，最后一句話也是關(guān)于組織架構(gòu)的建設(shè)，但是他沒有指出，因?yàn)橛辛藞F(tuán)隊(duì)建設(shè)這些組織架構(gòu)，才催生了微服務(wù)架構(gòu)，這是一套人與技術(shù)組成的有機(jī)生態(tài)系統(tǒng)）

黑客新聞網(wǎng)友：

1、微服務(wù)，雖然經(jīng)常被當(dāng)作解決技術(shù)問題的賣點(diǎn)，但實(shí)際上解決的是組織擴(kuò)展中的人性問題。 微服務(wù)聲稱要解決兩個(gè)技術(shù)問題：模塊化（關(guān)注點(diǎn)的分離、隱藏實(shí)現(xiàn)、文件接口和所有這些好東西）和可擴(kuò)展性（能夠增加計(jì)算量、內(nèi)存和IO到需要它的特定模塊）。

第一個(gè)問題，即模塊，可以在語言層面上得到解決。模塊可以做這個(gè)工作，這就是這篇博文的重點(diǎn)。

第二個(gè)問題，可擴(kuò)展性，在那些被設(shè)計(jì)成在分布式環(huán)境中運(yùn)行的語言之外的大多數(shù)語言中，很難在語言層面上解決。但是大多數(shù)人對(duì)它的需求比他們想象的要少得多。通常情況下，數(shù)據(jù)庫是你的瓶頸，如果你保持你的應(yīng)用服務(wù)器無狀態(tài)，你可以只運(yùn)行大量的數(shù)據(jù)庫；數(shù)據(jù)庫最終會(huì)成為一個(gè)瓶頸，但你可以大量擴(kuò)展數(shù)據(jù)庫。

微服務(wù)可能有意義的真正原因是：它們使人們?cè)谀K邊界周圍保持誠(chéng)實(shí)。它們使人們：

• 更難保留對(duì)持久性內(nèi)存狀態(tài)的訪問，
• 更難駕馭對(duì)象圖來依賴他們不應(yīng)該依賴的東西，
• 更難在沒有關(guān)于設(shè)計(jì)變化和未來證明的對(duì)話的情況下，在模塊邊界的兩邊創(chuàng)建復(fù)雜變化的PR。

（banq注：以上三點(diǎn)保證不讓人們變成全能上帝，因?yàn)槿绻粋€(gè)人變成上帝，他的工作產(chǎn)品就很難被替換，不符合模塊化思想，人就應(yīng)該被困在自己的代碼上下文界限內(nèi)，這就是代碼所有權(quán)，不應(yīng)該凌駕于多個(gè)上下文界限變成上帝）

當(dāng)組織規(guī)模擴(kuò)大時(shí)，團(tuán)隊(duì)的代碼所有權(quán)是你需要的，如果只是為了減少開發(fā)人員需要做的上下文切換，如果被視為完全可替換的話；擁有一個(gè)服務(wù)比擁有一個(gè)模塊更有說服力，因?yàn)閳F(tuán)隊(duì)將擁有發(fā)布時(shí)間表和質(zhì)量門檻。

我不太贊成每個(gè)微服務(wù)都維護(hù)自己的狀態(tài)副本，可能還有自己的獨(dú)立數(shù)據(jù)存儲(chǔ)。我認(rèn)為這通常會(huì)在同步方面增加更多的持續(xù)復(fù)雜性，而不是通過隔離模式來節(jié)省。一個(gè)更好的規(guī)則是一個(gè)服務(wù)擁有一個(gè)表的寫入，而其他服務(wù)只能讀取該表，甚至可能不是所有的列或所有的非自有表。狀態(tài)同步的問題是分布式應(yīng)用中最常見的故障模式之一：隊(duì)列需要備份，重試 "壞 "事件導(dǎo)致阻塞等等。

2、我只想指出，對(duì)于第二個(gè)問題（CPU/內(nèi)存/io的可擴(kuò)展性），微服務(wù)幾乎總是讓事情變得更糟。 做一個(gè)RPC必然意味著數(shù)據(jù)的序列化和反序列化，而且?guī)缀蹩偸且馕吨ㄟ^套接字發(fā)送數(shù)據(jù)。再加上大多數(shù)服務(wù)都有一些運(yùn)行RPC代碼和其他事情（健康檢查、統(tǒng)計(jì)數(shù)據(jù)收集等）的持續(xù)開銷，這些開銷通常被捆綁在每個(gè)服務(wù)中。即使額外的CPU/內(nèi)存對(duì)你來說不是什么大問題，做RPC也會(huì)增加延遲，如果你有太多的微服務(wù)，延遲的數(shù)字會(huì)開始真正增加，而且以后很難修復(fù)。

而在單個(gè)進(jìn)程中運(yùn)行代碼的開銷要低得多，因?yàn)槟悴恍枰D(zhuǎn)接網(wǎng)絡(luò)層，而且你通常只是在傳遞數(shù)據(jù)的指針，而不是序列化/反序列化。

在某些情況下，使用微服務(wù)確實(shí)能使事情的CPU/內(nèi)存效率更高，但這比人們想象的要少得多。一個(gè)真正能提高效率的例子是像地理圍欄服務(wù)（想象一下Uber、Doordash等），地理圍欄的定義可能很大，必須存儲(chǔ)在內(nèi)存中。根據(jù)地理圍欄查詢的頻率，讓少量的地理圍欄服務(wù)實(shí)例在內(nèi)存中加載地理圍欄定義，而不是讓這個(gè)邏輯作為一個(gè)模塊被許多工作者加載，可能更有效率。但同樣，像這樣的情況比服務(wù)導(dǎo)致的大量臃腫要少得多。

我在Uber工作時(shí)，他們開始從單體機(jī)過渡到微服務(wù)，幾乎普遍將邏輯分割到微服務(wù)中，需要配置更多的服務(wù)器，這對(duì)端到端的延遲時(shí)間是災(zāi)難性的。

（banq注：這位Uber工程師沒有理解第二個(gè)問題其實(shí)是代碼所有權(quán)問題，是和團(tuán)隊(duì)組織架構(gòu)有關(guān)，不是關(guān)于技術(shù)問題，技術(shù)是為獲得代碼所有權(quán)好處而付出成本費(fèi)用）

3、我在亞馬遜工作時(shí)，他們開始從單體過渡到微服務(wù)，其中最大的勝利是數(shù)據(jù)和緩存的定位。 所有的目錄數(shù)據(jù)都被轉(zhuǎn)移到一個(gè)只提供目錄數(shù)據(jù)的服務(wù)中，所以它的緩存為目錄數(shù)據(jù)進(jìn)行了優(yōu)化，在它前面的負(fù)載均衡器可以通過一致的散列來優(yōu)化這個(gè)緩存。

這與前端網(wǎng)絡(luò)層不同，前者使用一致的散列法將客戶定位到各個(gè)網(wǎng)絡(luò)服務(wù)器上。

對(duì)于像訂單歷史或客戶數(shù)據(jù)這樣的東西，這些服務(wù)坐在他們各自的數(shù)據(jù)庫前面，提供一致的散列和可用性（在當(dāng)時(shí)使用的SQL數(shù)據(jù)庫前面提供一致的寫通緩存）。

我不會(huì)把這些使事情更有效率的領(lǐng)域稱為罕見，而是實(shí)際上很常見，它來自于讓你的數(shù)據(jù)決定你的微服務(wù)，而不是讓你的組織決定你的微服務(wù)（盡管如果團(tuán)隊(duì)擁有數(shù)據(jù)，那么他們應(yīng)該排隊(duì)）。

（banq注：數(shù)據(jù)架構(gòu)決定微服務(wù)架構(gòu)，很新穎的觀點(diǎn)，其實(shí)數(shù)據(jù)代碼業(yè)務(wù)，類似于DDD界限上下文決定微服務(wù)，界限上下文和組織團(tuán)隊(duì)劃分，這兩個(gè)標(biāo)準(zhǔn)也是相互借用的，有的團(tuán)隊(duì)依據(jù)業(yè)務(wù)領(lǐng)域或上下文劃分，但是對(duì)于不熟悉的業(yè)務(wù)，例如亞馬遜這種創(chuàng)新的電商新領(lǐng)域，人們很難做到戰(zhàn)略上提前計(jì)劃與預(yù)測(cè)，大家都是摸著石頭過河，依據(jù)數(shù)據(jù)劃分可能比較有意義）

4、微服務(wù)效率較低，但可擴(kuò)展性更高。

服務(wù)器只能變得這么大。如果您的單體應(yīng)用需要的資源超過單個(gè)服務(wù)器所能提供的資源，那么您可以將其拆分為微服務(wù)，每個(gè)微服務(wù)都可以獲得自己的強(qiáng)大服務(wù)器。然后你可以在微服務(wù)前面放一個(gè)負(fù)載均衡器，并在 N 個(gè)強(qiáng)大的服務(wù)器上運(yùn)行它。但這只在 Facebook 規(guī)模上很重要。我認(rèn)為大多數(shù)開發(fā)人員會(huì)對(duì)運(yùn)行高效代碼的單個(gè)強(qiáng)大服務(wù)器能做的事情感到震驚。

我不同意，在我看來，微服務(wù)阻礙了部署和開發(fā)的可擴(kuò)展性--至少我看到大多數(shù)企業(yè)使用它們的方式。一般來說，他們會(huì)把代碼分解到不同的存儲(chǔ)庫中，所以現(xiàn)在你必須運(yùn)行70個(gè)不同的CI/CDS管道來部署70個(gè)微服務(wù)，而Repo A不知道Repo B對(duì)他們的API進(jìn)行了破壞性的修改。或者lib B拉入了lib D，現(xiàn)在污染了lib A的類路徑，而lib A對(duì)lib B有依賴性。通常你需要大規(guī)模部署所有的微服務(wù)來解決一個(gè)關(guān)鍵漏洞（想想log4shell）。

解決這個(gè)問題的辦法是使用正確的工具，即像Bazel這樣支持單點(diǎn)的構(gòu)建系統(tǒng)。Bazel很好地解決了這個(gè)問題。它只構(gòu)建/測(cè)試/容器化/部署（rules_k8s, rules_docker）需要重建、重新測(cè)試、重新容器化和重新部署的東西。構(gòu)建速度更快，開發(fā)人員對(duì)一個(gè)組織的所有代碼有上帝一樣的可見性（banq注：這個(gè)觀點(diǎn)就是把人變成上帝，違背代碼所有權(quán)，是很危險(xiǎn)的，導(dǎo)致不小心的耦合依賴），可以輕松地搜索整個(gè)代碼庫，并保證他們的變化不會(huì)破壞其他模塊， 所以你可以用任何最適合它的語言來實(shí)現(xiàn)你的服務(wù)。它允許你更容易地管理橫向依賴關(guān)系，在整個(gè)組織的代碼庫中管理版本。

當(dāng)然，Bazel的學(xué)習(xí)曲線很陡峭，所以它要像Maven、Gradle等那樣被廣泛采用還需要幾年時(shí)間。但在我工作過的銀行里，它可以為他們節(jié)省數(shù)千萬美元。

另外，git也需要趕上大型代碼庫的速度。我認(rèn)為Meta最近發(fā)布了一個(gè)新的源碼控制工具，與git類似，但可以處理大型單體。

5、微服務(wù)解決了第三個(gè)技術(shù)問題，也是我最喜歡的：隔離。

使用單體，您可以向整個(gè)單體提供所有秘密，并且一個(gè)模塊中的漏洞可以訪問任何其他模塊可用的任何秘密。類似地，導(dǎo)致一個(gè)模塊失效的錯(cuò)誤會(huì)導(dǎo)致整個(gè)過程失效（考慮到級(jí)聯(lián)故障時(shí)，可能還會(huì)導(dǎo)致整個(gè)應(yīng)用程序失效）。在大多數(shù)主流語言中，每個(gè)模塊（即使是最不重要的依賴樹上的葉節(jié)點(diǎn)）都需要進(jìn)行搜索以尋找潛在的安全性或可靠性問題，因?yàn)槿魏文K都可能導(dǎo)致整個(gè)事情崩潰。這在大多數(shù)主流語言的語言級(jí)別都沒有解決。Erlang 語言家族通常會(huì)解決可靠性問題，但大多數(shù)語言都將其放在了一起。

微服務(wù)可能有意義的真正原因是它們讓人們?cè)谀K邊界周圍保持誠(chéng)實(shí)。同意。與靜態(tài)類型系統(tǒng)一樣，微服務(wù)是“軌道”。大多數(shù)組織都有以權(quán)宜之計(jì)走捷徑的人，而帶有 軌道 的系統(tǒng)會(huì)抑制這些捷徑（重要的是，它們并不排除它們）。

”

6、模塊化和微服務(wù)都解決了擴(kuò)展問題：

模塊化允許開發(fā)擴(kuò)展。微服務(wù)允許運(yùn)維擴(kuò)展。

7、微服務(wù)的優(yōu)點(diǎn)在于，無論您的技能和資歷水平如何， 它們都會(huì)創(chuàng)建硬邊界。 任何無人監(jiān)督的初級(jí)人員都可能會(huì)消除模塊邊界。但他們不能簡(jiǎn)單地消除在另一個(gè)地方提供服務(wù)的硬邊界。

8、在實(shí)踐中，與微服務(wù)相比，庫和模塊是服務(wù)器端編程較不受歡迎的代碼分割解決方案，這是有充分理由的：

• 部署：當(dāng)所有的東西都以單體形式出現(xiàn)時(shí)，就失去了快速和獨(dú)立部署代碼的能力。
• 隔離：一個(gè)團(tuán)隊(duì)的bug修復(fù)會(huì)影響很多團(tuán)隊(duì)。
• 運(yùn)維復(fù)雜性：在系統(tǒng)上工作的人必須處理許多團(tuán)隊(duì)的模塊在同一服務(wù)中運(yùn)行這一事實(shí)。調(diào)試和排除故障變得更加困難。記錄和遙測(cè)也往往變得更加復(fù)雜。
• 依賴性耦合：每個(gè)人都必須使用完全相同的版本，每個(gè)人都必須同步升級(jí)。你可以用允許依賴性隔離的模塊系統(tǒng)來解決這個(gè)問題，但在我看來，這往往會(huì)導(dǎo)致其自身的復(fù)雜性問題，使之不值得。
• 模塊API的界限：根據(jù)我的經(jīng)驗(yàn)，開發(fā)人員處理服務(wù)API比處理庫API要容易得多。API的表面積比較小，而且你需要處理向后兼容和如何處理的問題也比較明顯。與庫的邊界相比，服務(wù)的邊界 "作弊 "或破壞封裝的機(jī)會(huì)也更少。

9、我已經(jīng)做了很多所謂的微服務(wù)的服務(wù)開發(fā)。 在我看來，這篇文章說得很對(duì):

• 微服務(wù)與組織上的限制有很大關(guān)系。
• 它與服務(wù)的邊界有很大關(guān)系。如果服務(wù)是相互調(diào)用，它們就會(huì)耦合。
• 一個(gè)服務(wù)所做的事情必須被指定，即它接收哪些數(shù)據(jù)和輸出哪些數(shù)據(jù)。這些數(shù)據(jù)可以而且應(yīng)該是事件。
• 服務(wù)應(yīng)該在隊(duì)列、主題、流等方面的消息傳遞的基礎(chǔ)上進(jìn)行依賴和合作。
• 服務(wù)通常是數(shù)據(jù)充實(shí)服務(wù)，其中一個(gè)服務(wù)根據(jù)一個(gè)事件/數(shù)據(jù)充實(shí)一些數(shù)據(jù)。
• 你永遠(yuǎn)不會(huì)同時(shí)測(cè)試一個(gè)以上的服務(wù)。
• 服務(wù)不應(yīng)該共享那些在頻繁更新方面具有活力或短命的代碼。
• 征服和劃分。從開發(fā)一個(gè)小的單體開始，為你所期望的多個(gè)服務(wù)開發(fā)。然后劃分代碼。分開后，每個(gè)服務(wù)都有自己的實(shí)現(xiàn)，而不是在它們之間共享代碼。
• IaaS是很重要的。你應(yīng)該能夠推送部署，并且服務(wù)的設(shè)置與所有基礎(chǔ)設(shè)施的依賴性。
• 領(lǐng)域的界限是很重要的。圍繞著它們的架構(gòu)組織你的團(tuán)隊(duì)，以某種能力為基礎(chǔ)。例如，客戶、預(yù)訂、開票。每個(gè)團(tuán)隊(duì)擁有一個(gè)能力和其基礎(chǔ)服務(wù)。
• 讓其他團(tuán)隊(duì)有可能讀取你的所有數(shù)據(jù)。他們可能需要這些數(shù)據(jù)來解決他們的問題。
• 不要使用kubernetes，除非你不能用云提供商的paas來實(shí)現(xiàn)你的愿望。Kubernetes是一頭野獸，會(huì)讓你經(jīng)受考驗(yàn)。
• 如果你不了解事情是如何溝通、失敗和恢復(fù)的，服務(wù)將無法解決你的問題。
• 一切最終都是一致性的。直面這個(gè)問題的心態(tài)需要時(shí)間。

10、微服務(wù)和模塊化是正交的，并不相同：

模塊化與業(yè)務(wù)概念相關(guān)，微服務(wù)與基礎(chǔ)設(shè)施概念相關(guān)。例如：我可以將模塊 A 部署到微服務(wù) A1 和 A2 中。在這種情況下，A 幾乎是抽象概念。當(dāng)然，我可以使用 1 個(gè)大型服務(wù)（單體）部署所有模塊 A、B、C。此外，我可以為所有模塊共享一個(gè)微服務(wù) X。

微服務(wù)的所有混淆，都是由微服務(wù) = 模塊的誤解造成的。更糟糕的是，我學(xué)到的大多數(shù)“專家建議”實(shí)際上都將領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)與微服務(wù)聯(lián)系起來，他們確實(shí)沒有關(guān)系。微服務(wù)對(duì)我來說就是規(guī)?；簲U(kuò)展基礎(chǔ)設(shè)施。擴(kuò)大團(tuán)隊(duì)規(guī)模（管理理念）。

（banq注：微服務(wù)是一個(gè)不同于模塊的角度，有業(yè)務(wù)角度，參考DDD；有數(shù)據(jù)角度；也有運(yùn)維角度；也有技術(shù)架構(gòu)角度）

審核編輯 ：李倩