?

1.為什么要服務發現【https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/】

?

2.選型

3.業界使用【http://www.infoq.com/cn/articles/background-architecture-and-solutions-of-service-discovery】

DNS可以算是最為原始的服務發現系統，但是在服務變更較為頻繁，即服務的動態性很強的時候，DNS記錄的傳播速度可能會跟不上服務的變更速度，這將導致在一定的時間窗口內無法提供正確的服務位置信息，所以這種方案只適合在比較靜態的環境中使用，不適用于微服務。

基于ZooKeeper、Etcd等分布式鍵值對存儲服務來建立服務發現系統在現在看起來也不是一種很好的方案，一方面是因為它們只能提供基本的數據存儲功能，還需要在外圍做大量的開發才能形成完整的服務發現方案。另一方面是因為它們都是強一致性系統，在集群發生分區時會優先保證一致性、放棄可用性，而服務發現方案更注重可用性，為了保證可用性可以選擇最終一致性，這兩方面原因共同導致了ZooKeeper、Etcd這類系統越來越遠離服務發現方案的備選清單，像SmartStack這種依賴ZooKeeper的服務發現方案也逐漸發覺ZooKeeper成了它的薄弱環節。

Netflix的Eureka是現在最流行的服務發現方案，服務端和客戶端都是Java編寫的，針對微服務場景，并且和Netflix的其他開源項目以及Spring Cloud都有著非常好的整合，具備良好的生態，如果你使用Java語言開發，Eureka幾乎是你的最佳選擇。與ZooKeeper、Etcd或者依賴它們的方案不同，Eureka是個專門為服務發現從零開始開發的項目，Eureka以可用性為先，可以在多種故障期間保持服務發現和服務注冊功能可用，雖然此時會存在一些數據錯誤，但是Eureka的設計原則是“存在少量的錯誤數據，總比完全不可用要好”，并且可以在故障恢復之后按最終一致性進行狀態合并，清理掉錯誤數據。

前面為什么說Eureka“幾乎是”最佳選擇，因為它還有個強大的對手Consul。Consul是HashiCorp公司的商業產品，它有一個開源的基礎版本，這個版本在基本的服務發現功能之外，還提供了多數據中心部署能力，包括內存、存儲使用情況在內的細粒度服務狀態檢測能力，和用于服務配置的鍵值對存儲能力（這是一把雙刃劍，使用它可以帶來便捷，但是也意味著和Consul的較強耦合性），這幾個能力Eureka目前都沒有。而Consul的商業版本功能更為強大，如果你不介意依賴單一公司提供的商業產品，也可以從Consul的開源版本開始用起。

最后還有一個比較有趣的方案是SkyDNS，這是一個結合古老的DNS技術和時髦的Go語言、Raft算法的有趣項目，主要在Kubernetes里使用，因為Kubernetes有一層較為穩定的Service抽象，有點類似于問題2里描述的服務端服務發現方式，所以不存在DNS時間窗口的問題。

這里我就不對上述的各個方案做具體功能特性上的對比了，我在做方案選型時不太喜歡做這種微觀對比，因為具體的功能特性是易變的，今天Consul出一個新功能，明天Eureka出一個新特性，如果依賴這個做選擇，會搖擺不定，我更注重這些方案背后的一些根深蒂固的必然性，比如ZooKeeper永遠都不會為了服務發現放棄它的強一致性，所以即使它有再多適合服務發現的功能特性，它也不會成為服務發現的優選方案，再比如Consul由一家商業軟件公司提供，那么必然或多或少的存在商業軟件的某些弊端，如果你非常在意這些弊端，Consul再強大，你也不會選擇它。

?

轉載于:https://www.cnblogs.com/davidwang456/p/9250493.html

總結

以上是生活随笔為你收集整理的微服务实践分享(3)服务发现的全部內容，希望文章能夠幫你解決所遇到的問題。

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