作者 | 張羽辰(同昭)

引子——什么是服務(wù)發(fā)現(xiàn)

近日來(lái)，和很多來(lái)自傳統(tǒng)行業(yè)、國(guó)企、政府的客戶在溝通技術(shù)細(xì)節(jié)時(shí)，發(fā)現(xiàn)云原生所代表的技術(shù)已經(jīng)逐漸成為大家的共識(shí)，從一個(gè)虛無(wú)縹緲的概念漸漸變成這些客戶的下一個(gè)技術(shù)戰(zhàn)略。自然，應(yīng)用架構(gòu)就會(huì)提到微服務(wù)，以及其中最重要的分布式協(xié)作的模式——服務(wù)發(fā)現(xiàn)。模式（pattern）是指在特定上下文中的解決方案，很適合描述服務(wù)發(fā)現(xiàn)這個(gè)過(guò)程。不過(guò)相對(duì)于 2016 年，現(xiàn)在我們最少有十多種的方式能實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，這的確是個(gè)好時(shí)機(jī)來(lái)進(jìn)行回顧和展望，最終幫助我們進(jìn)行技術(shù)選型與確定演進(jìn)方向。

微服務(wù)脫胎于 SOA 理論，核心是分布式，但單體應(yīng)用中，模塊之間的調(diào)用（比如讓消息服務(wù)給客戶發(fā)送一條數(shù)據(jù)）是通過(guò)方法，而所發(fā)出的消息是在同一塊內(nèi)存之中，我們知道這樣的代價(jià)是非常小的，方法調(diào)用的成本可能是納秒級(jí)別，我們從未想過(guò)這樣會(huì)有什么問(wèn)題。但是在微服務(wù)的世界中，模塊與模塊分別部署在不同的地方，它們之間的約束或者協(xié)議由方法簽名轉(zhuǎn)變?yōu)楦呒?jí)的協(xié)議，比如 RESTful 、PRC，在這種情況下，調(diào)用一個(gè)模塊就需要通過(guò)網(wǎng)絡(luò)，我們必須要知道目標(biāo)端的網(wǎng)絡(luò)地址與端口，還需要知道所暴露的協(xié)議，然后才能夠編寫(xiě)代碼比如使用 HttpClient 去進(jìn)行調(diào)用，這個(gè)“知道”的過(guò)程，往往被稱為服務(wù)發(fā)現(xiàn)。

分布式的架構(gòu)帶來(lái)了解耦的效果，使得不同模塊可以分別變化，不同的模塊可以根據(jù)自身特點(diǎn)選擇編程語(yǔ)言、技術(shù)棧與數(shù)據(jù)庫(kù)，可以根據(jù)負(fù)載選擇彈性與運(yùn)行環(huán)境，使得系統(tǒng)從傳統(tǒng)的三層架構(gòu)變成了一個(gè)個(gè)獨(dú)立的、自治的服務(wù)，往往這些服務(wù)與業(yè)務(wù)領(lǐng)域非常契合，比如訂單服務(wù)并不會(huì)關(guān)心如何發(fā)送郵件給客戶，司機(jī)管理服務(wù)并不需要關(guān)注乘客的狀態(tài)，這些服務(wù)應(yīng)該是網(wǎng)狀的，是通過(guò)組合來(lái)完成業(yè)務(wù)。解耦帶來(lái)了響應(yīng)變化的能力，可以讓我們大膽試錯(cuò)，我們希望啟動(dòng)一個(gè)服務(wù)的成本和編寫(xiě)一個(gè)模塊的成本類似，同時(shí)編寫(xiě)服務(wù)、進(jìn)行重構(gòu)的成本也需要降低至于代碼修改一般。在這種需求下，我們也希望服務(wù)之間的調(diào)用能夠簡(jiǎn)單，最好能像方法調(diào)用一樣簡(jiǎn)單。

