詳解微服務(wù)架構(gòu)及其演進(jìn)史

微服務(wù)全景架構(gòu)全面瓦解

微服務(wù)架構(gòu)拆分策略詳解

微服務(wù)的注冊(cè)與發(fā)現(xiàn)

我們前面在全景架構(gòu)中對(duì)服務(wù)注冊(cè)與發(fā)現(xiàn)做了大致的說明，本章我們著重詳細(xì)說明微服務(wù)下注冊(cè)與發(fā)現(xiàn)的這個(gè)能力。

微服務(wù)注冊(cè)與發(fā)現(xiàn)類似于生活中的"電話通訊錄"的概念，它記錄了通訊錄服務(wù)和電話的映射關(guān)系。在分布式架構(gòu)中，服務(wù)會(huì)注冊(cè)進(jìn)去，當(dāng)服務(wù)需要調(diào)用其它服務(wù)時(shí)，就這里找到服務(wù)的地址，進(jìn)行調(diào)用。

步驟如下：

• 1、你先要把"好友某某"記錄在通訊錄中。
• 2、撥打電話的時(shí)候通過通訊錄中找到"好友某某"，并撥通回電話。
• 3、當(dāng)好友某某電話號(hào)碼更新的時(shí)候，需要通知到你，并修改通訊錄服務(wù)中的號(hào)碼。

從這個(gè)過程中我們看到了一些特點(diǎn)：

• 1、把 "好友某某" 的電話號(hào)碼寫入通訊錄中，統(tǒng)一在通訊錄中維護(hù)，后續(xù)號(hào)碼變更也是更新到通訊錄中，這個(gè)過程就是服務(wù)注冊(cè)的過程。
• 2、后續(xù)我們通過"好友某某"就可以定位到通訊錄中的電話號(hào)碼，并撥通電話，這個(gè)過程理解為服務(wù)發(fā)現(xiàn)的過程。

而我們微服務(wù)架構(gòu)中的服務(wù)注冊(cè)與發(fā)現(xiàn)結(jié)構(gòu)如下圖所示：

圖片中是一個(gè)典型的微服務(wù)架構(gòu)，這個(gè)結(jié)構(gòu)中主要涉及到三大角色：

• provider - 服務(wù)提供者
• consumer - 服務(wù)消費(fèi)者
• register center - 注冊(cè)中心

它們之間的關(guān)系大致如下：

1. 1、每個(gè)微服務(wù)在啟動(dòng)時(shí)，將自己的網(wǎng)絡(luò)地址等信息（微服務(wù)的ServiceName、IP、Port、MetaData等）注冊(cè)到注冊(cè)中心，注冊(cè)中心存儲(chǔ)這些數(shù)據(jù)。
2. 2、服務(wù)消費(fèi)者從注冊(cè)中心查詢服務(wù)提供者的地址，并通過該地址調(diào)用服務(wù)提供者的接口。
3. 3、各個(gè)微服務(wù)與注冊(cè)中心使用一定機(jī)制（例如心跳）通信。如果注冊(cè)中心與某微服務(wù)長(zhǎng)時(shí)間無法通信，就會(huì)注銷該實(shí)例。

優(yōu)點(diǎn)如下：

1. 1、解耦：服務(wù)消費(fèi)者跟服務(wù)提供者解耦，各自變化，不互相影響
2. 2、擴(kuò)展：服務(wù)消費(fèi)者和服務(wù)提供者增加和刪除新的服務(wù)，對(duì)于雙方?jīng)]有任何影響
3. 3、中介者設(shè)計(jì)模式：用一個(gè)中介對(duì)象來封裝一系列的對(duì)象交互，這是一種多對(duì)多關(guān)系的中介者模式。

從功能上拆開主要有三塊：服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)，和注冊(cè)中心。我們一個(gè)一個(gè)來看。

1、服務(wù)注冊(cè)

如圖中，為Register注冊(cè)中心注冊(cè)一個(gè)服務(wù)信息，會(huì)將服務(wù)的信息：ServiceName、IP、Port以及服務(wù)實(shí)例MetaData元數(shù)據(jù)信息寫入到注冊(cè)中心。當(dāng)服務(wù)發(fā)生變化的時(shí)候，也可以更新到注冊(cè)中心。

