# 微服務中的服務發現 在單體架構時，因為服務不會經常和動態遷移，所有服務地址可以直接在配置文件中配置，所以也不會有服務發現的問題。但是對于微服務來說，應用的拆分，服務之間的解耦，和服務動態擴展帶來的服務遷移，服務發現就成了微服務中的一個關鍵問題。 服務發現分為**客戶端服務發現**和**服務端服務發現**兩種，架構如下圖所示。  這兩種架構都各有利弊，我們拿客戶端服務發現軟件Eureka和服務端服務發現架構Kubernetes/SkyDNS+Ingress LB+Traefik+PowerDNS為例說明。 | 服務發現方案 | Pros | Cons | | :--------- | ---------------------------------------- | ---------------------------------------- | | Eureka | 使用簡單，適用于java語言開發的項目，比服務端服務發現少一次網絡跳轉 | 對非Java語言的支持不夠好，Consumer需要內置特定的服務發現客戶端和發現邏輯 | | Kubernetes | Consumer無需關注服務發現具體細節，只需知道服務的DNS域名即可，支持異構語言開發 | 需要基礎設施支撐，多了一次網絡跳轉，可能有性能損失 | **Eureka** 也不是單獨使用的，一般會配合 ribbon 一起使用，ribbon 作為路由和負載均衡。 **Ribbon**提供一組豐富的功能集： - 多種內建的負載均衡規則： - Round-robin 輪詢負載均衡 - 平均加權響應時間負載均衡 - 隨機負載均衡 - 可用性過濾負載均衡（避免跳閘線路和高并發鏈接數） - 自定義負載均衡插件系統 - 與服務發現解決方案的可拔插集成（包括Eureka） - 云原生智能，例如可用區親和性和不健康區規避 - 內建的故障恢復能力 ## 參考 - [談服務發現的背景、架構以及落地方案](http://www.infoq.com/cn/articles/background-architecture-and-solutions-of-service-discovery)