但是 Armon（HashiCorp 的創(chuàng)始人）在他的技術(shù)分享中提到，實(shí)現(xiàn)分布式是沒(méi)有免費(fèi)午餐的，一旦你通過(guò)網(wǎng)絡(luò)進(jìn)行遠(yuǎn)程調(diào)用，那網(wǎng)絡(luò)是否可達(dá)、延遲與帶寬、消息的封裝以及額外的客戶端代碼都是代價(jià)，在此基礎(chǔ)上，有時(shí)候我們還會(huì)有負(fù)載均衡、斷路器、健康檢查、授權(quán)驗(yàn)證、鏈路監(jiān)控等需求，這些問(wèn)題是之前不需要考慮的。所以，我們需要有“產(chǎn)品”來(lái)幫助我們解決這類問(wèn)題，我們可以先從 Eureka 開(kāi)始回顧、整理。

一個(gè)單體應(yīng)用部署在多臺(tái)服務(wù)器中，模塊間通過(guò)方法直接調(diào)用。

分布式的情況下，模塊之間的調(diào)用通過(guò)網(wǎng)絡(luò)，也許使用 HTTP 或者其他 RPC 協(xié)議。

Spring Cloud Eureka

從 Netflix OSS 發(fā)展而來(lái)的 Spring Cloud 依舊是目前最流行的實(shí)現(xiàn)微服務(wù)架構(gòu)的方式，我們很難描述 Spring Cloud 是什么，它是一些獨(dú)立的應(yīng)用程序、特定的依賴與注解、在應(yīng)用層實(shí)現(xiàn)的一攬子的微服務(wù)解決方案。由于是應(yīng)用層解決方案，那就說(shuō)明了 Spring Cloud 很容易與運(yùn)行環(huán)境解耦，雖然限定了編程語(yǔ)言為 Java 但是也可以接受，因?yàn)樵诨ヂ?lián)網(wǎng)領(lǐng)域 Java 占有絕對(duì)的支配地位，特別是在國(guó)內(nèi)。所以服務(wù)發(fā)現(xiàn) Eureka、斷路器 Hystrix、網(wǎng)關(guān) Zuul 與負(fù)載均衡 Ribbon 非常流行直至今日，再加上 Netflix 成功的使用這些技術(shù)構(gòu)建了一個(gè)龐大的分布式系統(tǒng)，這些成功經(jīng)驗(yàn)使得 Spring Cloud 一度是微服務(wù)的代表。

對(duì)于 Eureka 來(lái)說(shuō)，我們知道不論是 Eureka Server 還是 Client 端都存在大量的緩存以及 TTL 機(jī)制，因?yàn)?Eureka 并不傾向于維持系統(tǒng)中服務(wù)狀態(tài)的一致性，雖然我們的 Client 在注冊(cè)服務(wù)時(shí)，Server 會(huì)嘗試將其同步至其他 Server，但是并不能保證一致性。同時(shí)，Client 的下線或者某個(gè)節(jié)點(diǎn)的斷網(wǎng)也是需要有 timeout 來(lái)控制是否移除，并不是實(shí)時(shí)的同步給所有 Server 與 Client。的確，通過(guò)“最大努力的復(fù)制（best effort replication）” 可以讓整個(gè)模型變得簡(jiǎn)單與高可用，我們?cè)谶M(jìn)行 A -> B 的調(diào)用時(shí)，服務(wù) A 只要讀取一個(gè) B 的地址，就可以進(jìn)行 RESTful 請(qǐng)求，如果 B 的這個(gè)地址下線或不可達(dá)，則有 Hystrix 之類的機(jī)制讓我們快速失敗。

對(duì)于 Netflix 來(lái)說(shuō)，這樣的模型是非常合理的，首先服務(wù)與 node 的關(guān)系相對(duì)靜態(tài)，一旦一個(gè)服務(wù)投入使用其使用的虛擬機(jī)（我記得大多是 AWS EC2）也確定下來(lái)，node 的 IP 地址與網(wǎng)絡(luò)也是靜態(tài)，所以很少會(huì)出現(xiàn)頻繁上線、下線的情況，即使在進(jìn)行頻繁迭代時(shí)，也是更新運(yùn)行的 jar，而不會(huì)修改運(yùn)行實(shí)例。國(guó)內(nèi)很多實(shí)現(xiàn)也是類似的，在我們參與的項(xiàng)目中，很多客戶的架構(gòu)圖上總會(huì)清晰的表達(dá)：這幾臺(tái)機(jī)器是 xx 服務(wù)，那幾臺(tái)是 xx 服務(wù)，他們使用 Eureka 注冊(cè)發(fā)現(xiàn)。第二，所有的實(shí)現(xiàn)都是 Java Code，高級(jí)語(yǔ)言雖然在效率上不如系統(tǒng)級(jí)語(yǔ)言，但是易于表達(dá)與修改，使得 Netflix 能夠保持與云環(huán)境、IDC 的距離，并且很多功能通過(guò) annotation 加入，也能讓代碼修改的成本變低。

