本篇文章為大家展示了如何進(jìn)行微服務(wù)的服務(wù)注冊(cè)與發(fā)現(xiàn)，內(nèi)容簡明扼要并且容易理解，絕對(duì)能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。
新羅網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、自適應(yīng)網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。成都創(chuàng)新互聯(lián)公司自2013年起到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選成都創(chuàng)新互聯(lián)公司。
微服務(wù)從大規(guī)模使用到現(xiàn)在已經(jīng)有很多年了，從之前的探索到一步步的不斷完善與成熟，微服務(wù)已經(jīng)成為眾多架構(gòu)選擇中所必須面對(duì)的一個(gè)選項(xiàng)。服務(wù)注冊(cè)與發(fā)現(xiàn)是相輔相成的，所以一般會(huì)合起來思索。其依托組件有很多，比如Zookeeper,Consul，Eureka等等。
我們將探討服務(wù)注冊(cè)和發(fā)現(xiàn)的概念及其使用機(jī)制，以使得微服務(wù)能夠在不知道其確切位置（通常是URL）的情況下消費(fèi)其他服務(wù)。
服務(wù)是在具有單獨(dú)部署周期的不同計(jì)算機(jī)上運(yùn)行的單個(gè)或較小的代碼庫，可明確解決相關(guān)的問題域。不正確的服務(wù)設(shè)計(jì)可能導(dǎo)致重復(fù)的服務(wù)創(chuàng)建，同時(shí)也無法進(jìn)行架構(gòu)層面的復(fù)用。
如果沒有服務(wù)注冊(cè)與服務(wù)發(fā)現(xiàn)，那么服務(wù)的位置將會(huì)耦合到消費(fèi)者服務(wù)里面，最終將會(huì)導(dǎo)致整個(gè)系統(tǒng)的架構(gòu)變得死板而又難以維護(hù)。事實(shí)上，在比較簡單的系統(tǒng)架構(gòu)里，采用靜態(tài)配置的方式是非常簡單而又效果顯著的，畢竟所有服務(wù)都在同一位置，而且很少發(fā)生變更。
而在微服務(wù)里，其目標(biāo)之一就是使系統(tǒng)能夠獨(dú)立開發(fā)、部署及升級(jí)擴(kuò)展，隨著系統(tǒng)的進(jìn)一步復(fù)雜，服務(wù)位置也發(fā)生變更，那么靜態(tài)配置就會(huì)變得十分雞肋，此時(shí)我們需要變更我們的策略，那就是在消費(fèi)其他服務(wù)的時(shí)候采用靜態(tài)配置。那么核心問題就來了，服務(wù)是如何發(fā)現(xiàn)它們索要消費(fèi)的服務(wù)的IP地址和端口號(hào)的？既是動(dòng)態(tài)配置，在多實(shí)例場景下，配置在專門的系統(tǒng)里是最好的選擇，ZK和Consul等也就應(yīng)運(yùn)而生。
我們來看一下一個(gè)簡單的服務(wù)通信流程
透過這張圖，我們可以知道，服務(wù)調(diào)用時(shí)，無需知道目標(biāo)服務(wù)的真實(shí)地址，只需要知道服務(wù)Key，然后到服務(wù)發(fā)現(xiàn)系統(tǒng)里獲取對(duì)應(yīng)的地址即可。
這張圖雖然比較簡單，但是傳遞的信息卻有很多：
服務(wù)如何確定自身的IP地址及端口？
在消費(fèi)方拿到被消費(fèi)方的地址以后，應(yīng)采用何種方式調(diào)用？
我們?nèi)绾翁砑有路?wù)并刪除已棄用的服務(wù)？
如果服務(wù)在運(yùn)行過程中出現(xiàn)問題，如何快速發(fā)現(xiàn)并提前通知？
作為集中化管理的服務(wù)注冊(cè)與發(fā)現(xiàn)中心掛了，咋整？
一般可以創(chuàng)建服務(wù)注冊(cè)表，該服務(wù)注冊(cè)表是服務(wù)及其實(shí)例及其位置的數(shù)據(jù)庫。服務(wù)實(shí)例在啟動(dòng)時(shí)注冊(cè)到服務(wù)注冊(cè)表，并在關(guān)閉時(shí)注銷。客戶端查詢服務(wù)注冊(cè)表以查找服務(wù)的可用實(shí)例。服務(wù)注冊(cè)表可能會(huì)調(diào)用服務(wù)實(shí)例的運(yùn)行狀況檢查API來驗(yàn)證它是否能夠處理請(qǐng)求。我們已經(jīng)有了現(xiàn)成的工具，就是Consul等，那么我們的關(guān)注點(diǎn)就是服務(wù)地址的注冊(cè)了。
最簡單的解決方案就是手動(dòng)配置。我們思考一個(gè)問題，如果我們需要對(duì)該服務(wù)進(jìn)行水平擴(kuò)展，再增加一個(gè)實(shí)例的時(shí)候，仍然需要我們手動(dòng)配置，但是我們已經(jīng)不想手動(dòng)配置了，在DevOps時(shí)代，再使用手動(dòng)配置，就顯得不那么專業(yè)了，而且人工的介入，也增加了系統(tǒng)運(yùn)維的成本與風(fēng)險(xiǎn)。
所以我們選擇，自動(dòng)獲取本機(jī)IP地址，但是這里有一個(gè)問題，也是我在實(shí)際運(yùn)用中遇到的問題就是本地會(huì)有多個(gè)網(wǎng)卡的情況，這是比較麻煩的，所以那時(shí)候我建議每臺(tái)機(jī)器只配置一個(gè)網(wǎng)卡，以減少不確定性，但是后來，遇到一個(gè)新的問題就是，當(dāng)我想在服務(wù)器上安裝代理，以獲取請(qǐng)求包信息的時(shí)候，容易改變系統(tǒng)的運(yùn)行環(huán)境，依然存在著不確定性。后來我在網(wǎng)上查看是否其他方案的時(shí)候，始終沒有一個(gè)比較好的解決方案，后來有人說，直接往服務(wù)注冊(cè)中心發(fā)送一個(gè)Socket連接就可以了，通過Socket實(shí)例獲取本機(jī)IP，網(wǎng)上也有人介紹這種方案。
至于端口獲取，相對(duì)簡單一點(diǎn)，我們使用的就是直接配置在服務(wù)里。
服務(wù)注冊(cè)本身就是要在有限人力干預(yù)的情況下，支持不同應(yīng)用之間的運(yùn)行與交互。
這個(gè)地方更多的是考慮服務(wù)消費(fèi)方的負(fù)載均衡策略、調(diào)用策略以及容錯(cuò)的可配置性。
在被消費(fèi)方做了集群部署的時(shí)候，這就是要求我們根據(jù)實(shí)際運(yùn)行情況及時(shí)調(diào)整對(duì)服務(wù)的調(diào)用，那么該如何判斷呢？在實(shí)現(xiàn)上可以考慮權(quán)重參數(shù)，該參數(shù)的設(shè)置應(yīng)該來源于自身以及服務(wù)治理系統(tǒng)。
來源于自身，是因?yàn)槲覀兊姆?wù)可能部署在相對(duì)較差的機(jī)器上或者該服務(wù)本身只是一個(gè)備用系統(tǒng)，不應(yīng)該承載過大的流量。
來源于服務(wù)治理系統(tǒng)，是因?yàn)樵趯?shí)際運(yùn)行中，可能該系統(tǒng)已經(jīng)出現(xiàn)問題，或者需要暫時(shí)下線，我們可以設(shè)置權(quán)重系數(shù)為0，以從消費(fèi)服務(wù)本身來停止對(duì)該服務(wù)的調(diào)用。
權(quán)重參數(shù)只是其中一個(gè)，也是最容易想到和實(shí)現(xiàn)的一個(gè)，當(dāng)然還有其他參數(shù)，只要是為了更好的優(yōu)化服務(wù)間的調(diào)用，那么就可以注冊(cè)進(jìn)去，同時(shí)實(shí)現(xiàn)相應(yīng)的調(diào)用策略。比如版本號(hào)，TTL等等。
一旦信息多了，就需要考慮如何及時(shí)獲取變更，以調(diào)整調(diào)用策略。
服務(wù)發(fā)現(xiàn)可以分為客戶端發(fā)現(xiàn)或服務(wù)器端發(fā)現(xiàn)來確定要向其發(fā)送請(qǐng)求的服務(wù)實(shí)例的位置?？蛻舳税l(fā)現(xiàn)比較簡單一些，直接向服務(wù)發(fā)現(xiàn)中心獲取所需的被消費(fèi)者服務(wù)的信息。而服務(wù)端發(fā)現(xiàn)相對(duì)來說，比較復(fù)雜，需要?jiǎng)?chuàng)建一個(gè)路由中心，由路由中心去發(fā)現(xiàn)被消費(fèi)者的請(qǐng)求。我們這邊用的比較多的是客戶端發(fā)現(xiàn)。
確保發(fā)現(xiàn)的穩(wěn)定性，首先就要確保服務(wù)注冊(cè)中心的穩(wěn)定性，其地址不應(yīng)該頻繁發(fā)生變化，所以我們可以在服務(wù)中配置我們的服務(wù)注冊(cè)中的地址。此處需要多說明一下，就是作為服務(wù)注冊(cè)中心系統(tǒng)，一定要保持高可用性，可以通過集群以及負(fù)載均衡來增強(qiáng)可用性。
服務(wù)實(shí)例的數(shù)量及其位置是動(dòng)態(tài)變化的。通常為虛擬機(jī)和容器分配動(dòng)態(tài)IP地址。最復(fù)雜的問題自然是如何及時(shí)獲得被消費(fèi)者服務(wù)變化后的地址？我們可以創(chuàng)建一個(gè)路由功能，用戶可以客戶端查詢服務(wù)注冊(cè)中心以查找服務(wù)的可用實(shí)例。服務(wù)注冊(cè)中心可能會(huì)調(diào)用服務(wù)實(shí)例的運(yùn)行狀況檢查API來驗(yàn)證它是否能夠處理請(qǐng)求。
我們?cè)谙到y(tǒng)啟動(dòng)的時(shí)候，會(huì)做個(gè)Reload，以加載最新信息。那么之后如何及時(shí)獲取最新信息呢？通常情況下有兩種，主動(dòng)輪詢和獲取推送消息。
主動(dòng)輪詢帶有隨機(jī)性，如果恰恰好，可能會(huì)很及時(shí)，大多數(shù)情況下，可能沒那么恰恰好，而且還要增加服務(wù)發(fā)現(xiàn)中心的負(fù)載壓力。
推送方式在效果上可能更好一些，在具體實(shí)現(xiàn)上可能沒有那么簡單。
一般而言，健康檢查包括，客戶端心跳和服務(wù)端主動(dòng)探測兩種方式，
首先來說，客戶端心跳，就是客戶端通過TCP或者HTTP的方式，告訴服務(wù)端自身的運(yùn)行情況，當(dāng)然客戶端通知是有弊端的，比如客戶端在某一時(shí)間點(diǎn)出現(xiàn)故障時(shí)，無法及時(shí)通知服務(wù)端，事后恢復(fù)運(yùn)行后，告知的也只是當(dāng)前的運(yùn)行狀態(tài)，即便這時(shí)再告訴服務(wù)端之前的運(yùn)行狀況，也對(duì)服務(wù)調(diào)用沒有什么太大意義了，只是對(duì)服務(wù)本身的運(yùn)行分析起到了一定作用。即便是保持正常連接的情況下，服務(wù)也未必是可以調(diào)用的，比如數(shù)據(jù)庫掛掉。
一般而言，采用服務(wù)端探測的比較多一些，調(diào)用方式和客戶端心跳差不多，但是仍然需要我們注意的是，客戶端所提供的探測接口必須具有通用性，比如可以查一下次數(shù)據(jù)庫等等，這樣可以比較全面的反應(yīng)系統(tǒng)的運(yùn)行情況。
容災(zāi)的原因有很多，比如服務(wù)不再使用、雙11大流量的涌進(jìn)，使得其中一些服務(wù)不可用，也就不得不針對(duì)性的對(duì)一些服務(wù)進(jìn)行容災(zāi)處理，以集中資源給核心應(yīng)用。在容災(zāi)過程中，可以給服務(wù)下線功能可以制定一些策略，以豐富功能的使用。.NET Core里面可以使用IApplicationLifetime來顯示下線功能。當(dāng)然也需要提供手動(dòng)下線的接口。
容災(zāi)主要考慮方向是客戶端容災(zāi)和服務(wù)端容災(zāi)?？蛻舳巳轂?zāi)中，如果服務(wù)注冊(cè)中心掛掉了，恢復(fù)運(yùn)行可能需要一段時(shí)間，在這個(gè)過程中如果保證服務(wù)正常運(yùn)行。在實(shí)際運(yùn)行中非常有可能發(fā)生這種情況，我們可以將服務(wù)發(fā)現(xiàn)中心獲取的信息緩存起來，緩存方式有很多，無外乎是本地內(nèi)存、文件以及外部存儲(chǔ)，本地內(nèi)存還要還要考慮該服務(wù)重啟過程中的數(shù)據(jù)丟失，所以可選的方式就有內(nèi)存+文件方式。反之，為了達(dá)到容災(zāi)的要求，我們可以在獲取服務(wù)發(fā)現(xiàn)中心返回的數(shù)據(jù)的過程中將數(shù)據(jù)存在到內(nèi)存和文件中，可以采用異步方式存儲(chǔ)。
如下圖所示，在發(fā)現(xiàn)過程中，使用緩存功能，如果緩存都失效了，那就真的要game over一陣子了。
服務(wù)端容災(zāi)，就比較簡單了，因?yàn)楝F(xiàn)在大多數(shù)做的都是服務(wù)端容災(zāi)，比如集群等水平擴(kuò)展方式， 可主動(dòng)從其他節(jié)點(diǎn)同步相應(yīng)的數(shù)據(jù)，也可等待master的同步。
服務(wù)注冊(cè)與發(fā)現(xiàn)在服務(wù)生命周期中發(fā)揮著重要作用。動(dòng)態(tài)的服務(wù)注冊(cè)和發(fā)現(xiàn)變得非常重要，它可以避免服務(wù)中斷。在處理服務(wù)實(shí)例的容災(zāi)與故障轉(zhuǎn)移時(shí)，盡量實(shí)現(xiàn)自動(dòng)轉(zhuǎn)移，并提供手動(dòng)方式處理，而對(duì)于跨服務(wù)調(diào)用，尤其是該服務(wù)擁有多實(shí)例服務(wù)的時(shí)候，需要考慮負(fù)載平衡。
上述內(nèi)容就是如何進(jìn)行微服務(wù)的服務(wù)注冊(cè)與發(fā)現(xiàn)，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
重慶分公司
重慶分公司