服務(wù)提供者（服務(wù)實(shí)例） 的服務(wù)注冊(cè)模型是一種簡(jiǎn)單、容易理解、流行的服務(wù)注冊(cè)模型，其在多種技術(shù)生態(tài)中都有所體現(xiàn)：

1. 1、在K8S生態(tài)中，通過 K8S Service服務(wù)信息，和Pod的 endpoint（用來記錄service對(duì)應(yīng)的pod的訪問地址）來進(jìn)行注冊(cè)。
2. 2、在Spring Cloud生態(tài)中，應(yīng)用名 對(duì)應(yīng) 服務(wù)Service，實(shí)例 IP + Port 對(duì)應(yīng) Instance實(shí)例。比較典型的就是A服務(wù)，后面對(duì)應(yīng)有多個(gè)實(shí)例做負(fù)載均衡。 
3. 3、在其他的注冊(cè)組件中，比如 Eureka、Consul，服務(wù)模型也都是 服務(wù)→ 服務(wù)實(shí)例。

可以認(rèn)為服務(wù)實(shí)例是一個(gè)真正的實(shí)體的載體，服務(wù)是對(duì)這些相同能力或者相同功能服務(wù)實(shí)例的一個(gè)抽象。

2、服務(wù)發(fā)現(xiàn)

服務(wù)發(fā)現(xiàn)實(shí)際就是我們查詢已經(jīng)注冊(cè)好的服務(wù)提供者，比如 p->p.queryService(serviceName)，通過服務(wù)名稱查詢某個(gè)服務(wù)是否存在，如果存在，

返回它的所有實(shí)例信息，即一組包含ip 、 port 、metadata元數(shù)據(jù)信息的endpoints信息。

這一組endpoints信息一般會(huì)被緩存在本地，如果注冊(cè)中心掛掉，可保證段時(shí)間內(nèi)依舊可用，這是去中心化的做法。對(duì)于單個(gè) Service 后面有多個(gè) Instance的情況（如上圖），做 load balance。

服務(wù)發(fā)現(xiàn)的方式一般有兩種：

1、拉取的方式：服務(wù)消費(fèi)方（Consumer）主動(dòng)向注冊(cè)中心發(fā)起服務(wù)查詢的請(qǐng)求。

2、推送的方式：服務(wù)訂閱/通知變更（下發(fā)）：服務(wù)消費(fèi)方（Consumer）主動(dòng)向注冊(cè)中心訂閱某個(gè)服務(wù)，當(dāng)注冊(cè)中心中該服務(wù)信息發(fā)生變更時(shí)，注冊(cè)中心主動(dòng)通知消費(fèi)者。 

3、注冊(cè)中心

注冊(cè)中心提供的基本能力包括：提供服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn) 以及 健康檢查。

服務(wù)注冊(cè)跟服務(wù)發(fā)現(xiàn)上面已經(jīng)詳細(xì)介紹了， 健康檢查指的是指注冊(cè)中心能夠感知到微服務(wù)實(shí)例的健康狀況，便于上游微服務(wù)實(shí)例及時(shí)發(fā)現(xiàn)下游微服務(wù)實(shí)例的健康狀況。采取必備的訪問措施，如避免訪問不健康的實(shí)例。

主要的檢查方式包括：

1. 1、服務(wù)Provider 進(jìn)行 TTL 健康匯報(bào)（Time To Live，微服務(wù)Provider定期向注冊(cè)中心匯報(bào)健康狀態(tài)）。
2. 2、注冊(cè)中心主動(dòng)檢查服務(wù)Provider接口。

綜合我們前面的內(nèi)容，可以總結(jié)下注冊(cè)中心有如下幾種能力：

1、高可用

這個(gè)主要體現(xiàn)在兩個(gè)方面。一個(gè)方面是，注冊(cè)中心本身作為基礎(chǔ)設(shè)施層，具備高可用；第二種是就是前面我們說到的去中心化，極端情況下的故障，短時(shí)間內(nèi)是不影響微服務(wù)應(yīng)用的調(diào)用的

2、可視化操作

常用的注冊(cè)中心，類似 Eureka、Consul 都有比較豐富的管理界面，對(duì)配置、服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)進(jìn)行可視化管理。

3、高效運(yùn)維