Eureka 的邏輯架構(gòu)很清楚的表達(dá)了 Eureka Client、Server 之間的關(guān)系，以及他們的 Remote Call 是調(diào)用的。

Eureka 的限制隨著容器的流行被逐漸的放大，我們漸漸的發(fā)現(xiàn) Eureka 在很多場(chǎng)景下并不能滿足我們的需求。首先對(duì)于弱一致性的需求使得我們?cè)谶M(jìn)行彈性伸縮，或者藍(lán)綠發(fā)布時(shí)就會(huì)出現(xiàn)一定的錯(cuò)誤，因?yàn)楣?jié)點(diǎn)下線的消息是需要時(shí)間才能同步的。在容器時(shí)代，我們希望應(yīng)用程序是無(wú)狀態(tài)的，可以優(yōu)雅的啟動(dòng)和終止，并且易于橫向擴(kuò)展。由于容器提供了很好的封裝能力，至于內(nèi)部的代碼是 Java 還是 Golang 并不是調(diào)用者關(guān)心的事情，這就帶來(lái)了第二個(gè)問(wèn)題，雖然使用 Java annotation 的方式方便使用，但是必須是 Java 語(yǔ)言而且需要一大堆 SDK，很多例如負(fù)載均衡的能力無(wú)法做到進(jìn)程之外。Eureka 會(huì)讓系統(tǒng)變得很復(fù)雜，如果你有十幾個(gè)微服務(wù)，每個(gè)微服務(wù)都有四五個(gè)節(jié)點(diǎn)，那維護(hù)這么多節(jié)點(diǎn)的地址就顯得非常臃腫，對(duì)于調(diào)用者來(lái)說(shuō)它只需要關(guān)注自己所依賴的服務(wù)。

Hashicorp Consul

Consul 作為繼任者解決了很多問(wèn)題，首先 Consul 使用了現(xiàn)在流行的 service mesh 模式，在一個(gè)“控制面”中提供了服務(wù)發(fā)現(xiàn)、配置管理與劃分等能力，與 Netflix OSS 套件一樣，任何的這些功能都是可以獨(dú)立使用的，也可以組合在一起去構(gòu)建我們自己的 service mesh 實(shí)現(xiàn)。Service mesh 作為實(shí)現(xiàn)微服務(wù)架構(gòu)的新模式，核心思想在于進(jìn)程之外 out-of-process 的實(shí)現(xiàn)功能，也就是 sidecar，我們可以通過(guò) proxy 實(shí)現(xiàn) interceptor 在不改變代碼的情況下注入某些功能，比如服務(wù)注冊(cè)發(fā)現(xiàn)、比如日志記錄、比如服務(wù)之間的授信。

Consul 的架構(gòu)更為全面并復(fù)雜，支持多 Data Center，使用了 GOSSIP 協(xié)議，有 Control Panel 提供 Mesh 能力，基本上解決為了 Eureka 的問(wèn)題。

與 Eureka 不同，Consul 通過(guò) Raft 協(xié)議提供了強(qiáng)一致性，支持各種類型的 health check，而且這些 health check 也是分布式的，也不需要使用大量的 SDK 來(lái)在代碼中集成這些功能。由于 Consul 代理了流量，所以可以支持傳輸安全 TLS，在架構(gòu)設(shè)計(jì)上 Consul 與 Istio 還是有所類似，但是的確還是有如下的不足：

