問題緣由

隨著時代發(fā)展，單機程序遇到了計算力和存儲的雙重瓶頸，分布式架構(gòu)應(yīng)運而生。單體應(yīng)用通過函數(shù)名(標(biāo)識)便可輕松完成本地函數(shù)調(diào)用，在分布式系統(tǒng)中，服務(wù)(RPC/RESTful API)承擔(dān)了類似的角色，但請求服務(wù)單靠服務(wù)名還不夠，服務(wù)名只是服務(wù)能力(服務(wù)類型)的標(biāo)識，還需要指示服務(wù)位于網(wǎng)絡(luò)何處，而部署在云中的服務(wù)實例IP是動態(tài)分配的，擴縮容、失敗和更新則讓問題變得更加復(fù)雜，靜態(tài)配置服務(wù)實例適應(yīng)不了新變化，需要更精細化的服務(wù)治理能力，為了解決或者說簡化這個問題，服務(wù)發(fā)現(xiàn)作為一種基礎(chǔ)能力被抽象和提供，它試圖讓請求網(wǎng)絡(luò)服務(wù)像調(diào)用本地函數(shù)一樣簡單透明。

服務(wù)即功能(函數(shù))。只是服務(wù)跟網(wǎng)絡(luò)緊密聯(lián)系在一起，所有才會出現(xiàn)網(wǎng)絡(luò)服務(wù)這個名詞，服務(wù)提供者通過網(wǎng)絡(luò)發(fā)布服務(wù)，服務(wù)使用者通過網(wǎng)絡(luò)請求服務(wù)，分布式系統(tǒng)突破了單機算力和存儲的限制，提升了系統(tǒng)穩(wěn)定性，使得高并發(fā)高可用的海量服務(wù)成為可能，但這也增加了軟件復(fù)雜度，引入軟件分層、負載均衡、微服務(wù)、服務(wù)發(fā)現(xiàn)/治理、分布式一致性等新的問題和挑戰(zhàn)。

服務(wù)發(fā)現(xiàn)

服務(wù)分服務(wù)提供者(Service Provider)和服務(wù)消費者(Service Consumer)，如果要提供海量服務(wù)能力，單一的服務(wù)實例顯然是不夠的，如果要提供成千上萬種服務(wù)，則需要有一個地方記錄服務(wù)名到服務(wù)實例列表的映射，所以，有必要引入一個新的角色：服務(wù)中介，服務(wù)中介維護一個服務(wù)注冊表(Service Registry)，可以把注冊表理解為服務(wù)字典，key是服務(wù)名，value是服務(wù)提供實例列表;服務(wù)注冊表是聯(lián)系服務(wù)提供者和服務(wù)消費者的橋梁，它維護服務(wù)提供者的最新網(wǎng)絡(luò)位置等信息，也是服務(wù)發(fā)現(xiàn)最核心的部分。

服務(wù)啟動的時候，把服務(wù)信息注冊(put)到服務(wù)注冊表;服務(wù)終止的時候，從服務(wù)注冊表刪除(remove)自身的服務(wù)信息。

服務(wù)消費者在請求服務(wù)的時候，先去服務(wù)注冊表按名查詢(get)服務(wù)提供者列表，然后從列表里挑選一個服務(wù)實例，向該實例請求服務(wù)。

大道至簡，這便是最簡單的服務(wù)發(fā)現(xiàn)模型，也是服務(wù)發(fā)現(xiàn)的基本原理，至此，似乎一切都OK，但其實尚有幾個問題沒有說清楚。

問題和解法

第一個問題

服務(wù)如果不是正常停止，而是被系統(tǒng)kill掉，它便沒有機會通知服務(wù)注冊表把自身服務(wù)信息刪除，這樣注冊表便多了一條指向無效服務(wù)實例的信息，而服務(wù)消費者卻并不知情，怎么辦?解決的辦法很簡單：保活(keepalive)，服務(wù)提供者定期(比如每隔10秒)給服務(wù)中介發(fā)送keepalive消息，服務(wù)中介收到keepalive消息后更新該服務(wù)實例的keepalive timestamp，服務(wù)中介定期檢查該timestamp，如果超期便把該服務(wù)實例從注冊表剔除。

第二個問題

服務(wù)實例列表變化如何通知服務(wù)消費者?不外乎兩種方法，輪詢和pub-sub。輪詢是消費者主動詢問服務(wù)中介服務(wù)列表是否變化，如果有變化，則把新的服務(wù)列表發(fā)送給消費者。如果消費者過多，則服務(wù)中介處理輪詢的消息會有壓力，在服務(wù)類別很多，服務(wù)列表很大的時候，它甚至?xí)蔀槠款i。pub-sub是服務(wù)中介主動通知服務(wù)消費者，時效性相比輪詢更好，缺點是會占用單獨的線程或者連接資源。