注冊(cè)中心的文檔豐富，對(duì)運(yùn)維的支持比較好，并且對(duì)于服務(wù)的注冊(cè)是動(dòng)態(tài)感知獲取的，方便動(dòng)態(tài)擴(kuò)容。

4、權(quán)限控制

數(shù)據(jù)是具有敏感性，無論是服務(wù)信息注冊(cè)或服務(wù)是調(diào)用，需要具備權(quán)限控制能力，避免侵入或越權(quán)請(qǐng)求

5、服務(wù)注冊(cè)推、拉能力

這個(gè)前面說過了，微服務(wù)應(yīng)用程序（服務(wù)的Consumer），能夠快速感知到服務(wù)實(shí)例的變化情況，使用拉取或者注冊(cè)中心下發(fā)的方式進(jìn)行處理。 

4、現(xiàn)下的主流注冊(cè)中心

4.1 Eureka

4.1.1 介紹

Eureka是Netflix OSS套件中關(guān)于服務(wù)注冊(cè)和發(fā)現(xiàn)的解決方案。因?yàn)镾pring Cloud 在它的微服務(wù)解決方案中對(duì)Eureka進(jìn)行了集成，并作為優(yōu)先推薦方案進(jìn)行宣傳，所以早期有用 Spring Cloud 來建設(shè)微服務(wù)系統(tǒng)的同學(xué)會(huì)比較熟悉。

目前大量公司的微服務(wù)系統(tǒng)中依舊使用Eureka作為注冊(cè)中心，它的核心設(shè)計(jì)思想也被后續(xù)大量注冊(cè)中心產(chǎn)品借鑒。但目前 Eureka 2.0已經(jīng)停止維護(hù)，所以新的微服務(wù)架構(gòu)設(shè)計(jì)中，不再建議使用。

Spring Cloud Netflix主要分為兩個(gè)部分：

1、Eureka Server： 作為注冊(cè)中心Server端，向微服務(wù)應(yīng)用程序提供服務(wù)注冊(cè)、發(fā)現(xiàn)、健康檢查等能力。

2、Eureka Client：  微服務(wù)應(yīng)用程序Client端，用以和Eureka Server進(jìn)行通信。

 Eureka有比較友好的管理界面，如上圖所示：

1、System Status：顯示當(dāng)前Eureka Server信息。

2、Instances Current registered with Eureka：在Eureka Server當(dāng)前注冊(cè)的數(shù)據(jù)，在Spring Cloud生態(tài)中，被注冊(cè)的服務(wù)可以唄發(fā)現(xiàn)并羅列在這個(gè)地方。

3、General Info：基本信息，如cpu、內(nèi)存、環(huán)境等。

4.1.2 整體架構(gòu)

Eureka Server可以運(yùn)行多個(gè)實(shí)例來構(gòu)建集群，解決單點(diǎn)問題，但不同于ZooKeeper的選舉leader的過程，Eureka Server采用的是Peer to Peer對(duì)等通信。

所以他有如下特點(diǎn)：

1. 1、去中心化的架構(gòu)：無master/slave區(qū)分，每一個(gè)Peer都是對(duì)等的。在這種架構(gòu)中，節(jié)點(diǎn)通過彼此互相注冊(cè)來提高可用性，每個(gè)節(jié)點(diǎn)需要添加一個(gè)或多個(gè)有效的serviceUrl指向其他節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)都可被視為其他節(jié)點(diǎn)的副本。
2. 2、故障轉(zhuǎn)移/故障恢復(fù)：如果某臺(tái)Eureka Server宕機(jī)，Eureka Client的請(qǐng)求會(huì)自動(dòng)切換到新的Eureka Server節(jié)點(diǎn)，當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后，Eureka會(huì)再次將其納入到服務(wù)器集群管理之中。
3. 3、節(jié)點(diǎn)復(fù)制：當(dāng)節(jié)點(diǎn)開始接受客戶端請(qǐng)求時(shí)，所有的操作都會(huì)進(jìn)行replicateToPeer（節(jié)點(diǎn)間復(fù)制）操作，將請(qǐng)求復(fù)制到其他Eureka Server當(dāng)前所知的所有節(jié)點(diǎn)中。
   同理，一個(gè)新的Eureka Server節(jié)點(diǎn)啟動(dòng)后，會(huì)首先嘗試從鄰近節(jié)點(diǎn)獲取所有實(shí)例注冊(cè)表信息，完成初始化。