• 沒(méi)有提供 native 的方式去配置 circuit breaker，Netflix OSS suite 最大的優(yōu)勢(shì)是，Eureka\Hystrix\Ribbon 能夠提供完整的分布式解決方案，特別是 Hystrix，能夠提供“快速失敗”的能力，但是 Consul 的話，目前還沒(méi)有提供原生的方案。
• 同樣的，集成 Consul 也變得比較麻煩，agent 的啟動(dòng)不是那么簡(jiǎn)單，特別是在 k8s 上我們需要多級(jí) sidecar 時(shí)，同時(shí)其提供的 ACL 配置也難以理解和使用。相對(duì)于內(nèi)部的實(shí)現(xiàn)，管控用的 GUI 界面也是大家吐槽比較多的地方。
• 相對(duì)于服務(wù)發(fā)現(xiàn)，其他 Consul 所提供的功能就顯得不那么誘人了，比如 Key-Value 數(shù)據(jù)庫(kù)以及多數(shù)據(jù)中心支持，當(dāng)然我認(rèn)為這也不是核心內(nèi)容。
• 政治因素，雖然是開(kāi)源產(chǎn)品，但是其公司也參與了對(duì)中國(guó)企業(yè)的制裁，所以在國(guó)內(nèi)是無(wú)法合法使用該產(chǎn)品的。

Alibaba Nacos

Nacos 已經(jīng)是目前項(xiàng)目中的首選，特別是那些急需 Eureka 替代品的場(chǎng)景下，當(dāng)然這不是因?yàn)槲覀儫o(wú)法使用 Consul，更多的是因?yàn)?Nacos 已經(jīng)成為了穩(wěn)定的云產(chǎn)品，你無(wú)需自己部署、運(yùn)維、管控一個(gè) Consul 或者別的機(jī)制，直接使用 Nacos 即可。

而且 Nacos 替代 Eureka 基本上是一行代碼的事情，某些時(shí)候客戶并沒(méi)有足夠的預(yù)算和成本投入微服務(wù)的改造與升級(jí)，所以在進(jìn)行微服務(wù)上云的過(guò)程中，Nacos 是目前的首選。相對(duì)于 Consul 自己發(fā)明輪子的做法，Nacos 在協(xié)議的支持更全面，包括 Dubbo 與 gRPC，這對(duì)于廣泛使用 Dubbo 的國(guó)內(nèi)企業(yè)是一個(gè)巨大的優(yōu)勢(shì)。

在這里筆者就不擴(kuò)展 Nacos 的功能與內(nèi)部實(shí)現(xiàn)了，Nacos 團(tuán)隊(duì)所做的科普、示例以及深度的文章都已經(jīng)足夠多了，已經(jīng)所有的文檔都可以在官網(wǎng)找到，代碼也開(kāi)源，有興趣的話請(qǐng)大家移步 Nacos 團(tuán)隊(duì)的博客：https://nacos.io/zh-cn/blog/index.html

SLB、Kubernetes Service 與 Istio

實(shí)際上，我們剛才提到的“服務(wù)發(fā)現(xiàn)”是“客戶端的服務(wù)發(fā)現(xiàn)（client-side service discovery）”，假設(shè)訂單系統(tǒng)運(yùn)行在四個(gè)節(jié)點(diǎn)上，每個(gè)節(jié)點(diǎn)有不同的 IP 地址，那我們的調(diào)用者在發(fā)起 RPC 或者 HTTP 請(qǐng)求前，是必須要清楚到底要調(diào)用個(gè)節(jié)點(diǎn)的，在 Eureka 的過(guò)程中，我們會(huì)通過(guò) Ribbon 使用輪詢或者其他方式找到那個(gè)地址與端口，并且發(fā)起請(qǐng)求。

這個(gè)過(guò)程是非常直接的，作為調(diào)用者，我有所有可用服務(wù)的列表，所以我可以很靈活的決定我該調(diào)用誰(shuí)，我可以簡(jiǎn)單的實(shí)現(xiàn)斷路器。但是缺點(diǎn)的話也很清楚，我們必須依賴 SDK，如果是不同的編程語(yǔ)言或框架，我們就必須要編寫(xiě)自己的實(shí)現(xiàn)。

像蜘蛛網(wǎng)一樣的互相調(diào)用過(guò)程，并且每個(gè)服務(wù)都必須有 SDK 來(lái)實(shí)現(xiàn)客戶端的服務(wù)發(fā)現(xiàn)，比如 IP3 這臺(tái)機(jī)器，是由它來(lái)決定最終訪問(wèn) Service 2 的那個(gè)節(jié)點(diǎn)。同時(shí)，IP23 剛剛上線，但是還沒(méi)有流量過(guò)來(lái)。

