沒用過微服務？別慌，丐版架構圖，讓你輕鬆拿捏面試官

來源：哪吒程式設計

大家好，我是哪吒。

很多人都說現在是雲原生、大模型的時代，微服務已經過時了，但現實的是，很多人開發多年，都沒有在實際的開發中用過微服務，更別提搭建微服務框架和技術選型了。

面試的時候都會問，怎麼辦？

今天分享一張微服務的丐版架構圖，讓你可以和麵試官掰扯掰扯~

腦中有圖，口若懸河，一套組合拳下來，面試官只能拍案叫好，大呼快哉，HR更是驚呼，我勒個乖乖，完全聽不懂。

話不多說，直接上圖。

由此可見，Spring Cloud微服務架構是由多個元件一起組成的，各個元件的互動流程如下。

1.  瀏覽器透過查詢DNS伺服器，獲取可用的服務例項的網路位置資訊，從而實現服務的自動發現和動態更新；

2. 透過CDN獲取靜態資源，提高訪問速度，解決跨地域請求速度慢的問題；

3. 透過LVS負載均衡器，實現負載均衡和網路協議；

4. 透過Nginx反向代理伺服器，將請求轉發到gateway做路由轉發和安全驗證；

5. 訪問註冊中心和配置中心Nacos，獲取後端服務和配置項；

6. 透過Sentinel進行限流；

7. 透過Redis進行快取服務、會話管理、分散式鎖控制；

8. 透過Elasticsearch進行全文搜尋，儲存日誌，配合Kibana，對ES中的資料進行實時的視覺化分析。
   

一、域名系統DNS

在微服務中，域名系統DNS的作用主要是進行服務發現和負載均衡。

1. 每個微服務例項在啟動時，將自己的IP地址和埠號等資訊註冊到DNS伺服器，瀏覽器透過查詢DNS伺服器，獲取可用的服務例項的網路位置資訊，從而實現服務的自動發現和動態更新。
2. DNS伺服器可以根據一定的策略，比如輪詢、隨機等，將請求分發到不同的負載均衡器LVS上，提高系統的併發處理能力和容錯性。

二、LVS（Linux Virtual Server）,Linux虛擬伺服器

LVS是一個開源的負載均衡軟體，基於Linux作業系統實現。它在Linux核心中實現負載均衡的功能，透過執行在使用者空間的使用者程式實現負載均衡的策略。

1. LVS支援多種負載均衡演算法，例如輪詢、隨機、加權輪詢、加權隨機等。
2. LVS支援多種網路協議，例如TCP、HTTP、HTTPS，可以滿足不同應用的需求。
3. LVS具有高可用和可擴充套件性。它支援主從備份和冗餘配置，當主伺服器出現故障時，備份伺服器可以自動接管負載，確保服務的連續性。此外，LVS還支援動態新增和刪除伺服器節點，方便管理員進行擴容和縮容的操作。

三、CDN靜態資源

CDN靜態資源圖片、影片、JavaScript檔案、CSS檔案、靜態HTML檔案等。這些靜態資源的特點是讀請求量極大，對訪問速度的要求很高，並佔據了很高的寬頻。如果處理不當，可能導致訪問速度慢，寬頻被佔滿，進而影響動態請求的處理。

CDN的作用是將這些靜態資源分發到多個地理位置的機房的伺服器上。讓使用者就近選擇訪問，提高訪問速度，解決跨地域請求速度慢的問題。

四、Nginx反向代理伺服器

1、Nginx的主要作用體現在以下幾個方面：

1. 反向代理，Nginx可以作為反向代理伺服器，接收來自客戶端的請求，然後將請求轉發到後端的微服務例項。
2. 負載均衡，Nginx可以根據配置，將請求分發到微服務不同的例項上，實現負載均衡。
3. 服務路由，Nginx可以根據不同的路徑規則，將請求路由到不同的微服務上。
4. 靜態資源服務，Nginx可以提供靜態資源服務，如圖片、影片、JavaScript檔案、CSS檔案、HTML靜態檔案等，減輕後端服務的壓力，提高系統的響應速度和效能。

2、Nginx靜態資源服務和CDN靜態資源服務，如何選擇？

在選擇Nginx靜態資源服務和CDN靜態資源服務時，可以根據以下幾個因素進行權衡和選擇：