第三個問題

服務(wù)中介如果掛了怎么辦?所以我們要解決單點的問題，通常會用集群來對抗這種脆弱性，有很多用于做服務(wù)注冊表的開源解決方案，比如etcd/zookeeper/consul，本質(zhì)上使用分布式一致性數(shù)據(jù)庫來保存注冊表信息，它既解決讀寫性能問題又提高了系統(tǒng)穩(wěn)定性可用性。

第四個問題

如果服務(wù)消費者每次使用遠程服務(wù)都需要先查詢服務(wù)中介獲取實例列表，再請求服務(wù)，這樣效率太低效?對服務(wù)中介的壓力也不小?通常，客戶端會緩存服務(wù)實例列表，這樣對同名服務(wù)的多次請求，便不用重復(fù)查詢，既減少了延遲又減輕了對服務(wù)中介的訪問壓力。

第五個問題

前述的keepalive有間隔，如果在這個間隔內(nèi)服務(wù)實例不可用，那么服務(wù)消費者還是不能感知的，所以還是有可能把請求發(fā)送到一個無法提供服務(wù)的網(wǎng)絡(luò)遠端機器上去，這樣自然是沒法work。我們無法從根本上杜絕這種情況，系統(tǒng)需要容忍這種錯誤，但也可以做一些改進，比如向某實例請求服務(wù)失敗后便拉黑，避免向同一無效服務(wù)實例多次派發(fā)請求。

第六個問題

服務(wù)消費者怎么從多個服務(wù)實例里選擇一個?如何確保同一服務(wù)消費者的多次服務(wù)請求被分配到固定的服務(wù)實例(有時候需要這樣)?這其實就是負載均衡的問題，有多種策略，比如rr、優(yōu)先級、比如加權(quán)隨機、一致性哈希。

服務(wù)發(fā)現(xiàn)模式

服務(wù)發(fā)現(xiàn)主要有兩種模式：客戶端發(fā)現(xiàn)模式(client-side discovery)和服務(wù)端發(fā)現(xiàn)模式(server-side discovery)。

客戶端發(fā)現(xiàn)模式

客戶端負責(zé)查詢服務(wù)實例列表并決定向哪個實例請求服務(wù)，也就是負載均衡策略在客戶端實現(xiàn)。該模式包括注冊和發(fā)現(xiàn)兩個部分。

服務(wù)實例調(diào)用服務(wù)中介的注冊接口進行實例注冊，服務(wù)實例通過keepalive做服務(wù)續(xù)期，服務(wù)中介通過健康檢查剔除不可用的服務(wù)實例。

服務(wù)消費者請求服務(wù)的時候，先向服務(wù)注冊表查詢服務(wù)實例列表，注冊表是一個服務(wù)數(shù)據(jù)庫，為了提升性能和可靠性，客戶端通常會緩存服務(wù)列表(緩存用來確保注冊表掛了之后還能繼續(xù)工作)，拿到實例列表后客戶端基于負載均衡策略挑選一個實例發(fā)送服務(wù)請求。

優(yōu)點：

• 直接，客戶端可以靈活的執(zhí)行負載均衡策略。
• 去中心化，非網(wǎng)關(guān)式，有效避開單點瓶頸和可靠性下降。
• 服務(wù)發(fā)現(xiàn)直接SDK集成進客戶端，這種語言整合程度很好，程序執(zhí)行性能也很好，排錯方便。

缺點：

• 客戶端與服務(wù)注冊表耦合，需要為服務(wù)客戶端使用的每種語言每種框架開發(fā)服務(wù)發(fā)現(xiàn)邏輯。
• 這種侵入式的集成會導(dǎo)致任何服務(wù)發(fā)現(xiàn)的變化都需要客戶端應(yīng)用程序重新編譯和部署，強綁定違背了獨立性原則。
• 服務(wù)上下線會對調(diào)用方有影響，導(dǎo)致服務(wù)短暫不可用。

服務(wù)端發(fā)現(xiàn)模式

發(fā)現(xiàn)：服務(wù)消費者通過負載均衡器發(fā)送服務(wù)請求，負載均衡器會查詢服務(wù)注冊表，挑選一個服務(wù)實例，并將請求轉(zhuǎn)發(fā)到服務(wù)實例。

注冊：服務(wù)注冊/注銷可以跟上述客戶端發(fā)現(xiàn)模式一致，也可以通過部署平臺的內(nèi)置服務(wù)注冊和發(fā)現(xiàn)機制完成，即容器化部署平臺(docker/k8s)能主動發(fā)現(xiàn)服務(wù)實例并幫助服務(wù)實例完成注冊注銷。