但是在邏輯架構(gòu)上，這個(gè)系統(tǒng)又非常簡(jiǎn)單，serivce 1 -> service 2 -> service 3\4。對(duì)于研發(fā)或者運(yùn)維人員，你是希望 order service 是這樣描述：

https://internal.order-service.some-company.com:8443/ - online

還是，這樣一大堆地址，并且不確定的狀態(tài)？

http://192.168.20.19:8080 ?- online
http://192.168.20.20:8080 - online
http://192.168.20.21:8080 - offline
http://192.168.20.22:8080 - offline

事實(shí)上斷路器所提供的快速失敗在客戶端的服務(wù)發(fā)現(xiàn)中非常重要，但是這個(gè)功能并不完美，我們想要的場(chǎng)景是調(diào)用的服務(wù)都是可用的，而不是等調(diào)用鏈路走到個(gè)節(jié)點(diǎn)后再快速失敗，而這時(shí)候另一個(gè)節(jié)點(diǎn)是可以提供服務(wù)的。

而且對(duì)于一個(gè)訂單服務(wù)，在外來(lái)看它就應(yīng)該是“一個(gè)服務(wù)”，它內(nèi)部的幾個(gè)節(jié)點(diǎn)是否可用并不是調(diào)用者需要關(guān)心的，這些細(xì)節(jié)我們并不想關(guān)心。

在微服務(wù)世界，我們很希望每個(gè)服務(wù)都是獨(dú)立且完整的，就像面向?qū)ο缶幊桃粯?#xff0c;細(xì)節(jié)應(yīng)該被隱藏到模塊內(nèi)部。按照這種想法，服務(wù)端的服務(wù)發(fā)現(xiàn)（server-side serivce discovery）會(huì)更具有優(yōu)勢(shì)，其實(shí)我們對(duì)這種模式并不陌生，在使用 NGINX 進(jìn)行負(fù)載均衡的代理時(shí)，我們就在實(shí)踐這種模式，一旦流量到了 proxy，由 proxy 決定下發(fā)至哪個(gè)節(jié)點(diǎn)，而 proxy 可以通過(guò) healthcheck 來(lái)判斷哪個(gè)節(jié)點(diǎn)是否健康。

邏輯上還是 serivce 1 -> service 2 -> service 3\4，但是 LB 或者 Service 幫助我們隱藏了細(xì)節(jié)，從 Service 1 看 Service 2，就只能看到一個(gè)服務(wù)，而不是一堆機(jī)器。

服務(wù)端服務(wù)發(fā)現(xiàn)的確有很多優(yōu)勢(shì)，比如隱藏細(xì)節(jié)，讓客戶端無(wú)需關(guān)心最終提供服務(wù)的節(jié)點(diǎn)，同時(shí)也消除了語(yǔ)言與框架的限制。缺點(diǎn)也很明顯，每個(gè)服務(wù)都有這一層代理，而且如果你的平臺(tái)不提供這樣的能力的話，自己手動(dòng)去部署與管理高可用的 proxy 組件，成本是巨大的。但是這個(gè)缺陷已經(jīng)有很好的應(yīng)對(duì)，你可以使用阿里云的 SLB 實(shí)現(xiàn)，不論 client 使用 HTTP 還是 PRC 都可以通過(guò) DNS 名稱來(lái)訪問(wèn) SLB，甚至實(shí)現(xiàn)全鏈路 TLS 也非常簡(jiǎn)單，而 SLB 可以管理多個(gè) ECS 實(shí)例，也支持實(shí)例的 health check 與彈性，這就像一個(gè)注冊(cè)中心一樣，每個(gè)實(shí)例的狀態(tài)實(shí)際上保存在 SLB 之上。云平臺(tái)本身就是利于管控和使用，加入更多的比如驗(yàn)證、限流等能力。

Kubernetes Service 也具有同樣的能力，隨著容器化的逐漸成熟，在云原生的落地中 ACK 是必不可少的運(yùn)行環(huán)境，那通過(guò) Service 去綜合管理一組服務(wù)的 pod 與之前提到的 SLB 的方式是一致的，當(dāng)然相對(duì)于平臺(tái)綁定的 SLB + ECS 方案，k8s 的 service 更加開(kāi)放與透明，也支持者企業(yè)進(jìn)行混合云的落地。

