如果面試官詢問微服務(wù)架構(gòu)設(shè)計，該如何作答？
為什么要做微服務(wù)？
圖片
單體架構(gòu)達(dá)到瓶頸
- 業(yè)務(wù)復(fù)雜度上升，擴(kuò)展困難，維護(hù)費(fèi)力度上升，牽一發(fā)動全身
- 團(tuán)隊規(guī)模擴(kuò)大，開發(fā)沖突增多，開發(fā)效率降低，無法兼容多種編程語言
- 性能受到制約，在服務(wù)可靠性、吞吐能力、服務(wù)部署等方面達(dá)到瓶頸
優(yōu)化架構(gòu)，更新?lián)Q代
- 保證技術(shù)架構(gòu)的鮮活度，不與主流脫軌
- 不斷的調(diào)整技術(shù)建設(shè)，支撐內(nèi)部技術(shù)發(fā)展
- 更好的架構(gòu)體系，更有力的支撐業(yè)務(wù)需求
跟隨潮流，為了微服務(wù)而微服務(wù)
- 為了緊跟潮流，別人搞我們也要搞
- 為了體驗下微服務(wù)架構(gòu)的魅力
- 為了自己實操一把，掌握微服務(wù)技術(shù)
微服務(wù)的出發(fā)點(diǎn)必定是為了解決架構(gòu)層面遇到的問題，微服務(wù)是分而治之的思想。它通過引入更分散的架構(gòu)思想，從而來解決更復(fù)雜的系統(tǒng)問題。所以，微服務(wù)并不是所有系統(tǒng)都適用的。在考慮微服務(wù)架構(gòu)的時候，我們得先評估下是否真的需要？從單體到微服務(wù)是一個復(fù)雜化的過程，如果非必要不微服務(wù)。最近，大有微服務(wù)合并轉(zhuǎn)向單體的趨勢。只有我們的系統(tǒng)在業(yè)務(wù)復(fù)雜度層面、系統(tǒng)性能層面、團(tuán)隊開發(fā)協(xié)作層面等有了確切的需求，那么微服務(wù)確實是不二之選。
微服務(wù)到底是什么？
微服務(wù)（Microservices）是一種軟件開發(fā)架構(gòu)風(fēng)格，它將一個復(fù)雜的應(yīng)用程序構(gòu)建為一系列小型服務(wù)的集合，每個服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，并通常圍繞特定的業(yè)務(wù)能力進(jìn)行構(gòu)建。這些服務(wù)可以通過定義良好的API進(jìn)行通信，通常是HTTP RESTful API或輕量級的消息傳遞系統(tǒng)。
微服務(wù)的核心特點(diǎn)包括：
- 小型化和輕量級：每個服務(wù)都相對較小，只關(guān)注特定的業(yè)務(wù)功能。
- 獨(dú)立部署：各個微服務(wù)可以獨(dú)立部署，不需要依賴其他服務(wù)。
- 獨(dú)立擴(kuò)展：可以根據(jù)需求獨(dú)立擴(kuò)展或收縮特定的服務(wù)。
- 技術(shù)多樣性：團(tuán)隊可以根據(jù)服務(wù)的特定需求選擇最適合的技術(shù)棧，包括編程語言和數(shù)據(jù)存儲等。
- 業(yè)務(wù)中心化：每個服務(wù)都圍繞一項業(yè)務(wù)能力構(gòu)建，易于理解和維護(hù)。
- 敏捷性：微服務(wù)架構(gòu)提高了開發(fā)和部署的速度，使得快速迭代和持續(xù)交付成為可能。
- 容錯性：系統(tǒng)中某個服務(wù)的故障不會導(dǎo)致整個系統(tǒng)的崩潰，提高了系統(tǒng)的穩(wěn)定性。
- 去中心化治理：沒有統(tǒng)一的控制中心，服務(wù)之間的調(diào)用和數(shù)據(jù)流是去中心化的。
- 去中心化數(shù)據(jù)管理：每個服務(wù)可以有自己的數(shù)據(jù)庫，實現(xiàn)數(shù)據(jù)的封裝和隔離。
- 基礎(chǔ)設(shè)施自動化：自動化的部署、擴(kuò)展、監(jiān)控和故障恢復(fù)是微服務(wù)架構(gòu)的關(guān)鍵。
我們到底如何進(jìn)行微服務(wù)拆分？
拆分是沒有完全標(biāo)準(zhǔn)的答案和方式，每家公司或者每個團(tuán)隊拆分的微服務(wù)方式可以說是各不相同。但拆分必然有相同的部分，有一些必然需要參考的準(zhǔn)則和拆分方式。這些就是我們所需要掌握的，包括面試時候所需要回答出來的點(diǎn)。
微服務(wù)拆分原則
- 單一職責(zé)原則：每個服務(wù)應(yīng)該有一個清晰定義的職責(zé)，并且只負(fù)責(zé)一個特定的業(yè)務(wù)功能。
- 業(yè)務(wù)能力對齊：服務(wù)應(yīng)該圍繞業(yè)務(wù)能力構(gòu)建，確保每個服務(wù)都是一個可獨(dú)立部署和擴(kuò)展的業(yè)務(wù)單元。
- 獨(dú)立性：每個服務(wù)應(yīng)該是獨(dú)立的，擁有自己的代碼庫、數(shù)據(jù)庫和部署流程。
- 輕量級通信：服務(wù)之間的通信應(yīng)該是輕量級的，避免使用重量級的通信協(xié)議。
- 數(shù)據(jù)隔離：每個服務(wù)應(yīng)該有自己的數(shù)據(jù)存儲，避免服務(wù)之間的數(shù)據(jù)依賴。
- 去中心化治理：允許每個服務(wù)獨(dú)立選擇技術(shù)棧和框架。
- 容錯性：服務(wù)應(yīng)該能夠容忍其他服務(wù)的故障，通常通過斷路器模式實現(xiàn)。
- 敏捷性：服務(wù)應(yīng)該能夠快速迭代和部署，以適應(yīng)快速變化的業(yè)務(wù)需求。
- 智能端點(diǎn)和啞管道：服務(wù)之間通過簡單的管道通信，而業(yè)務(wù)邏輯應(yīng)該封裝在端點(diǎn)中。
- API 網(wǎng)關(guān)：使用API網(wǎng)關(guān)來提供統(tǒng)一的入口，處理跨服務(wù)的請求路由、負(fù)載均衡和安全控制。
- 持續(xù)集成和持續(xù)部署（CI/CD） ：自動化的構(gòu)建和部署流程對于微服務(wù)架構(gòu)至關(guān)重要。
- 監(jiān)控和日志：實現(xiàn)集中的監(jiān)控和日志管理，以便于跟蹤和診斷跨服務(wù)的問題。
- 團(tuán)隊自治：每個服務(wù)的開發(fā)團(tuán)隊?wèi)?yīng)該有足夠的自治權(quán)，以快速響應(yīng)業(yè)務(wù)需求。
- 服務(wù)發(fā)現(xiàn)：實現(xiàn)服務(wù)發(fā)現(xiàn)機(jī)制，以便服務(wù)實例可以相互發(fā)現(xiàn)并進(jìn)行通信。
- 斷路器模式：使用斷路器模式來防止級聯(lián)故障，并提高系統(tǒng)的穩(wěn)定性。
- 異步消息傳遞：在可能的情況下，使用異步消息傳遞來解耦服務(wù)。
- 版本控制：為服務(wù)和API實現(xiàn)版本控制，以支持向后兼容性。
- 安全性：確保每個服務(wù)都有適當(dāng)?shù)陌踩胧ㄕJ(rèn)證和授權(quán)。
- 文檔和API管理：為API提供詳細(xì)的文檔，并管理API的變更。
- 避免遠(yuǎn)程調(diào)用：盡量避免遠(yuǎn)程服務(wù)調(diào)用，優(yōu)先考慮本地服務(wù)調(diào)用。
- 服務(wù)邊界清晰：服務(wù)之間的邊界應(yīng)該清晰定義，避免功能重疊。
- 避免共享服務(wù)：避免創(chuàng)建共享服務(wù)，因為它們可能導(dǎo)致服務(wù)間的耦合。
- 可替換性：設(shè)計服務(wù)時，應(yīng)考慮到將來可能的替換或升級。
- 環(huán)境一致性：確保開發(fā)、測試和生產(chǎn)環(huán)境盡可能一致，以減少環(huán)境差異導(dǎo)致的問題。
- 配置管理：實現(xiàn)集中的配置管理，以便于跨服務(wù)的配置變更。
- 服務(wù)契約：定義清晰的服務(wù)契約，包括API和數(shù)據(jù)格式。
- 性能和可伸縮性：在設(shè)計服務(wù)時，考慮性能和可伸縮性需求。
- 避免過度拆分：避免過度拆分服務(wù)，導(dǎo)致過多的服務(wù)管理和通信開銷。
微服務(wù)拆分方式
- 按業(yè)務(wù)拆分
這是最常見的拆分方式，根據(jù)業(yè)務(wù)功能的不同將應(yīng)用程序劃分為不同的服務(wù)。每個服務(wù)對應(yīng)一個特定的業(yè)務(wù)領(lǐng)域，例如用戶管理、訂單處理、庫存管理等。
優(yōu)點(diǎn)：
服務(wù)之間界限清晰，易于管理和維護(hù)。
每個服務(wù)可以獨(dú)立部署和擴(kuò)展。
缺點(diǎn)：
需要良好的業(yè)務(wù)領(lǐng)域分析和規(guī)劃。
- 按復(fù)用度拆分
根據(jù)服務(wù)的復(fù)用程度進(jìn)行拆分，將那些在多個地方被使用的通用功能（如認(rèn)證、日志記錄、配置管理）劃分為獨(dú)立的服務(wù)。
優(yōu)點(diǎn)：
提高代碼復(fù)用性。
便于統(tǒng)一管理和更新通用功能。
缺點(diǎn)：
過度拆分可能導(dǎo)致服務(wù)之間的依賴性增加。
- 按冷熱拆分
根據(jù)服務(wù)的使用頻率以及業(yè)務(wù)復(fù)雜度、需求頻率，將高頻率（熱）服務(wù)和低頻率（冷）服務(wù)分開部署。熱服務(wù)可能需要更多的資源和優(yōu)化、以及更頻繁的服務(wù)發(fā)布。
優(yōu)點(diǎn)：
可以根據(jù)服務(wù)的實際使用情況優(yōu)化資源分配。
冷熱分離有助于提高系統(tǒng)整體性能。
有助于保持系統(tǒng)穩(wěn)定性。
缺點(diǎn)：
需要準(zhǔn)確評估服務(wù)的使用頻率。
- 按吞吐量拆分
根據(jù)服務(wù)的吞吐量需求進(jìn)行拆分，將那些需要高吞吐量處理的服務(wù)單獨(dú)拆分出來，以便進(jìn)行專門的優(yōu)化和擴(kuò)展。
優(yōu)點(diǎn)：
可以根據(jù)服務(wù)的性能需求進(jìn)行資源分配和優(yōu)化。
有助于確保關(guān)鍵服務(wù)的性能。
缺點(diǎn)：
需要對服務(wù)的性能特性有深入的了解。
- 按團(tuán)隊架構(gòu)拆分
根據(jù)團(tuán)隊的組織結(jié)構(gòu)和開發(fā)能力進(jìn)行服務(wù)拆分，每個團(tuán)隊負(fù)責(zé)一個或多個服務(wù)的開發(fā)和維護(hù)。
優(yōu)點(diǎn)：
提高團(tuán)隊的責(zé)任感和開發(fā)效率。
便于團(tuán)隊內(nèi)部協(xié)作和知識共享。
缺點(diǎn)：
可能導(dǎo)致團(tuán)隊間的溝通和協(xié)調(diào)成本增加。
微服務(wù)與DDD領(lǐng)域驅(qū)動設(shè)計
微服務(wù)與DDD的關(guān)系
- 業(yè)務(wù)邊界的確定：DDD通過戰(zhàn)略設(shè)計幫助確定業(yè)務(wù)邊界，這些邊界可以直接映射到微服務(wù)的劃分上。每個限界上下文（Bounded Context）通常對應(yīng)一個微服務(wù)。
- 高內(nèi)聚低耦合：DDD提倡高內(nèi)聚的領(lǐng)域模型，這與微服務(wù)追求的高內(nèi)聚、低耦合的服務(wù)設(shè)計原則相吻合。
- 持續(xù)演進(jìn)：DDD鼓勵通過不斷的迭代來演進(jìn)領(lǐng)域模型，這與微服務(wù)架構(gòu)中服務(wù)的持續(xù)集成和持續(xù)部署（CI/CD）的理念相符。
- 技術(shù)與業(yè)務(wù)的對齊：DDD通過統(tǒng)一語言（Ubiquitous Language）促進(jìn)業(yè)務(wù)專家與開發(fā)人員之間的溝通，而微服務(wù)架構(gòu)則通過服務(wù)的獨(dú)立性支持快速響應(yīng)業(yè)務(wù)變化。
- 獨(dú)立部署和擴(kuò)展：DDD中的每個限界上下文都可以獨(dú)立部署和擴(kuò)展，這與微服務(wù)的獨(dú)立部署和擴(kuò)展原則一致。
- 領(lǐng)域事件：DDD中的領(lǐng)域事件可以用來觸發(fā)微服務(wù)間的通信，實現(xiàn)服務(wù)間的松耦合。
- 抗腐層：在微服務(wù)架構(gòu)中，DDD的反腐層概念可以幫助維護(hù)服務(wù)間的清晰界限，確保服務(wù)的獨(dú)立性和穩(wěn)定性。
在實踐中，DDD可以幫助團(tuán)隊更好地理解和建模業(yè)務(wù)領(lǐng)域，而微服務(wù)架構(gòu)提供了實現(xiàn)這些模型的技術(shù)手段。通過DDD的領(lǐng)域模型，可以更容易地識別出微服務(wù)的職責(zé)和邊界，從而設(shè)計出更靈活、可維護(hù)和可擴(kuò)展的系統(tǒng)。
圖片
說白了，DDD誕生了20多年了，之前一直不溫不火是因為DDD很難落地。但隨著微服務(wù)的出現(xiàn)，DDD思想與微服務(wù)非常契合，2者相輔相成，DDD成為了微服務(wù)拆分的指導(dǎo)思想，而微服務(wù)有著完善的落地技術(shù)方案。DDD通過聚焦業(yè)務(wù)模型，強(qiáng)調(diào)明確清晰的業(yè)務(wù)邊界，劃分出多個限界下上文，通過定義具體的實體、值對象、聚合根把業(yè)務(wù)模型分的明明白白，這不就是微服務(wù)劃分業(yè)務(wù)服務(wù)最好的軍師嗎？
微服務(wù)與其他架構(gòu)模式的區(qū)別
微服務(wù)架構(gòu)與傳統(tǒng)的單體架構(gòu)、分布式架構(gòu)和Serverless架構(gòu)有顯著的不同。以下是微服務(wù)架構(gòu)與其他架構(gòu)的區(qū)別：
微服務(wù)架構(gòu) vs 單體架構(gòu)
單體架構(gòu)：
- 應(yīng)用程序的所有功能模塊都打包在一起，作為一個單一的單元運(yùn)行。
- 通常難以維護(hù)和更新，因為任何更改都需要重新部署整個應(yīng)用。
- 技術(shù)棧統(tǒng)一，整個應(yīng)用通常使用相同的編程語言和技術(shù)。
微服務(wù)架構(gòu)：
- 應(yīng)用程序被分解為一系列小型服務(wù)，每個服務(wù)運(yùn)行在自己的進(jìn)程中，并通常圍繞特定的業(yè)務(wù)功能構(gòu)建。
- 易于開發(fā)和維護(hù)，因為每個服務(wù)都是獨(dú)立的，可以單獨(dú)部署、升級和擴(kuò)展。
- 技術(shù)多樣性，不同的服務(wù)可以使用不同的編程語言和技術(shù)棧。
微服務(wù)架構(gòu) vs 分布式架構(gòu)
分布式架構(gòu)：
- 應(yīng)用程序被拆分成多個模塊，這些模塊運(yùn)行在不同的服務(wù)器上，并通過網(wǎng)絡(luò)通信。是一個更廣泛的概念，已經(jīng)存在了很長時間，涉及多個計算機(jī)或節(jié)點(diǎn)協(xié)同工作完成復(fù)雜任務(wù)。
- 指的是系統(tǒng)的組件分布在不同的物理位置，但作為一個整體協(xié)同工作。分布式系統(tǒng)不一定涉及服務(wù)的拆分，它更側(cè)重于組件之間的通信和協(xié)作。
微服務(wù)架構(gòu)：
- 雖然微服務(wù)架構(gòu)也是分布式的，但它更側(cè)重于服務(wù)的獨(dú)立性、靈活性和敏捷性。
- 微服務(wù)架構(gòu)是分布式系統(tǒng)架構(gòu)的一種特殊形式，它專注于更細(xì)粒度的服務(wù)拆分和獨(dú)立部署
微服務(wù)架構(gòu) vs Serverless架構(gòu)
Serverless架構(gòu)：
- 在Serverless架構(gòu)中，開發(fā)者不需要管理服務(wù)器，而是將代碼部署到云平臺上，由云平臺負(fù)責(zé)運(yùn)行和擴(kuò)展。
- 通常以函數(shù)為單位，按需運(yùn)行，按實際使用量計費(fèi)。
微服務(wù)架構(gòu)：
- 微服務(wù)通常長期運(yùn)行，提供持續(xù)的服務(wù)，而Serverless架構(gòu)中的函數(shù)是事件驅(qū)動和短暫運(yùn)行的。
- 微服務(wù)架構(gòu)可能需要更多的運(yùn)維工作，因為每個服務(wù)都需要獨(dú)立管理和部署。
微服務(wù)架構(gòu) vs Soa架構(gòu)
微服務(wù)架構(gòu)和SOA（面向服務(wù)的架構(gòu)）都是設(shè)計軟件系統(tǒng)的方法，它們在多個方面有相似之處，但也存在一些關(guān)鍵的區(qū)別：
服務(wù)粒度：
- 微服務(wù)：通常具有更細(xì)的粒度，每個服務(wù)都非常專注，以至于可能只有一個單一的職責(zé)或功能23。
- SOA：服務(wù)粒度較粗，可以包含多個功能，服務(wù)組件的大小可以從小型應(yīng)用程序服務(wù)到非常大型的企業(yè)服務(wù)23。
通信方式：
- 微服務(wù)：傾向于使用輕量級的通信機(jī)制，如HTTP RESTful API或輕量級的消息傳遞系統(tǒng)12。
- SOA：可能使用更復(fù)雜的協(xié)議，如WebService BPEL（業(yè)務(wù)流程執(zhí)行語言），并且常通過ESB（企業(yè)服務(wù)總線）進(jìn)行服務(wù)間的通信和集成12。
架構(gòu)劃分方式：
- 微服務(wù)：強(qiáng)調(diào)按垂直架構(gòu)劃分，按照業(yè)務(wù)能力將系統(tǒng)拆分成獨(dú)立的服務(wù)，每個服務(wù)完成一種特定的功能，服務(wù)即產(chǎn)品3。
- SOA：更注重按水平架構(gòu)劃分，將系統(tǒng)劃分為前端、后端、數(shù)據(jù)庫和測試等不同的層次
微服務(wù)架構(gòu) vs Service Mesh
微服務(wù)和Service Mesh是云原生架構(gòu)中的兩個重要概念，它們在軟件架構(gòu)和部署上有不同的關(guān)注點(diǎn)和作用：
微服務(wù)（Microservices）：
- 微服務(wù)是一種架構(gòu)風(fēng)格，它將一個大型復(fù)雜軟件應(yīng)用分解為一組小型、獨(dú)立的服務(wù)，每個服務(wù)運(yùn)行在自己的進(jìn)程中，并通常圍繞特定的業(yè)務(wù)功能構(gòu)建。
- 微服務(wù)之間通過定義良好的API進(jìn)行通信，通常是HTTP RESTful API或輕量級的消息傳遞系統(tǒng)。
- 微服務(wù)架構(gòu)的優(yōu)點(diǎn)包括降低系統(tǒng)復(fù)雜度、松耦合、跨語言開發(fā)、獨(dú)立部署等。
Service Mesh（服務(wù)網(wǎng)格）：
- Service Mesh是微服務(wù)架構(gòu)中的一個基礎(chǔ)設(shè)施層，專門用于處理服務(wù)間的通信。它通過使用“sidecar”代理模式，使得服務(wù)通信的細(xì)節(jié)（如發(fā)現(xiàn)、負(fù)載均衡、故障恢復(fù)、度量和監(jiān)控、安全性等）對應(yīng)用層透明。
- Service Mesh的典型實現(xiàn)包括Istio、Linkerd、Consul等，它們通常以輕量級代理的形式與應(yīng)用服務(wù)一起部署，而不需要應(yīng)用代碼的更改。
- Service Mesh解決了微服務(wù)架構(gòu)中的一些挑戰(zhàn)，如服務(wù)發(fā)現(xiàn)、配置管理、流量控制和故障處理等。
主要區(qū)別：
- 關(guān)注點(diǎn)：微服務(wù)關(guān)注的是將應(yīng)用拆分成獨(dú)立部署的小型服務(wù)，而Service Mesh關(guān)注的是這些服務(wù)間的通信和治理。
- 實現(xiàn)：微服務(wù)可以通過各種技術(shù)棧實現(xiàn)，而Service Mesh通常需要特定的基礎(chǔ)設(shè)施支持，如Istio或Linkerd。
- 透明性：Service Mesh通過代理抽象了服務(wù)通信的復(fù)雜性，對應(yīng)用層是透明的，而微服務(wù)架構(gòu)中，服務(wù)通信的實現(xiàn)細(xì)節(jié)通常需要開發(fā)者自行處理。
- 治理：Service Mesh提供了一套完整的服務(wù)治理功能，如流量控制、安全認(rèn)證、監(jiān)控等，這些在微服務(wù)架構(gòu)中可能需要額外的工作來實現(xiàn)。
微服務(wù)架構(gòu)是一種將應(yīng)用分解為獨(dú)立服務(wù)的方法，而Service Mesh是支持微服務(wù)的通信和治理的基礎(chǔ)設(shè)施層。Service Mesh可以視為微服務(wù)架構(gòu)的進(jìn)化，它解決了微服務(wù)架構(gòu)中的一些復(fù)雜問題，使得開發(fā)者可以更專注于業(yè)務(wù)邏輯的實現(xiàn)。微服務(wù)架構(gòu)適合于需要高擴(kuò)展性和靈活性的復(fù)雜應(yīng)用，而Serverless架構(gòu)適合于無狀態(tài)的、事件驅(qū)動的應(yīng)用場景。選擇哪種架構(gòu)取決于項目的具體需求、團(tuán)隊的技術(shù)能力以及期望的運(yùn)維復(fù)雜度。
微服務(wù)中的常見技術(shù)實現(xiàn)方案
服務(wù)間通信：
- RESTful API：使用HTTP協(xié)議和JSON或XML格式進(jìn)行服務(wù)間通信。
- gRPC：一個高性能的RPC框架，使用Protocol Buffers作為接口定義語言。
- Apache Thrift：Facebook開發(fā)的一套RPC通信框架，支持多種語言。
- Apache Avro：Apache的一個項目，提供了RPC和數(shù)據(jù)序列化的功能。
- Apache Dubbo：Alibaba開源的高性能Java RPC框架。
消息隊列：
- Kafka：一個分布式流處理平臺，廣泛用于構(gòu)建實時數(shù)據(jù)管道和流式應(yīng)用。
- RabbitMQ：一個開源的消息代理，也稱為消息隊列。
- Amazon SQS：Amazon提供的一個完全托管的消息隊列服務(wù)。
- Google Pub/Sub：Google Cloud提供的事件驅(qū)動的異步服務(wù)到服務(wù)通信。
- Apache Pulsar：一個云原生分布式消息流平臺。
服務(wù)注冊與發(fā)現(xiàn)：
- Eureka：Netflix開源的服務(wù)注冊與發(fā)現(xiàn)組件。
- Consul：提供服務(wù)發(fā)現(xiàn)和配置共享。
- Apache Zookeeper：一個分布式協(xié)調(diào)服務(wù)，可用于服務(wù)注冊與發(fā)現(xiàn)。
- etcd：一個分布式鍵值存儲，用于配置共享和服務(wù)發(fā)現(xiàn)。
- Nacos：Alibaba開源的更易于構(gòu)建云原生應(yīng)用的動態(tài)服務(wù)發(fā)現(xiàn)、配置管理和服務(wù)管理平臺。
配置管理：
- Spring Cloud Config：Spring Cloud的配置管理工具。
- Consul K/V：Consul的鍵值存儲，可用于存儲配置信息。
- Apache ZooKeeper：可以用作分布式配置存儲。
- etcd：除了服務(wù)發(fā)現(xiàn)，也常用于配置管理。
- Config Server：Spring Cloud Netflix的配置中心組件。
API網(wǎng)關(guān)：
- Zuul：Netflix開源的API網(wǎng)關(guān)服務(wù)。
- Kong：一個云原生API網(wǎng)關(guān)，提供API管理、開發(fā)平臺和DevOps解決方案。
- Amazon API Gateway：AWS提供的一個完全托管的服務(wù)，用于創(chuàng)建、發(fā)布、維護(hù)、監(jiān)控和保護(hù)API。
- Nginx：一個高性能的HTTP服務(wù)器和反向代理，也可以作為API網(wǎng)關(guān)使用。
- Traefik：一個開源的邊緣路由器，支持API網(wǎng)關(guān)功能。
認(rèn)證鑒權(quán)：
- OAuth 2.0：一個行業(yè)標(biāo)準(zhǔn)的協(xié)議，用于授權(quán)。
- OpenID Connect：基于OAuth 2.0的認(rèn)證層。
- Apache Shiro：一個強(qiáng)大且易于使用的Java安全框架。
- Spring Security：為Java應(yīng)用程序提供認(rèn)證和訪問控制。
- JWT (JSON Web Tokens)：用于在雙方之間安全地傳輸信息。
日志監(jiān)控：
- ELK Stack（Elasticsearch, Logstash, Kibana）：用于集中日志收集和可視化。
- Prometheus：開源監(jiān)控和警報工具。
- Grafana：一個跨平臺的開源分析和監(jiān)控解決方案。
- Fluentd：一個開源的數(shù)據(jù)收集器，用于統(tǒng)一日志數(shù)據(jù)收集和消費(fèi)。
- Graylog：提供數(shù)據(jù)收集、索引和實時搜索的日志管理平臺。
持續(xù)集成與部署：
- Jenkins：一個開源的持續(xù)集成工具。
- GitLab CI/CD：GitLab內(nèi)置的持續(xù)集成和持續(xù)部署工具。
- CircleCI：提供自動化的持續(xù)集成和持續(xù)部署服務(wù)。
- Travis CI：一個持續(xù)集成服務(wù)，支持GitHub。
- Spinnaker：一個開源的、多功能的持續(xù)交付平臺。
斷路器：
- Hystrix：Netflix開源的斷路器庫，用于容錯。
- Resilience4j：輕量級的容錯庫，靈感來自Hystrix。
- Sentinel：Alibaba開源的輕量級流量控制、熔斷和系統(tǒng)保護(hù)開源庫。
- Spring Retry：Spring提供的一個簡單的自動重試機(jī)制。
- Polly：一個提供斷路器功能的庫，支持多種語言。
分布式追蹤：
- Zipkin：一個分布式追蹤系統(tǒng)。
- Jaeger：由Uber開發(fā)的分布式追蹤系統(tǒng)。
- SkyWalking：一個開源的APM系統(tǒng)，用于分布式系統(tǒng)的追蹤、監(jiān)控和診斷。
- OpenTelemetry：一個用于觀測分布式系統(tǒng)的工具，提供追蹤、度量和日志。
- AWS X-Ray：AWS提供的一個服務(wù)，用于分析和調(diào)試分布式Web應(yīng)用程序。
容器化和編排：
- Docker：用于開發(fā)、發(fā)布和運(yùn)行應(yīng)用程序的容器化平臺。
- Kubernetes：一個開源平臺，用于自動部署、擴(kuò)展和管理容器化應(yīng)用程序。
- Apache Mesos：一個集群管理器，提供有效的資源隔離和共享。
- Amazon ECS：AWS提供的容器管理服務(wù)。
- Nomad：HashiCorp開發(fā)的一個容器編排工具，用于管理容器化和非容器化應(yīng)用程序的部署。
總結(jié)
- 微服務(wù)架構(gòu)現(xiàn)在依舊是架構(gòu)設(shè)計的主流，微服務(wù)分而治之的思想永不過時。
- 架構(gòu)是從簡單到復(fù)雜的一個過程，架構(gòu)設(shè)計是為了把復(fù)雜變得盡量簡單，所以能用單體就單體，不要盲目微服務(wù)，隨之帶來的可能不是微服務(wù)的好處，而是成本。
- DDD是微服務(wù)拆分的指導(dǎo)思想，它以業(yè)務(wù)為王，只關(guān)心于業(yè)務(wù)模型本身。
- 微服務(wù)拆分按業(yè)務(wù)是基礎(chǔ)，在業(yè)務(wù)之上還可以按照業(yè)務(wù)復(fù)雜度、變動頻率、吞吐量、以及團(tuán)隊情況等進(jìn)行多維度的拆分。服務(wù)的人員分配可參考3個火槍手原則。
- 好的架構(gòu)一定是邊界清晰、職責(zé)明確、規(guī)范統(tǒng)一、修少擴(kuò)多（原先代碼需要修改的少、擴(kuò)展新增的多）、鏈路明朗、適配靈活、伸縮自如、高內(nèi)聚低耦合。
圖片