4. 4、CAP模式：復(fù)制算法非強(qiáng)一致性算法，而是當(dāng)有數(shù)據(jù)寫入時(shí)，Eureka Server將數(shù)據(jù)同步給其他的節(jié)點(diǎn)，因此Eureka在CAP提系統(tǒng)（一致性、可用性、分區(qū)容錯(cuò)性）是典型的AP系統(tǒng)。

4.1.3 接入Spring Cloud

如上圖所示：

1、Provider 服務(wù)提供者：服務(wù)向注冊(cè)中心注冊(cè)服務(wù)信息，即 服務(wù) -> 服務(wù)實(shí)例 數(shù)據(jù)模型， 同時(shí)定時(shí)向注冊(cè)中心匯報(bào)健康檢查，如果一定時(shí)間內(nèi)（一般90s）沒有進(jìn)行心跳匯報(bào)，則會(huì)被注冊(cè)中心剔除。

所以這邊注意，注冊(cè)中心感知到應(yīng)用下線并進(jìn)行剔除這個(gè)過程可能比較長(zhǎng)。 

2、Consumer 服務(wù)消費(fèi)者：服務(wù)向注冊(cè)中心獲取所需服務(wù)對(duì)應(yīng)的服務(wù)實(shí)例信息。這邊需要注意，Eureka不支持訂閱，因此在Spring Cloud生態(tài)中，通過定時(shí)拉取方式從注冊(cè)中心中獲取所需的服務(wù)實(shí)例信息。

3、Remote Call 遠(yuǎn)程調(diào)用：Consumer從注冊(cè)中心獲取的Provider的實(shí)例信息，通過 Load Balance的策略，確定一個(gè)實(shí)際的實(shí)例，發(fā)起遠(yuǎn)程調(diào)用。 

4.2 ZooKeeper

4.2.1 介紹

作為一個(gè)分布式的、開源的協(xié)調(diào)服務(wù)，ZooKeeper實(shí)現(xiàn)了一系列基礎(chǔ)功能，包括簡(jiǎn)單易用的接口。

這些接口被用來實(shí)現(xiàn)服務(wù)的注冊(cè)與發(fā)現(xiàn)功能。并實(shí)現(xiàn)一些高級(jí)功能，如數(shù)據(jù)同步、分布式鎖、配置中心、集群選舉、命名服務(wù)等。

在數(shù)據(jù)模型上，類似于傳統(tǒng)的文件系統(tǒng)，節(jié)點(diǎn)類型分為：

1、持久節(jié)點(diǎn)：節(jié)點(diǎn)創(chuàng)建后，就一直存在，除非執(zhí)行刪除操作，主動(dòng)刪掉這個(gè)節(jié)點(diǎn)。

2、臨時(shí)節(jié)點(diǎn)（注冊(cè)中心場(chǎng)景下的主要實(shí)現(xiàn)機(jī)制）：臨時(shí)節(jié)點(diǎn)的生命周期和客戶端會(huì)話綁定。也就是說，如果客戶端會(huì)話失效，那么這個(gè)節(jié)點(diǎn)就會(huì)自動(dòng)被清除掉。

在實(shí)際場(chǎng)景下，微服務(wù)啟動(dòng)的時(shí)候，會(huì)創(chuàng)建一個(gè)服務(wù)臨時(shí)節(jié)點(diǎn)，等把服務(wù)停止，短時(shí)間后節(jié)點(diǎn)就沒有了。

Zookeeper有如下特點(diǎn)：

1. 1、最終一致性：為客戶端展示同一視圖，這是zookeeper最重要的功能。
2. 2、可靠性：如果消息被到一臺(tái)服務(wù)器接受，那么它將被所有的服務(wù)器接受。
3. 3、實(shí)時(shí)性：Zookeeper不能保證兩個(gè)客戶端能同時(shí)得到剛更新的數(shù)據(jù)，如果需要最新數(shù)據(jù)，應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口。
4. 4、等待無關(guān)（wait-free）：慢的或者失效的client不干預(yù)快速的client的請(qǐng)求。
5. 5、原子性：更新只能成功或者失敗，沒有中間狀態(tài)。
6. 6、順序性：所有Server，同一消息發(fā)布順序一致。

4.2.2 整體架構(gòu)