作為 service mesh 目前最流行的產(chǎn)品，Istio 使用了 virtual service 與 destination rule 來(lái)解決了服務(wù)注冊(cè)與發(fā)現(xiàn)的問(wèn)題，virtual service 與其他 proxy 一樣，都非常強(qiáng)調(diào)與客戶端的解耦，除了我們?nèi)粘Ｊ褂玫妮喸兪降恼{(diào)用方式，virtual service 可以提供更靈活的流量控制，比如“20% 的流量去新版本”或者“來(lái)自某個(gè)地區(qū)的用戶使用版本 2”，實(shí)現(xiàn)金絲雀發(fā)布也比較簡(jiǎn)單。相對(duì)于 kubernetes serivce, virtual service 可控制的地方更多，比如通過(guò) destination rule 可控制下游，也可以實(shí)現(xiàn)根據(jù)路徑匹配選擇下游服務(wù)，也可以加入權(quán)重，重試策略等等。你同樣可以通過(guò) Istio 的能力實(shí)現(xiàn)服務(wù)間的傳輸安全，比如全鏈路的 TLS，也可以做到細(xì)粒度的服務(wù)授權(quán)，而這所有的一切都是不需要寫(xiě)入業(yè)務(wù)代碼中的，只要進(jìn)行一些配置就好。但是這也不是免費(fèi)的，隨著服務(wù)數(shù)量的上升，手動(dòng)的管理這么多的 proxy 與 sidecar，沒(méi)有自動(dòng)化的報(bào)警和響應(yīng)手段，都會(huì)造成效率的下降。

ZooKeeper 真的不適合做注冊(cè)發(fā)現(xiàn)嗎？

在微服務(wù)剛剛開(kāi)始流行的時(shí)候，很多企業(yè)在探索的過(guò)程中開(kāi)始使用 ZooKeeper 進(jìn)行服務(wù)發(fā)現(xiàn)的實(shí)現(xiàn)，一方面是 ZooKeeper 的可靠、簡(jiǎn)單、天然分布式的優(yōu)勢(shì)可以說(shuō)是直接的選擇，另一方面也是因?yàn)闆](méi)有其他的機(jī)制讓我們模仿。下面這篇發(fā)布于 2014 年底的文章詳細(xì)的說(shuō)明了為什么在服務(wù)發(fā)現(xiàn)中，使用 Eureka 會(huì)是一個(gè)更好的解決方案。

https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764

在 CAP 理論中，ZooKeeper 是面向 CP 的，在可用性（available）與一致性（consistent）中，ZooKeeper 選擇了一致性，這是因?yàn)?ZooKeeper 最開(kāi)始用于進(jìn)行分布式的系統(tǒng)管理與協(xié)調(diào)（coordination），比如控制大數(shù)據(jù)的集群或者 kafka 之類的，一致性在這類系統(tǒng)中是紅線。文章還提到了“如果我們自己為 ZooKeeper 加上一種客戶端緩存的能力，緩存了其他服務(wù)地址的話，這樣就能緩解在集群不可用時(shí)，依舊可以進(jìn)行服務(wù)發(fā)現(xiàn)的能力，并且 Pinterest 與 Airbnb 都有類似的實(shí)現(xiàn)”，的確，看起來(lái)這樣是修復(fù)了問(wèn)題，但是在原理上和 Eureka 這種 AP 型的系統(tǒng)就沒(méi)有多少區(qū)別了，使用了 Cache 就必須要在一致性上進(jìn)行妥協(xié)，必須要自己的實(shí)現(xiàn)才能緩存失效、無(wú)法同步等問(wèn)題。

使用 ZooKeeper 實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)并沒(méi)有什么問(wèn)題，問(wèn)題是使用者必須要想清楚在這樣一個(gè)分布式系統(tǒng)中，AP 還是 CP 是最終的目標(biāo)，如果我們的系統(tǒng)是在劇烈變化，面向終端消費(fèi)者，但是又沒(méi)有交易或者對(duì)一致性要求不高，那這種情況下 AP 是較為理想的選擇，如果是一個(gè)交易系統(tǒng)，一致性顯然更重要。其實(shí)實(shí)現(xiàn)一個(gè)自己的服務(wù)發(fā)現(xiàn)并沒(méi)有大多數(shù)人想的那么難，如果有一個(gè) KV Store 去存儲(chǔ)服務(wù)的狀態(tài)，再加上注冊(cè)、更新等機(jī)制，這也是很多服務(wù)注冊(cè)與發(fā)現(xiàn)和配置管理經(jīng)常做在一起的原因，剩下的事情就是 AP 與 CP 的選擇了，下面這篇文章是一個(gè)很好的例子，也提到了其他的服務(wù)發(fā)現(xiàn)，請(qǐng)查閱。

