微服务实践分享(3)服务发现
?
1.為什么要服務(wù)發(fā)現(xiàn)【https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/】
?
2.選型
3.業(yè)界使用【http://www.infoq.com/cn/articles/background-architecture-and-solutions-of-service-discovery】
DNS可以算是最為原始的服務(wù)發(fā)現(xiàn)系統(tǒng),但是在服務(wù)變更較為頻繁,即服務(wù)的動(dòng)態(tài)性很強(qiáng)的時(shí)候,DNS記錄的傳播速度可能會(huì)跟不上服務(wù)的變更速度,這將導(dǎo)致在一定的時(shí)間窗口內(nèi)無法提供正確的服務(wù)位置信息,所以這種方案只適合在比較靜態(tài)的環(huán)境中使用,不適用于微服務(wù)。
基于ZooKeeper、Etcd等分布式鍵值對(duì)存儲(chǔ)服務(wù)來建立服務(wù)發(fā)現(xiàn)系統(tǒng)在現(xiàn)在看起來也不是一種很好的方案,一方面是因?yàn)樗鼈冎荒芴峁┗镜臄?shù)據(jù)存儲(chǔ)功能,還需要在外圍做大量的開發(fā)才能形成完整的服務(wù)發(fā)現(xiàn)方案。另一方面是因?yàn)樗鼈兌际菑?qiáng)一致性系統(tǒng),在集群發(fā)生分區(qū)時(shí)會(huì)優(yōu)先保證一致性、放棄可用性,而服務(wù)發(fā)現(xiàn)方案更注重可用性,為了保證可用性可以選擇最終一致性,這兩方面原因共同導(dǎo)致了ZooKeeper、Etcd這類系統(tǒng)越來越遠(yuǎn)離服務(wù)發(fā)現(xiàn)方案的備選清單,像SmartStack這種依賴ZooKeeper的服務(wù)發(fā)現(xiàn)方案也逐漸發(fā)覺ZooKeeper成了它的薄弱環(huán)節(jié)。
Netflix的Eureka是現(xiàn)在最流行的服務(wù)發(fā)現(xiàn)方案,服務(wù)端和客戶端都是Java編寫的,針對(duì)微服務(wù)場景,并且和Netflix的其他開源項(xiàng)目以及Spring Cloud都有著非常好的整合,具備良好的生態(tài),如果你使用Java語言開發(fā),Eureka幾乎是你的最佳選擇。與ZooKeeper、Etcd或者依賴它們的方案不同,Eureka是個(gè)專門為服務(wù)發(fā)現(xiàn)從零開始開發(fā)的項(xiàng)目,Eureka以可用性為先,可以在多種故障期間保持服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)功能可用,雖然此時(shí)會(huì)存在一些數(shù)據(jù)錯(cuò)誤,但是Eureka的設(shè)計(jì)原則是“存在少量的錯(cuò)誤數(shù)據(jù),總比完全不可用要好”,并且可以在故障恢復(fù)之后按最終一致性進(jìn)行狀態(tài)合并,清理掉錯(cuò)誤數(shù)據(jù)。
前面為什么說Eureka“幾乎是”最佳選擇,因?yàn)樗€有個(gè)強(qiáng)大的對(duì)手Consul。Consul是HashiCorp公司的商業(yè)產(chǎn)品,它有一個(gè)開源的基礎(chǔ)版本,這個(gè)版本在基本的服務(wù)發(fā)現(xiàn)功能之外,還提供了多數(shù)據(jù)中心部署能力,包括內(nèi)存、存儲(chǔ)使用情況在內(nèi)的細(xì)粒度服務(wù)狀態(tài)檢測能力,和用于服務(wù)配置的鍵值對(duì)存儲(chǔ)能力(這是一把雙刃劍,使用它可以帶來便捷,但是也意味著和Consul的較強(qiáng)耦合性),這幾個(gè)能力Eureka目前都沒有。而Consul的商業(yè)版本功能更為強(qiáng)大,如果你不介意依賴單一公司提供的商業(yè)產(chǎn)品,也可以從Consul的開源版本開始用起。
最后還有一個(gè)比較有趣的方案是SkyDNS,這是一個(gè)結(jié)合古老的DNS技術(shù)和時(shí)髦的Go語言、Raft算法的有趣項(xiàng)目,主要在Kubernetes里使用,因?yàn)镵ubernetes有一層較為穩(wěn)定的Service抽象,有點(diǎn)類似于問題2里描述的服務(wù)端服務(wù)發(fā)現(xiàn)方式,所以不存在DNS時(shí)間窗口的問題。
這里我就不對(duì)上述的各個(gè)方案做具體功能特性上的對(duì)比了,我在做方案選型時(shí)不太喜歡做這種微觀對(duì)比,因?yàn)榫唧w的功能特性是易變的,今天Consul出一個(gè)新功能,明天Eureka出一個(gè)新特性,如果依賴這個(gè)做選擇,會(huì)搖擺不定,我更注重這些方案背后的一些根深蒂固的必然性,比如ZooKeeper永遠(yuǎn)都不會(huì)為了服務(wù)發(fā)現(xiàn)放棄它的強(qiáng)一致性,所以即使它有再多適合服務(wù)發(fā)現(xiàn)的功能特性,它也不會(huì)成為服務(wù)發(fā)現(xiàn)的優(yōu)選方案,再比如Consul由一家商業(yè)軟件公司提供,那么必然或多或少的存在商業(yè)軟件的某些弊端,如果你非常在意這些弊端,Consul再強(qiáng)大,你也不會(huì)選擇它。
?
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/p/9250493.html
總結(jié)
以上是生活随笔為你收集整理的微服务实践分享(3)服务发现的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 微服务实践分享(2)api网关
- 下一篇: 谈服务发现的背景、架构以及落地方案