上圖是Zookeeper 的服務(wù)架構(gòu)，他有如下流程：

1. 1、 多個(gè)節(jié)點(diǎn)組成分布式架構(gòu)，每個(gè)Server在內(nèi)存中存儲(chǔ)一份數(shù)據(jù)； 
2. 2、通過選舉產(chǎn)生leader，通過 Paxos(帕克索斯)強(qiáng)一致性算法 進(jìn)行保證，是典型的CP結(jié)構(gòu)。
3. 3、Leader負(fù)責(zé)處理數(shù)據(jù)更新等操作（Zab協(xié)議）；

4.2.3 接入Dubbo生態(tài)

上圖中的角色如下：

Provider：提供者,服務(wù)發(fā)布方

Consumer：消費(fèi)者, 調(diào)用服務(wù)方

Container：Dubbo容器.依賴于Spring容器

Registry：注冊(cè)中心，當(dāng)Container啟動(dòng)時(shí)把所有可以提供的服務(wù)列表上Registry中進(jìn)行注冊(cè)，告訴Consumer提供了什么服務(wù)，以及服務(wù)方的位置

Monitor:監(jiān)聽器

說明：ZooKeeper在注冊(cè)中心方面對(duì)Dubbo生態(tài)支持的比較好。服務(wù)提供者Providerzai Container啟動(dòng)時(shí)主動(dòng)向注冊(cè)中心Registry ZooKeeper中注冊(cè)信息。

服務(wù)消費(fèi)者Consumer啟動(dòng)時(shí)向注冊(cè)中心Registry ZooKeeper中訂閱注冊(cè)中心，當(dāng)Provider的信息發(fā)生變化時(shí)，注冊(cè)中心ZooKeeper會(huì)主動(dòng)向Consumer進(jìn)行推送通知變更。

這邊注意與Eureka的區(qū)別，這是主動(dòng)推送通知，是注冊(cè)中心下發(fā)的操作。

4.3 Consul

4.3.1 介紹

Consul是HashiCorp推出的一款軟件，是一個(gè)Service Mesh解決方案，提供了功能豐富的控制面功能：

1、Service Discovery（服務(wù)發(fā)現(xiàn)）

2、Configuration（配置化）

3、Segmentation Functionality

這些功能可以根據(jù)需要獨(dú)立使用，或者將它們一起使用用來構(gòu)建完整的Service Mesh。

Consul提供的關(guān)鍵功能如下：

1. 1、Service Discovery：服務(wù)注冊(cè)/發(fā)現(xiàn)功能。
2. 2、Health Checking：健康檢查，豐富的健康檢查方式；
3. 3、KV Store：KV存儲(chǔ)功能，可應(yīng)用多種場(chǎng)景，如動(dòng)態(tài)配置存儲(chǔ)，分布式協(xié)調(diào)、leader選舉等。
4. 4、Multi DataCenter：多數(shù)據(jù)中心。

4.3.2 整體架構(gòu)

如上圖為Consul的架構(gòu)，這邊對(duì)技術(shù)點(diǎn)做一下說明：

1、Raft: 一種分布式一致性算法，Consul使用該算法報(bào)紙強(qiáng)一致性，所以也是典型的CP模式

2、Client：Client是一種agent，其將會(huì)重定向所有的RPC 請(qǐng)求到Server。Client是無狀態(tài)的，其主要參與LAN Gossip協(xié)議池。其占用很少的資源，并且消耗很少的網(wǎng)絡(luò)帶寬。

3、Server：Server是一種agent，其包含了一系列的責(zé)任包括：參與Raft協(xié)議寫半數(shù)（Raft Quorum）、維護(hù)集群狀態(tài)、響應(yīng)RPC響應(yīng)、和其他Datacenter通過WAN gossip交換信息和重定向查詢請(qǐng)求至leader或者遠(yuǎn)端Datacenter。

4、Datacenter: Datacenter其是私有的、低延遲、高帶寬的網(wǎng)絡(luò)環(huán)境，去除了在公共網(wǎng)絡(luò)上的網(wǎng)絡(luò)交互。