1. 效能和速度：CDN靜態資源服務通常具有更廣泛的分散式節點和快取機制，可以更快地響應使用者的請求，並減少傳輸距離和網路擁塞。如果靜態資源的載入速度和效能是首要考慮因素，CDN可能是更好的選擇。
2. 控制和自定義能力：Nginx靜態資源服務提供更高的靈活性和控制能力，可以根據具體需求進行定製和配置。如果需要更精細的控制和自定義能力，或者在特定的網路環境下進行部署，Nginx可能更適合。
3. 成本和預算：CDN靜態資源服務通常需要支付額外的費用，而Nginx靜態資源服務可以自行搭建和部署，成本相對較低。在考慮選擇時，需要綜合考慮成本和預算的因素。
4. 內容分發和全球覆蓋：如果靜態資源需要分發到全球各地的使用者，CDN靜態資源服務的分散式節點可以更好地滿足這個需求，提供更廣泛的內容分發和全球覆蓋。

選擇Nginx靜態資源服務還是CDN靜態資源服務取決於具體的需求和場景。如果追求更好的效能和全球覆蓋，可以選擇CDN靜態資源服務；如果更需要控制和自定義能力，且對效能要求不是特別高，可以選擇Nginx靜態資源服務。

五、Gateway閘道器

在微服務架構中，Gateway的作用如下：

1. 統一入口：Gateway作為整個微服務架構的統一入口，所有的請求都會經過Gateway，這樣做可以隱藏內部微服務的細節，降低後臺服務受攻擊的機率；
2. 路由和轉發：Gateway根據請求的路徑、引數等資訊，將請求路由到相應的微服務例項。這樣可以讓服務解耦，讓各個微服務可以獨立的開發、測試、部署；
3. 安全和認證：Gateway通常整合了身份驗證和許可權驗證的功能，確保只有經過驗證的請求才能訪問微服務。Gateway還具備防爬蟲、限流、熔斷的功能；
4. 協議轉換：由於微服務架構中可以使用不同的技術和協議，Gateway可以作為協議轉換中心，實現不同協議之間的轉換和相容性；
5. 日誌和監控，Gateway可以記錄所有的請求和響應日誌，為後續的故障排查、效能分析、安全審計提供資料支援。Gateway還整合了監控和報警功能：實時反饋系統的執行狀態；
6. 服務聚合：在某些場景中，Gateway可以將來自多個微服務的資料進行聚合，然後一次性返回給客戶端，減少客戶端和微服務之間的互動次數，提高系統效能；

六、註冊中心Nacos

在微服務架構中，Nacos的作用主要體現在註冊中心、配置中心、服務健康檢查等方面。

1. 註冊中心：Nacos支援基於DNS和RPC的服務發現，微服務可以將介面服務註冊到Nacos中，客戶端透過nacos查詢和呼叫這些服務例項。
2. 配置中心：Nacos提供了動態配置服務，可以動態的修改配置中心中的配置項，不需要重啟後臺服務，即可完成配置的修改和釋出，提高了系統的靈活性和可維護性。
3. 服務健康檢查：Nacos提供了一系列的服務治理功能，比如服務健康檢查、負載均衡、容錯處理等。服務健康檢查可以阻止向不健康的主機或服務例項傳送請求，保證了服務的穩定性和可靠性。負載均衡可以根據一定的策略，將請求分發到不同的服務例項中，提高系統的併發處理能力和效能。

七、Redis快取

1、在微服務架構中，Redis的作用主要體現在以下幾個方面：

1. 快取服務：Redis可以作為快取記憶體伺服器，將常用的資料儲存在記憶體中，提高資料訪問速度和響應時間，減輕資料庫的訪問壓力，並加速後臺資料的查詢；
2. 會話管理：Redis可以儲存會話資訊，並實現分散式會話管理。這使會話資訊可以在多個服務之間共享和訪問，提供一致的使用者體驗；
3. 分散式鎖：Redis提供了分散式鎖機制，可以確保微服務中多個節點對共享資源的訪問的合理性和有序性，避免競態條件和資源衝突；
4. 訊息佇列：Redis支援釋出訂閱模式和訊息佇列模式，可以作為訊息中介軟體使用。微服務之間可以透過Redis實現非同步通訊，實現解耦和高可用性；

2、競態條件

