在傳統應用中，對於其他服務的依賴通常是在安裝的時候寫在配置文件裡面的。客戶端在訪問服務端的時候會從配置文件中讀取服務端信息，之後再構造請求連接進行訪問。這種模式在微服務的情況下是行不通的。一個應用被拆分成了多個服務，服務之間的依賴要比之前的依賴多幾個數量級。如果這個時候依然使用配置文件的方式，那麼配置這些文件就是一個噩夢。另外，一般服務是以多實例的形態存在，在擴容或者收縮實例時，IP信息會發生變化，每次去修改配置文件是不現實的事情。為此，服務發現出現了。
總體來說，服務發現分兩種：客戶端服務發現和服務端服務發現。
客戶端服務發現
在客戶端服務發現的場景下，服務在啟動的時候會把自己註冊到註冊中心，並且在之後的運行中會與註冊中心以心跳的方式保持聯繫。當服務down掉時，這個服務的信息會從註冊中心刪除；當有新服務加入時，新服務會把自己的信息註冊到註冊中心，讓客戶端能夠感知到新服務的存在。客戶端會持有註冊中心的訪問信息。因為註冊中心的訪問信息是相對比較固定的，基本不會發生變化，所以註冊中心的訪問信息可以寫到配置文件中。客戶端在需要訪問服務端的時候，會去註冊中心查訊服務端信息，再拿著服務端信息去訪問。
服務端服務發現
服務端服務發現與客戶端服務發現比較相似，區別就是，客戶端不去感知服務發現的信息。客戶端只與負載均衡器進行交互。服務發現的能力由負載均衡器進行實現。
在服務發現中，一般客戶端是具有負載均衡能力的。客戶端從服務端拿到全部的服務端信息之後，可以隨機挑選一個服務或者對這些服務進行輪詢，再或者使用一致哈希算法進行選擇。
服務發現的能力中，一般也會帶有路由的能力。通過路由可以配置客戶端可以訪問哪些服務。利用這個能力，能夠實現灰度發佈，即環境中同時存在高版本和低版本的服務，利用路由能力，使一部分客戶端使用新版本的服務，另一部分客戶端使用舊版本的服務。
服務發現框架一般還要具備調用鏈跟蹤、熔斷和服務降級能力。
當前註冊中心一般使用etcd、zk等。作為註冊中心本身，需要具備這些能力：1.服務健康檢測的能力，一般通過心跳的方式實現；2.服務信息更新後通知客戶端的能力。註冊中心不需要強一致性。很多服務發現框架都採用AP存儲來實現，即保證可用性和分區容忍性而不要求一致性。
現在有比較多的服務發現開源框架，如阿里的dubbo、華為的servicecomb、百度的bsf、spring cloud等。一般不需要自己實現，使用開源框架即可。
閱讀更多 java技術小碼農 的文章
