微服務架構不是銀彈，在微服務架構中，我們將面臨很多新的問題，這時候勢必會引入一個服務注冊發現問題。中培偉業《微服務架構設計與最佳實踐培訓》培訓專家程老師在這里就根據負載均衡位置的不同，三種主要的服務注冊與發現和負載均衡方案進行了詳細介紹。

1.微服務架構下服務注冊與發現機制

隨著微服務架構深入人心，越來越多的企業將微服務架構付諸實踐。相比于傳統的單體應用架構，微服務架構有著得天獨厚的優勢；在傳統的單體應用架構下，因為功能集中，代碼中心化，一個發布包部署發布在一個進程的應用程序中，單體應用架構已經無法滿足企業業務快速變化的需求。

一方面，代碼維護困難，擴展性較差，靈活性較低，另一方面，系統的修改成本，維護成本在增加以及構建時間，發布周期很長。而微服務架構，因為服務之間獨立部署，每個服務在開發，測試，部署的時候，無論是開發周期還是難易程度，都比單塊應用要好。

然而，微服務架構不是銀彈， 在微服務架構中，會面臨很多新的問題，微服務架構由一組小的服務組成，服務之間采用輕量級的通訊機制進行溝通，微服務之間調用關系是一個網狀結構，一個微服務在調用另一個微服務的時候，無法知道另一個微服務的具體地址；由于每個服務屬于”微”服務，每個服務生命周期不長，每個服務可能隨時被關閉、重啟、替換；在隨著訪問量增加的時候，微服務需要擴容，訪問量減少時，微服務需要縮容；這樣就導致每個微服務的地址在動態變化，這時候必然引入一個服務注冊發現問題，也就是說客戶端在調用的時候，需要知道服務端的地址，服務端在提供服務的時候，需要注冊通告自己的地址，供客戶端調用；同時服務端一般存在多個實例來提供服務，這就要求需要引入負載均衡的能力，隨著負載均衡位置的不同，主要的服務注冊與發現和負載均衡方案有三種。

2.常見的服務注冊與發現的方案

1).集中式負載均衡方案

集中式負載均衡也叫服務端負載均衡，負載均衡器在一臺單獨的主機上，可以采用軟負載，如nginxapache等，也可以采用硬負載，如F5等，它負責多實例服務的負載均衡，客戶端直接通過域名訪問負載均衡器，DNS服務器將域名解析到負載均衡器IP上：

該方案實現較為簡單，仍是業界的主流，可以充分利用負載均衡器的能力，根據不同的負載策略將請求分發到后面的服務實例上；同時，該方案缺點也很明顯，負載均衡器存在單點問題，所有的流量都需要通過負載均衡器，如果負載均衡器存在問題，則直接導致服務不能正常提供服務；中間經過負載均衡器做代理，性能也有一定損耗。

2).客戶端負載均衡方案

客戶端負載針對服務端負載的缺點，做了一定的改進，負載能力由客戶端進程提供，服務端實例注冊自己的地址到注冊中心，客戶端從注冊中心訂閱服務提供者的地址，獲取地址后，根據負載均衡實現策略進行服務路由。

該方案在解決了服務端負載的單點問題，每個客戶端都實現了自己的負載功能，負載能力和客戶端進程在一起，和客戶端的生命周期一致，如果負載均衡進程down了，則客戶端也down了，而且只影響本身客戶端，不會影響其他客戶端；同時，該方案也有一定的缺點，負載要求每個客戶端自己實現，如果不同的技術棧，每個客戶端則需要使用不同的語言實現自己的負載能力，技術難度較大；業界的motandubbo采用此方案做服務注冊與發現。

3).客戶端主機獨立負載均衡方案

第三種方案綜合了前2個方案的優缺點，服務發現和負載的能力從客戶端進程移出，客戶端進程和負載均衡進程是個獨立的進程，在同一個主機上；服務實例還是在啟動的時候注冊自己的地址到注冊中心，客戶端直接發送請求給本機的負載均衡器。

該方案是一個典型的分布式方案，沒有單點問題，如果一個主機的負載均衡器出問題，只影響一個節點調用，不影響其他的節點，負載均衡器本身負載也較小，性能損耗較低；同時也不需要多種語言實現自己的負載能力，負載能力是公用的；但是該方案部署復雜，維護困難，出了異常之后，調試負載，定位問題都比較麻煩。

3.新一代的選擇

對于服務注冊與發現，在普元新一代數字化企業云平臺中，可以選擇DevOps這條路來實現我們理想的運營，同時以微服務架構為核心。