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