我們先來看一個最簡單的情況,A,B兩個服務,他們都有自己的地址,既然都有地址,A里面配一下B的地址不就好了,這不就能找到了嗎,簡單明了,但是現在變成分布式的了,我前面說分布式定義的時候,也說到,多個處理元素,不共享主內存,所以在分布式系統里面呢,A是多節點的,B也是多節點的,但是在這里先把問題簡化一下,我們先把B做成多節點的,就是A怎么來找多節點的B呢,有人說簡單,繼續寫配置,把這三個地址都寫到A里面去,沒錯,當B服務不多的時候,也是個辦法,但是有一天B要是很多了呢,100個,1000個,你還寫配置嗎,更何況現在已經到了云服務的時代,B服務不僅多,B的數目還會變,它會根據流量的大小,調整服務的數量,比如在流量比較小的時候,服務數目可能就會比較少,當大流量過來的時候呢,就需要很多的服務了,另一方面呢,這機器有的時候可能扛不住,機器是有可能掛掉的,服務也就掛掉了,總而言之呢,B服務的數量在不停的變化,你這個時候要是把配置寫在A里面,那肯定沒戲,我們應該怎么來做呢

這個時候必然就會出現一個角色了,叫做注冊中心,B啟動的時候呢,就會把自己的信息上報到注冊中心去,來一個報一個,來兩個報一雙,來再多的服務都要對他進行上報,這個時候A要調用B的話,你就去服務中心去取信息就好了,我看到這個圖的時候,我覺得特別有畫面感,這個很類似于什么事情呢,大家看古裝劇肯定看到過,嫖客去青樓,這注冊中心類似于什么,就類似于青樓的媽媽,那么A就是嫖客,B自然就是青樓的女子,那么往常A一來就要說出名字,我要春花,我要秋月,那么現在有了注冊中心,有了媽咪,你可以直接跟他說,我就要你們加的花魁,這個時候你就不用關心那么多了,你直接找媽咪就對了,最近還有個廣告呢,沒有中間商賺差價,你看這個圖,注冊中心就是中間商,他就是A和B之間的橋梁,A和B完全就靠它來溝通,說了這么多呢,我們回到正題,因此分布式系統中,服務注冊中心,肯定是最重要的基礎部分,注意我說的是最重要的基礎部分,隨時都應該提供服務的狀態,無論你用不用Eureka,服務注冊組件隨時都應該是高可用的,也是采用集群的基本方案,因為如果這一部分掛了,那你所有的服務基本上就成了無頭蒼蠅,不知道要去找誰,因為B服務啟動的時候,要像服務中心進行注冊,我們看一下A是如何像注冊中心拿到B的信息的呢,有兩種方法,第一種很容易,A直接來找注冊中心,注冊中心把上面所有B服務的信息,全部告訴A,這個時候A從B獲取服務呢,注意這里A調用B,只要選一個服務去調用,所以他從注冊中心拿到地址之后呢,他要挑選出來一個,他可以通過某種機制,比如輪詢,隨機,哈希,其實就是負載均衡的機制,從眾多可用的B里面挑出來一個,然后通過IP地址找到B,這種方式叫客戶端發現,是由A發起的,另一種方式出現了一種新的角色,叫做代理,A從眾多的B里面挑出一個出來,然后A再去找B,這種方式叫服務發現,我們可以看得出來,最終的目的就是要挑選一個B出來,那看在哪邊挑選,在客戶端叫客戶端發現,在服務端叫服務端發現

這兩種方式各有優缺點,客戶端發現的優點,那就是簡單直接,不需要代理的介入,同時客戶端是知道所有可用實際的地址的,缺點也很明顯,A服務得自己去實現一堆邏輯,把B給他挑出來,我們在看服務端發現的優缺點,他的優點也很明顯,代理的介入,B和注冊中心對A,是透明不可見的,A服務只需要找代理,我現在想問個問題,大家覺得Eureka是哪種方式呢,不妨先想一下,其實很明顯,Eureka采用的是客戶端發現的方式,我們并沒有用代理來做一個介入,那服務端發現有誰呢,其實服務端發現的更多,比如Nginx,Nginx不僅僅是可以做HTTP反向代理服務器,和負載均衡器,也可以作為一個服務發現的負載均衡器,經常拉過來做這個角色,還有我們之前提到的阿里系的Dubbo,在使用Dubbo的時候,一般會結合使用Zookeeper來作為注冊中心來使用,另外還有Kubernetes,不知道大家知不知道這個,最近也是比較火,后面我們提到Docker的時候呢,也會提到Kubernetes,它是通過集群中運行的每一個節點,都運行一個代理,來實現服務發現的功能,代理的角色就是server side discovery,客戶端根據主機的IP地址和端口,向代理發送請求,代理再將請求轉發到集群里面,任何一個可用的服務上,他也是屬于服務端發現的范疇,Eureka采用客戶端發現的方式,是一種權衡,在服務發現機制上的一種權衡,兩種方式都有利有弊,看你怎么選,不信我們來試試

大家發揮一下想象力,現在服務注冊發現,這里是Eureka Server,前端服務和后端通用服務,我這里都會用EnableEureka注解,他們都向注冊中心注冊了自己,現在大家都可以正常調用了,一切看上去都特別的美好,但是有沒有人思考過這個問題,雖然大家現在都是JAVA程序員,雖然JAVA不是世界上最好的語言,你不能強迫別人都來用JAVA吧,假如別人的服務都不是用JAVA來開發的,那還能注冊上去嗎

所以我們這里要直面微服務的一個特點,異構,這個詞很書面化,服務間可以用不同的語言,同時每個服務根據需要,也可以選用不同類型的數據庫,這個現象我們稱之為異構,Spring Cloud是一個很強大的微服務框架,但是他是純JAVA的,這對JAVA的團隊來說呢,當然是個福音,但是真實情況下,微服務落地的時候呢,特別是你越大的微服務系統,遇到非JAVA的部分呢,因為每種語言都有他自己的優勢,那現在問題來了,假如我現在用的語言是PHP,又或者是其他的語言,該怎么通過注冊中心,調用其他的服務呢,我們先可以把問題提升到一個比較高的層次,SpringCloud的服務調用方式,微服務他的一個特點,就是輕量級的通信,那現在流行的輕量級通信機制是什么呢,要么就是HTTP的RESTFul API接口,要么就是RPC,那SpringCloud選擇的是Rest,所以Eureka的服務端呢,提供了較為完善的REST API,他對外提供了API,Eureka也支持將非JAVA的服務,納入到自己的服務治理體系中來,需要其他語言自己實現,比如Node.js實現了eureka-js-client,由于REST API實現簡單,所以其他語言要實現Eureka的客戶端呢,也是相對比較容易的,它提供了接口讓你調用的

理解分布式架構的特點,原理更重要,微服務怎么落地呢,不是照搬書本,也沒有固定的套路,雖然我們這里主要講的SpringCloud,但是實際生產中呢,各種方式混搭,阿里系,SpringCloud混搭的都有用,大家千萬不要固化思維,要能夠靈活運用

?

總結

以上是生活随笔為你收集整理的分布式下服务注册的地位和原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。