微服務學習核心關鍵點

在這裏插入圖片描述

1.微服務的服務治理

當我們架構微服務應用時首先遇到的一個問題是,作爲消費者如何訪問並調用服務提供者所提供
的服務,作爲服務提供者如何能讓服務消費者知道並進行消費。在傳統應用開發時,通常是在開
發語言層面上解決這個問題,可能我們從來也沒有考慮過這個問題,甚至可以說這個問題在傳統
開發時根本不存在。但在微服務架構下,同-一個微服務可能同時存在多個實例,並且這些微服務
實例還在不停上線、下線, 那麼它們如何相知、相識並進行通信呢?使用物理地址顯然不行,因
爲不知道服務提供者到底在哪臺服務器,服務當前是否仍然在線,如果服務不在線還進行調用豈
不是造成調用失敗?
此外,對於微服務架構應用來說還有一個重要考量因素:快速水平擴展。在進行快速擴展時我們
不可能預先知道所有的服務實例地址並告知服務消費者,而且也無法確定有哪些、有多少消費者
會來消費。
業界對於此問題典型的解決方案就是服務治理(服務註冊及服務發現)。通過服務發現,消費者
可以在預先不知道服務提供者物理地址的情況下,僅通過相應的服務名稱就可以實現服務調用。
服務註冊機制,可以讓服務提供者在上線時將所提供的服務信息註冊到服務治理服務器中,供服
務消費者使用。當服務下線時將自己從服務治理服務器中註銷,避免服務消費者調用而造成的異
常。

2.微服務的負載均衡

對於負載均衡,傳統應用通常會在用戶請求的入]通過負載均衡設備(如F5等) 或通過Ngnix反
向代理方式實現負載均衡。但在微服務架構下負載均衡不僅僅指的是用戶請求入口,還包含了微
服務之間的調用。如果此時再採用之前傳統的解決方案,顯然是不合適的: -是傳統的負載均衡
設備配置非常複雜;二是微服務應用實例在快速變化。因此,針對微服務之間的負載均衡需要另,
謀出路。因此業界提出了客戶端負載均衡的概念,也稱之爲軟負載均衡。核心思想就是在服務消
費者(也就是客戶端)保存有一份服務者列表,這份服務者列表通常是從服務治理服務器中動態
獲取,也可以採用固定配置方式,然後通過某種負載均衡策略來決定每次服務調用時所使用的具
體服務實例,從而實現微服務之間的負載均衡。

3.微服務的統一入口

微服務是衆多的,而且大部分都會對外提供某種服務接口。對於前端或者第三方開發者來說,一
定不願意與多個服務地址打交道。那麼如何將這麼多微服務入口統一到- 一個入口進行管理呢?可
能首先映入你腦海的就是門戶模式,通過門戶模式可以有效地隱藏後端的複雜性,對客戶提供統
一訪問入口。對於微服務也是,API服務網關就是爲微服務提供了一個統一入口, 並能夠附加一
些路由規則,使得不同的微服務通過路由規則提供-致的訪問入口。

4.微服務的容錯

微服務架構的應用是一種高度分佈式架構應用,各微服務之間的調用更是通過網絡來完成,而且
-個用戶的請求往往需要涉及多個微服務。我們知道網絡訪問是不可靠的,那麼如何在一個微服
務不可用時不會影響其他微服務及調用者,以及如何有效防止服務調用失敗而引起的“雪 崩效
應”呢?如何在一個服務不可用時能夠對用戶更加友好,使整個應用非常具有彈性呢?這些是實
施微服務架構時一個非常重要的話題。
在業界,針對微服務架構的容錯提出了斷路器、服務降級等模式,這些模式都可以有效防止微服
務調用失敗而引起的連鎖反應,並且在必要時可以通過這些模式主動實施應用的降級處理,從而
保證核心業務的正常運行。

5.微服務的統一一配置

單體應用中可以直接在所開發項目中進行配置管理。而在微服務架構中,- -個應用被拆成衆多的
微服務,並由不同的團隊負責,而這些微服務中會存在- -些共同的配置數據,如果還是分散在各
個項目中分別進行管理,那麼面對數十個、.上百個應用實例, 可以預見變更一個配置數據時的難
度。此外,我們也不希望某個應用實例可以獨立進行變更,從而造成更大的混亂。因此,如何統
一對配置進行管理和發佈更新,就需要在構建微服務之初進行思考。

6.微服務的監控

微服務的靈活和強大也爲開發者帶來了“噩夢” 一般的調試和跟蹤分析體驗。單體架構下所有的
應用都在一起,根本不存在難以調試的問題。對於調用和跟蹤分析的重要性不言而喻,特別是當
應用正式.上線時,通過日誌分析可以快速定位到問題所在。而在微服務場景下調試將難以進行,
因爲一個用戶請求會涉及多個微服務應用,要在多個應用下統- -進行調試將會非常困難。應用上
線後,日誌多由服務實例自己管理,如何將分散在多個日誌之間的調用串聯起來,形成-個完整
的請求調用鏈,將是另外一個非常大的挑戰。因此,針對這個問題及需求,業界在微服務監控中
提供了日誌聚合、日誌可視化分析、調用鏈跟蹤等解決方案,都可爲我們所構建的微服務應用的
運維提供強有力的武器。

7.微服務的部署

在動輒幾十個甚至上百個服務實例在線,並且不斷上線、下線的場景下, 開發者- -定不願意通過
手工構建和部署這些服務實例。此時,開發者更願意將這些處理交付給自動化工具去做,一方面
可以提升工作效率,另- -方面通過自動化的方式才能夠保障所構建和部署的服務實例一致化。因
此,業界針對這種需求提出了相應的解決方案,包括通過構建一發布管道來構建自動化發佈流
程。可以通過Docker工具來快速部署,通過k8s來構建自動化部署編排等。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章