有了服務(wù)注冊與發(fā)現(xiàn),客戶端就不用再去配置各個服務(wù)實(shí)例的地址,改為從注冊中心統(tǒng)一獲取。
那注冊中心又是怎么保證每個地址的可用狀態(tài)呢,假如某個實(shí)例掛了怎么辦呢?原則上掛掉的實(shí)例不應(yīng)該被客戶端獲取到,所以就要提到:健康檢查 。
常見注冊中心有 Consul、ZooKeeper、etcd、Eureka。
微服務(wù)帶來大的好處就是把整個大項(xiàng)目分割成不同的服務(wù),運(yùn)行在不同服務(wù)器上,實(shí)現(xiàn)解耦和分布式處理。微服務(wù)雖然有很多好處,但是也會有不好的一方面。任何事物都會有兩面性,在微服務(wù)里面運(yùn)維會是一個很大的難題,如果有一天我們的服務(wù)數(shù)量非常的多,然后我們又不知道哪一個服務(wù)在什么機(jī)器上??赡軙腥苏f這部分直接寫在程序的配置里面就好了,當(dāng)我們服務(wù)少的時候是可以這么做的,也允許這么做,但是在實(shí)際當(dāng)中我們要盡量避免這么做,比如說我們某一個服務(wù),地址換了,那么我們設(shè)計(jì)的相關(guān)代碼就得修改重新部署;又或者說我們有一天上線一個新服務(wù)或者下線一個服務(wù),這時候我們又得修改程序代碼,這是非常不合理的做法。那么有沒有什么可以解決這樣的問題呢?這里就需要用到我們的服務(wù)注冊和發(fā)現(xiàn)了。
上面圖片我們可以看到在沒有服務(wù)注冊發(fā)現(xiàn)的時候一個調(diào)用者需要維護(hù)多個服務(wù)的ip和端口,這是非常不好的做法,當(dāng)我們服務(wù)進(jìn)行調(diào)整的時候就有可能導(dǎo)致服務(wù)調(diào)用失敗,還有服務(wù)器更換服務(wù)器,上下新服務(wù),都會受到影響。將來某一個服務(wù)節(jié)點(diǎn)出現(xiàn)問題,排查對于程序和運(yùn)維人員來說都是一場很大的災(zāi)難,因?yàn)椴恢滥囊粋€節(jié)點(diǎn)出了問題,需要每一臺服務(wù)器的去排查。
而當(dāng)我們有使用服務(wù)注冊發(fā)現(xiàn)之后的結(jié)構(gòu)體是什么樣子的呢?
我們從上圖可以發(fā)現(xiàn),當(dāng)我們有注冊中心之后調(diào)用者不需要自己去維護(hù)所有服務(wù)的信息了,僅需要向注冊中心請求獲取服務(wù),就可以拿到想要的服務(wù)信息。這樣當(dāng)我們的服務(wù)有所調(diào)整,或者上線下線服務(wù),都要可以輕松操作,并且可以在注冊中間檢查到服務(wù)的健康情況,幫助運(yùn)維人員快速定位到故障的服務(wù)器。
在Swoft這個框架里面推薦我們使用的就是consul,consult是一個使用go寫的服務(wù)注冊、發(fā)現(xiàn)、配置管理系統(tǒng)。
Agent:Agent是Consul集群中一個常駐后臺的程序。Agent有兩種模式,一種是服務(wù)端,一種是客戶端。所有Agent都可以運(yùn)行DNS或者HTTP接口,并且負(fù)責(zé)檢查服務(wù)是否存活,和保持服務(wù)同步。
Client:Client是一種Agent的運(yùn)行模式,把所有RPC轉(zhuǎn)發(fā)到Agent服務(wù)器的代理者,客戶端會在后臺有一個用最小帶寬消耗把請求轉(zhuǎn)發(fā)到后端的Agent服務(wù),減輕Agent服務(wù)器的壓力。
Server:Server是另一種Agent的運(yùn)行模式,包括使用Raft算法處理數(shù)據(jù),維護(hù)集群狀態(tài),響應(yīng)RPC的請求,與其他集群的server交換數(shù)據(jù)或者遠(yuǎn)程數(shù)據(jù)中心。
RPC:遠(yuǎn)程過程調(diào)用,這是一種允許客戶端發(fā)出服務(wù)器請求的請求/響應(yīng)機(jī)制。
以上是我們本次比較重要的一些概念性的東西。知道每一個組件每一個部分干嘛的我們看以下的配置才會簡單,才會事半功倍。
在consult里面有很多組件,在這里我們暫時使用一個組件就夠了就是agent,對于consul的安裝也是非常簡單的畢竟只有一個二進(jìn)制文件包,所以直接下載就可以使用了。
文章參考:
https://www.sunnyos.com/article-show-85.html (描述作用)
https://www.cnblogs.com/xhznl/p/13091750.html (講解比較詳情,代碼注冊服務(wù))