https://dzone.com/articles/zookeeper-for-microservice-registration-and-discov

一些思考

進(jìn)行技術(shù)選型的壓力是非常之大的，隨著技術(shù)的演進(jìn)、人員的更替，很多系統(tǒng)逐漸變成了無(wú)法修改、無(wú)法移動(dòng)的存在，作為技術(shù)負(fù)責(zé)人我們?cè)谶M(jìn)行這件工作時(shí)應(yīng)該更加注意，選擇某項(xiàng)技術(shù)時(shí)也需要考慮自己能否負(fù)擔(dān)的起。Spring Cloud 提供的微服務(wù)方案在易用性上肯定好于自己在 Kubernetes 上發(fā)明新的，但是我們也擔(dān)心它尾大不掉，所以在我們現(xiàn)在接觸的項(xiàng)目中，對(duì) Spring Cloud 上的應(yīng)用進(jìn)行遷移、重構(gòu)還是可以負(fù)擔(dān)的起的，但我非常擔(dān)心幾年后，改造的成本就會(huì)變的非常高，最終導(dǎo)向重寫(xiě)的境地。

我們將調(diào)用方式分為“同步”與“異步”兩種情況，在異步調(diào)用時(shí)，使用 MQ 傳輸事件，或者使用 Kafka 進(jìn)行 Pub / Sub，事實(shí)上，Event Driven 的系統(tǒng)更有靈活性，也符合 Domain 的封閉。

服務(wù)與服務(wù)之前的調(diào)用不僅僅是同步式的，別忘了在異步調(diào)用或者 pub-sub 的場(chǎng)景，我們會(huì)使用中間件幫助我們解耦。雖然中間件（middleware）這個(gè)詞很容易讓人產(chǎn)生困惑，它并不能很好的描述它的功能，但最少在實(shí)現(xiàn)消息隊(duì)里、Event Bus、Stream 這種需求時(shí)，現(xiàn)在已有的產(chǎn)品已經(jīng)非常成熟，我們?cè)?jīng)使用 Serverless 實(shí)現(xiàn)了一個(gè)完整的 web service，其中模塊的互相調(diào)用就是通過(guò)事件。但是這并不是完美的，“如無(wú)必要，勿增實(shí)體”，加入了額外的系統(tǒng)或者應(yīng)用就得去運(yùn)維與管理，就需要考慮失效，考慮 failure 策略，同時(shí)在這種場(chǎng)景下實(shí)現(xiàn)“exactly once”的目標(biāo)更為復(fù)雜，果然在分布式的世界中，真是沒(méi)有一口飯是免費(fèi)的。

參考

https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance
https://www.consul.io/docs/architecture
https://dzone.com/articles/zookeeper-for-microservice-registration-and-discov
https://medium.com/knerd/eureka-why-you-shouldnt-use-zookeeper-for-service-discovery-4932c5c7e764
https://istio.io/latest/docs/concepts/traffic-management/#why-use-virtual-services
https://microservices.io/patterns/server-side-discovery.html

作者簡(jiǎn)介

**張羽辰（同昭）**阿里云交付專家，有著近十年研發(fā)經(jīng)驗(yàn)，是一名軟件工程師、架構(gòu)師、咨詢師，從 2016 年開(kāi)始采用容器化、微服務(wù)、Serverless 等技術(shù)進(jìn)行云時(shí)代的應(yīng)用開(kāi)發(fā)。同時(shí)也關(guān)注在分布式應(yīng)用中的安全治理問(wèn)題，整理《微服務(wù)安全手冊(cè)》，對(duì)數(shù)據(jù)、應(yīng)用、身份安全都有一定的研究。

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的服务发现技术选型那点事儿的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。