競態條件是指在同一個程式的多執行緒訪問同一個資源的情況下，如果對資源的訪問順序敏感，就存在競態條件。競態條件可能會導致執行結果出現各種問題，例如計算機當機、出現非法操作提示並結束程式、錯誤的讀取舊的資料或錯誤的寫入新資料。在序列的記憶體和儲存訪問能防止這種情況，當讀寫命令同時發生的時候，預設是先執行讀操作的。

競態條件也可能在網路中出現，當兩個使用者同時試圖訪問同一個可用通道的時候就會發生，系統同意訪問之前沒有計算機能得到通道被佔用的提示。統計上說這種情況通常是發生在有相當長的延遲時間的網路裡，比如使用地球同步衛星。

為了防止這種競態條件發生，需要制定優先順序列表，比如使用者的使用者名稱在字母表裡排列靠前可以得到相對較高的優先順序。駭客可以利用競態條件這一弱點來贏得非法訪問網路的權利。

競態條件是由於多個執行緒或多個程式同時訪問共享資源而引發的問題，它可能會導致不可預測的結果和不一致的狀態。解決競態條件的方法包括使用鎖、同步機制、優先順序列表等。

3、Redis會話管理如何實現？

Redis會話管理的一般實現步驟：

1. 會話建立：當使用者首次訪問應用時，可以在Redis中建立一個新的會話，會話可以是一個具有唯一識別符號的資料結構，例如雜湊表或字串；
2. 會話資訊儲存：將會話資訊關聯到會話ID儲存到Redis中，會話資訊可以包括使用者身份、登入狀態、許可權等。
3. 會話過期時間設定：為會話設定過期時間，以確保會話在一定時間後自動失效。Redis提供了設定鍵值對過期時間的機制，可以透過EXPIRE命令為會話設定過期時間；
4. 會話訪問和更新：在每次使用者訪問應用時，透過會話ID獲取相應的會話資訊，並對其進行驗證和更新。如果會話已過期，可以要求使用者重新登入；
5. 會話銷燬：當使用者主動退出或會話到期後，需要銷燬會話，透過刪除Redis中儲存的會話資訊即可。

八、Elasticsearch全文搜尋引擎

在微服務架構中，Elasticsearch全文搜尋引擎的應用主要體現在如下幾個方面：

1. 全文搜尋引擎：ES是一個分散式的全文搜尋引擎，它可以對海量的資料進行實時的全文搜尋，返回與關鍵詞相關的結果；
2. 分散式儲存：ES提供了分散式的實時檔案儲存功能，每個欄位都可以被索引並可被搜尋，這使得資料在ES中的儲存和查詢都非常高效；
3. 資料分析：配合Kibana，對ES中的資料進行實時的視覺化分析，為資料決策提供資料支援；
4. 日誌和監控：ES可以作為日誌和監控資料的儲存和分析平臺。透過收集系統的日誌資訊，存入ES，可以實現實時的日誌查詢、分析、告警、展示；
5. 擴充套件性：ES具有很好的擴充套件性，可以水平擴充套件到數百臺伺服器，處理PB級別的資料，使得ES能夠應對海量資料的挑戰。

九、感覺Redis和Elasticsearch很像？微服務中Redis和Elasticsearch的區別

1. 資料儲存和查詢方式：Redis是一種基於鍵值對的儲存系統，它提供高效能的讀寫操作，適用於儲存結構簡單、查詢條件同樣簡單的應用場景。而Elasticsearch是一個分散式搜尋和分析引擎，適用於全文搜尋、資料分析等複雜場景，能夠處理更復雜的查詢需求；
2. 資料結構與處理能力：Redis支援豐富的資料結構，如字串、雜湊、列表、集合等，並提供了原子性的操作，適用於實現快取、訊息佇列、計數器等功能。而Elasticsearch則是基於倒排索引的資料結構，提供了強大的搜尋和分析能力。但相對於Redis，Elasticsearch的寫入效率較低；
3. 實時性和一致性：Redis提供了很高的實時性，Redis將資料儲存到記憶體中，能夠很快的進行讀寫操作；而Elasticsearch是一個近實時的搜尋平臺，實時性不如Redis；
4. 擴充套件性：Redis是透過增加Redis例項的形式實現擴充套件，對非常大的資料集可能要進行資料分片；而Elasticsearch具有水平擴充套件的能力，可以透過新增更多的節點來提高系統的處理能力，適用於大量資料的場景；