5、Consensus: Consensus一致性在leader 選舉、順序執(zhí)行transaction 上。當(dāng)這些事務(wù)已經(jīng)提交至有限狀態(tài)機(jī)（finite-state machine）中，Consul定義consensus作為復(fù)制狀態(tài)機(jī)的一致性。本質(zhì)上使用實(shí)現(xiàn)了Raft協(xié)議，對(duì)于具體實(shí)現(xiàn)細(xì)節(jié)可參考 Consensus Protocol。

6、Gossip：Consul使用了Serf，其提供了Gossip協(xié)議多種用途，Serf提供成員關(guān)系、失敗檢查和事件廣播。

7、LAN Gossip: Local Area Network Gossip其包含在同一個(gè)網(wǎng)絡(luò)環(huán)境或Datacenter的節(jié)點(diǎn)。

8、WAN Gossip: Wide Area Network Gossip 其只包含Server節(jié)點(diǎn)，這些server分布在不同的datacenter中，其主要通過因特網(wǎng)或廣域網(wǎng)相互交流。

9、RPC: 遠(yuǎn)程過程調(diào)用，用于服務(wù)之間的通信。

10、CAP抉擇：在高可用方面，Consul使用Raft協(xié)議作為其分布式一致性協(xié)議，本身對(duì)故障節(jié)點(diǎn)有一定的容忍性，在單個(gè)DataCenter中Consul集群中節(jié)點(diǎn)的數(shù)量控制在2*n + 1個(gè)節(jié)點(diǎn)，其中n為可容忍的宕機(jī)個(gè)數(shù)，通常為3個(gè)節(jié)點(diǎn)。

所以是典型的CP模式。

根據(jù)Consul 的選舉機(jī)制和服務(wù)原理，我們有兩個(gè)注意點(diǎn) ：

1、部署Consul Service 節(jié)點(diǎn)應(yīng)該奇數(shù)為宜，因?yàn)?1的偶數(shù)節(jié)點(diǎn)和奇數(shù)節(jié)點(diǎn)可容忍的故障數(shù)是一樣的，比如上圖3和4，另一方面，偶數(shù)個(gè)節(jié)點(diǎn)在選主節(jié)點(diǎn)的時(shí)候可能會(huì)出現(xiàn)二分選票的情況，還得重新選舉。

2、Consul Service 節(jié)點(diǎn)數(shù)不是越多越好，雖然Server數(shù)量越多可容忍的故障數(shù)越多，但是Raft進(jìn)行日志復(fù)制也是很耗時(shí)間的，而且Server數(shù)量越多，性能越低，所以結(jié)合實(shí)際場(chǎng)景，一般建議Server部署3個(gè)即可。 

有興趣的同學(xué)可以去Consul官網(wǎng)看看它的選舉機(jī)制，還可以對(duì)比下Redis中Sentinel模式。

4.3.3 生態(tài)對(duì)接

對(duì)接Spring Cloud生態(tài)

Consul作為注冊(cè)中心，集成在Spring Cloud生態(tài)。可以看出，跟Eureka對(duì)接到Spring Cloud 生態(tài)的過程很像。

但是這邊的健康檢查更豐富，可以有多種不同的的Check方式：

• Script check（Script+ Interval）
• 基于HTTP請(qǐng)求
• 基于tcp請(qǐng)求
• 基于grpc請(qǐng)求

4.4 總結(jié)對(duì)比

4種注冊(cè)中心技術(shù)對(duì)比

這邊是對(duì)業(yè)內(nèi)4種注冊(cè)中心各緯度上的對(duì)比，Eureka是典型的AP類型，Zookeeper和Consul是典型的CP類型。如何選擇取決你的業(yè)務(wù)是傾向A：高可用性 還是 C：強(qiáng)一致性。

當(dāng)然，業(yè)務(wù)是復(fù)雜的，在真正的技術(shù)選型時(shí)，還是要根據(jù)自己的實(shí)際業(yè)務(wù)現(xiàn)狀來判斷。有一些傾向，比如你的系統(tǒng)是Spring Cloud體系下，那優(yōu)先選擇Eureka、Consul。

如果業(yè)務(wù)會(huì)更多向云原生對(duì)齊，則Consul、Etcd會(huì)是比較優(yōu)先的選擇。

以上就是微服務(wù)架構(gòu)之服務(wù)注冊(cè)與發(fā)現(xiàn)功能詳解的詳細(xì)內(nèi)容，更多關(guān)于服務(wù)注冊(cè)與發(fā)現(xiàn)功能的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論