微服務(wù)架構(gòu)不是銀彈，在微服務(wù)架構(gòu)中，我們將面臨很多新的問題，這時候勢必會引入一個服務(wù)注冊發(fā)現(xiàn)問題。本文作者向大家介紹了隨著負(fù)載均衡位置的不同，三種主要的服務(wù)注冊與發(fā)現(xiàn)和負(fù)載均衡方案。
1.微服務(wù)架構(gòu)下服務(wù)注冊與發(fā)現(xiàn)機(jī)制
隨著微服務(wù)架構(gòu)深入人心，越來越多的企業(yè)將微服務(wù)架構(gòu)付諸實踐。相比于傳統(tǒng)的單體應(yīng)用架構(gòu)，微服務(wù)架構(gòu)有著得天獨厚的優(yōu)勢;在傳統(tǒng)的單體應(yīng)用架構(gòu)下，因為功能集中，代碼中心化，一個發(fā)布包部署發(fā)布在一個進(jìn)程的應(yīng)用程序中，單體應(yīng)用架構(gòu)已經(jīng)無法滿足企業(yè)業(yè)務(wù)快速變化的需求。
一方面，代碼維護(hù)困難，擴(kuò)展性較差，靈活性較低，另一方面，系統(tǒng)的修改成本，維護(hù)成本在增加以及構(gòu)建時間，發(fā)布周期很長。而微服務(wù)架構(gòu)，因為服務(wù)之間獨立部署，每個服務(wù)在開發(fā)，測試，部署的時候，無論是開發(fā)周期還是難易程度，都比單塊應(yīng)用要好。
然而，微服務(wù)架構(gòu)不是銀彈， 在微服務(wù)架構(gòu)中，會面臨很多新的問題，微服務(wù)架構(gòu)由一組小的服務(wù)組成，服務(wù)之間采用輕量級的通訊機(jī)制進(jìn)行溝通，微服務(wù)之間調(diào)用關(guān)系是一個網(wǎng)狀結(jié)構(gòu)，一個微服務(wù)在調(diào)用另一個微服務(wù)的時候，無法知道另一個微服務(wù)的具體地址;由于每個服務(wù)屬于”微”服務(wù)，每個服務(wù)生命周期不長，每個服務(wù)可能隨時被關(guān)閉、重啟、替換;在隨著訪問量增加的時候，微服務(wù)需要擴(kuò)容，訪問量減少時，微服務(wù)需要縮容;這樣就導(dǎo)致每個微服務(wù)的地址在動態(tài)變化，這時候必然引入一個服務(wù)注冊發(fā)現(xiàn)問題，也就是說客戶端在調(diào)用的時候，需要知道服務(wù)端的地址，服務(wù)端在提供服務(wù)的時候，需要注冊通告自己的地址，供客戶端調(diào)用;同時服務(wù)端一般存在多個實例來提供服務(wù)，這就要求需要引入負(fù)載均衡的能力，隨著負(fù)載均衡位置的不同，主要的服務(wù)注冊與發(fā)現(xiàn)和負(fù)載均衡方案有三種。
2.常見的服務(wù)注冊與發(fā)現(xiàn)的方案
1).集中式負(fù)載均衡方案
集中式負(fù)載均衡也叫服務(wù)端負(fù)載均衡，如圖1所示，負(fù)載均衡器在一臺單獨的主機(jī)上，可以采用軟負(fù)載，如nginx，apache等，也可以采用硬負(fù)載，如F5等，它負(fù)責(zé)多實例服務(wù)的負(fù)載均衡，客戶端直接通過域名訪問負(fù)載均衡器，DNS服務(wù)器將域名解析到負(fù)載均衡器IP上：
該方案實現(xiàn)較為簡單，仍是業(yè)界的主流，可以充分利用負(fù)載均衡器的能力，根據(jù)不同的負(fù)載策略將請求分發(fā)到后面的服務(wù)實例上;同時，該方案缺點也很明顯，負(fù)載均衡器存在單點問題，所有的流量都需要通過負(fù)載均衡器，如果負(fù)載均衡器存在問題，則直接導(dǎo)致服務(wù)不能正常提供服務(wù);中間經(jīng)過負(fù)載均衡器做代理，性能也有一定損耗。
2).客戶端負(fù)載均衡方案
客戶端負(fù)載針對服務(wù)端負(fù)載的缺點，做了一定的改進(jìn)，如圖2所示，負(fù)載能力由客戶端進(jìn)程提供，服務(wù)端實例注冊自己的地址到注冊中心，客戶端從注冊中心訂閱服務(wù)提供者的地址，獲取地址后，根據(jù)負(fù)載均衡實現(xiàn)策略進(jìn)行服務(wù)路由：
該方案在解決了服務(wù)端負(fù)載的單點問題，每個客戶端都實現(xiàn)了自己的負(fù)載功能，負(fù)載能力和客戶端進(jìn)程在一起，和客戶端的生命周期一致，如果負(fù)載均衡進(jìn)程down了，則客戶端也down了，而且只影響本身客戶端，不會影響其他客戶端;同時，該方案也有一定的缺點，負(fù)載要求每個客戶端自己實現(xiàn)，如果不同的技術(shù)棧，每個客戶端則需要使用不同的語言實現(xiàn)自己的負(fù)載能力，技術(shù)難度較大;業(yè)界的motan，dubbo采用此方案做服務(wù)注冊與發(fā)現(xiàn)。
3).客戶端主機(jī)獨立負(fù)載均衡方案
第三種方案綜合了前2個方案的優(yōu)缺點，如圖3所示，服務(wù)發(fā)現(xiàn)和負(fù)載的能力從客戶端進(jìn)程移出，客戶端進(jìn)程和負(fù)載均衡進(jìn)程是2個獨立的進(jìn)程，在同一個主機(jī)上;服務(wù)實例還是在啟動的時候注冊自己的地址到注冊中心，客戶端直接發(fā)送請求給本機(jī)的負(fù)載均衡器。
該方案是一個典型的分布式方案，沒有單點問題，如果一個主機(jī)的負(fù)載均衡器出問題，只影響一個節(jié)點調(diào)用，不影響其他的節(jié)點，負(fù)載均衡器本身負(fù)載也較小，性能損耗較低;同時也不需要多種語言實現(xiàn)自己的負(fù)載能力，負(fù)載能力是公用的;但是該方案部署復(fù)雜，維護(hù)困難，出了異常之后，調(diào)試負(fù)載，定位問題都比較麻煩。