對比客戶端發(fā)現(xiàn)模式，使用服務(wù)端發(fā)現(xiàn)模式的客戶端本地不保存服務(wù)實例列表，客戶端不做負載均衡，這個負載均衡器既承擔(dān)了服務(wù)發(fā)現(xiàn)的角色，又承擔(dān)了網(wǎng)關(guān)的角色，所以經(jīng)常叫API網(wǎng)關(guān)服務(wù)器。

因為負載均衡器是中心式的，所以它也必須是一個集群，單個實例不足以支撐高并發(fā)訪問，針對負載均衡器本身的服務(wù)發(fā)現(xiàn)和負載均衡通常借助DNS。

Http服務(wù)器，Nginx、Nginx Plus就是此類服務(wù)端發(fā)現(xiàn)模式的負載均衡器。

優(yōu)點：

• 服務(wù)發(fā)現(xiàn)對于服務(wù)消費者是透明的，服務(wù)消費者與注冊表解耦，服務(wù)發(fā)現(xiàn)功能的更新對客戶端無感知。
• 服務(wù)消費者只需要向負載均衡器發(fā)送請求，不需要為每種服務(wù)消費者的編程語言和框架，開發(fā)服務(wù)發(fā)現(xiàn)邏輯SDK。

缺點：

• 由于所有請求都要經(jīng)負載均衡器轉(zhuǎn)發(fā)，所以負載均衡器有可能成為新的性能瓶頸。
• 負載均衡器(服務(wù)網(wǎng)關(guān))是中心式的，而中心式的架構(gòu)會有穩(wěn)定性的隱憂。
• 因為負載均衡器轉(zhuǎn)發(fā)請求，所以RT會比客戶端直連模式高。

微服務(wù)和服務(wù)發(fā)現(xiàn)

Service Mesh服務(wù)網(wǎng)格是服務(wù)于微服務(wù)應(yīng)用程序的可配置基礎(chǔ)設(shè)施層，旨在處理服務(wù)之間的大量基于網(wǎng)絡(luò)的進程間通信。

Service Mesh服務(wù)網(wǎng)關(guān)解耦調(diào)用和通信，在非mesh下，對于協(xié)議的感知和服務(wù)發(fā)現(xiàn)方法的感知需要應(yīng)用去做，用mesh之后，就只管調(diào)用，mesh通過控制面來控制應(yīng)用的數(shù)據(jù)流。

Mesh做服務(wù)發(fā)現(xiàn)其實是客戶端發(fā)現(xiàn)模式的升級版，基于sidecar和pilot實現(xiàn)，Sidecars，即數(shù)據(jù)面板(Data Plane)，負責(zé)發(fā)現(xiàn)目標(biāo)服務(wù)實例地址列表并轉(zhuǎn)發(fā)請求。Pilots，即控制面板(Control Plane)，負責(zé)管理服務(wù)注冊表的所有服務(wù)注冊信息。

服務(wù)注冊模式

一個選擇是服務(wù)實例自注冊，即self-registration模式。另一種選擇是其它的系統(tǒng)組件來管理服務(wù)實例的注冊，即third-party registration模式。

自注冊模式如前面所述，它足夠簡單，不需要第三方組件，缺點是必須為服務(wù)中用到的每種編程語言與框架實現(xiàn)注冊代碼。

第三方注冊服務(wù)實例不會自己完成注冊注銷，它由另一個叫做Service Registrar的系統(tǒng)組件負責(zé)，該組件會輪詢部署環(huán)境或者跟蹤訂閱事件去感知服務(wù)實例的變化，幫助服務(wù)實例完成自動化注冊注銷。

Third-party registration模式主要的優(yōu)勢在于解耦了服務(wù)和服務(wù)注冊表。不需要為每個語言和框架都實現(xiàn)服務(wù)注冊邏輯。服務(wù)實例注冊由一個專用的服務(wù)集中實現(xiàn)。缺點是除了被內(nèi)置到部署環(huán)境中，它本身也是一個高可用的系統(tǒng)組件，需要被啟動和管理。

其他

如果某個服務(wù)對于的服務(wù)實例特別多，比如在一些頭部公司，一個服務(wù)名可能對應(yīng)幾千幾萬個服務(wù)實例，這樣，服務(wù)變更的查詢和對比會很慢，IO的量會大得超過想象，通常，會用version num去解決這個問題。

以上就是淺談服務(wù)發(fā)現(xiàn)和負載均衡的來龍去脈的詳細內(nèi)容，更多關(guān)于服務(wù)發(fā)現(xiàn)和負載均衡的來龍去脈的資料請關(guān)注腳本之家其它相關(guān)文章！