深入淺出帶你了解微服務架構如何運作?
1．您對微服務有何了解?
微服務，又稱微服務架構，是一種架構風格，它將應用程序構建為以業務領域為模型的小型自治服務集合。一文詳解微服務架構通俗地說，你必須看到蜜蜂如何通過對齊六角形蠟細胞來構建它們的蜂窩狀物。他們最初從使用各種材料的小部分開始，并繼續從中構建一個大型蜂箱。這些細胞形成圖案，產生堅固的結構，將蜂窩的特定部分固定在一起。這里，每個細胞獨立于另一個細胞，但它也與其他細胞相關。這意味著對一個細胞的損害不會損害其他細胞，因此，蜜蜂可以在不影響完整蜂箱的情況下重建這些細胞。
圖 1:微服務的蜂窩表示 – 微服務訪談問題
請參考上圖。這里，每個六邊形形狀代表單獨的服務組件。與蜜蜂的工作類似，每個敏捷團隊都使用可用的框架和所選的技術堆棧構建單獨的服務組件。就像在蜂箱中一樣，每個服務組件形成一個強大的微服務架構，以提供更好的可擴展性。此外，敏捷團隊可以單獨處理每個服務組件的問題，而對整個應用程序沒有影響或影響最小。
2．說說微服務架構的優勢
優勢 | 說明 |
獨立開發 | 所有微服務都可以根據各自的功能輕松開發 |
獨立部署 | 根據他們所提供的服務，可以在任何應用中單獨部署 |
故障隔離 | 即使應用中的一個服務不起作用，系統仍然繼續運行 |
混合技術棧 | 可以用不同的語言和技術來構建同一應用程序的不同服務 |
粒度縮放 | 各個組件可根據需要進行擴展，無需將所有組件融合到一起 |
3．微服務有哪些特點?
- 解耦—系統內的服務很大程度上是分離的。因此，整個應用程序可以輕松 構建，更改和擴展
- 組件化—微服務被視為可以輕松更換和升級的獨立組件
- 業務能力—微服務非常簡單，專注于單一功能
- 自治—開發人員和團隊可以彼此獨立工作，從而提高速度
- 持續交付—通過軟件創建，測試和批準的系統自動化，允許頻繁發布軟件
- 責任—微服務不關注應用程序作為項目。相反，他們將應用程序視為他們
- 負責的產品
- 分散治理—重點是使用正確的工具來做正確的工作。這意味著沒有標準化模式或任何技術模式。開發人員可以自由選擇最有用的工具來解決他們的問題
- 敏捷—微服務支持敏捷開發。任何新功能都可以快速開發并再次丟棄
4．設計微服務的最佳實踐是什么?
以下是設計微服務的最佳實踐:
圖 6:設計微服務的最佳實踐 – 微服務訪談問題
5．微服務架構如何運作?
微服務架構具有以下組件:
- 客戶端 – 來自不同設備的不同用戶發送請求。
- 身份提供商 – 驗證用戶或客戶身份并頒發安全令牌。
- API 網關 – 處理客戶端請求。
- 靜態內容 – 容納系統的所有內容。
- 管理 – 在節點上平衡服務并識別故障。
- 服務發現 – 查找微服務之間通信路徑的指南。
- 內容交付網絡 – 代理服務器及其數據中心的分布式網絡。
- 遠程服務 – 啟用駐留在 IT 設備網絡上的遠程訪問信息。
6．微服務架構的優缺點是什么?
微服務架構的優點 | 微服務架構的缺點 |
自由使用不同的技術 | 增加故障排除挑戰 |
每個微服務都側重于單一功能 | 由于遠程呼叫而增加延遲 |
支持單個可部署單元 | 增加了配置和其他操作的工作量 |
允許經常發布軟件 | 難以保持交易安全 |
確保每項服務的安全性 | 艱難地跨越各種便捷跟蹤數據 |
多個服務是并行開發和部署的 | 難以在服務之間進行編碼 |
7．單片，SOA 和微服務架構有什么區別?
- 單片架構類似于大容器，其中應用程序的所有軟件組件組裝在一起并緊密封裝。
- 一個面向服務的架構是一種相互通信服務的集合。通信可以涉及簡單的數據傳遞，也可以涉及兩個或多個協調某些活動的服務。
- 微服務架構是一種架構風格，它將應用程序構建為以業務域為模型的小型 自治服務集合。
8．在使用微服務架構時，您面臨哪些挑戰?
開發一些較小的微服務聽起來很容易，但開發它們時經常遇到的挑戰如下。
- 自動化組件:難以自動化，因為有許多較小的組件。因此，對于每個組件，我們必須遵循 Build，Deploy 和 Monitor 的各個階段。
- 易感性:將大量組件維護在一起變得難以部署，維護，監控和識別問題。
- 它需要在所有組件周圍具有很好的感知能力。
- 配置管理:有時在各種環境中維護組件的配置變得困難。
- 調試:很難找到錯誤的每一項服務。維護集中式日志記錄和儀表板以調試問題至關重要。
9．SOA 和微服務架構之間的主要區別是什么?
SOA | 微服務 |
遵循“盡可能多的共享”架構方法 | 遵循“盡可能少分享”架構方法 |
重要性在于“業務功能”重用 | 重要性在于“有界背景”的概念 |
它們有共同的治理和標準 | 它們專注于人們的合作和其他選擇的自由 |
使用企業服務總線(ESB)進行通信 | 簡單的消息系統 |
它們支持多種消息協議 | 它們使用輕量級協議，如 HTTP/REST 等 |
多線程，有跟多的開銷來處理 I/O | 單線程，通常使用 Event Loop 功能進行非 鎖定 I/O 處理 |
最大化應用程序服務可重用性 | 專注于解耦 |
傳統的關系數據庫更常用 | 現代關系數據庫更常用 |
系統的變化需要修改整體 | 系統的變化是創造一種新的服務 |
DevOps/Continuous Delivery 正在變得流 行，但還不是主流 | 專注于 DevOps/持續交付 |
10．微服務有什么特點?
您可以列出微服務的特征，如下所示:
圖 7:微服務的特征 – 微服務訪談問題
11．什么是領域驅動設計?
圖 8: DDD 原理 – 微服務面試問題
12．為什么需要域驅動設計(DDD)?
圖 9:我們需要 DDD 的因素 – 微服務面試問題
13．什么是無所不在的語言?
如果您必須定義泛在語言(UL)，那么它是特定域的開發人員和用戶使用的通 用語言，通過該語言可以輕松解釋域。無處不在的語言必須非常清晰，以便它將所有團隊成員放在同一頁面上，并以 機器可以理解的方式進行翻譯。
14．什么是凝聚力?
模塊內部元素所屬的程度被認為是凝聚力。
15．什么是耦合?
組件之間依賴關系強度的度量被認為是耦合。一個好的設計總是被認為具有高內聚力和低耦合性。
16．什么是 REST / RESTful 以及它的用途是什么?
Representational State Transfer(REST)/ RESTful Web服務是一種幫助計 算機系統通過 Internet 進行通信的架構風格。這使得微服務更容易理解和實 現。
微服務可以使用或不使用 RESTful API 實現，但使用 RESTful API 構建松散 耦合的微服務總是更容易。
17．什么是不同類型的微服務測試?
在使用微服務時，由于有多個微服務協同工作，測試變得非常復雜。因此，測試分為不同的級別。
在底層，我們有面向技術的測試，如單元測試和性能測試。這些是完全自 動化的。
在中間層面，我們進行了諸如壓力測試和可用性測試之類的探索性測試。
在頂層， 我們的驗收測試數量很少。這些驗收測試有助于利益相關者理解和驗證軟件功能。
