1 微服務

1.1 微服務的演變

單體架構：

• 將業(yè)務的所有功能集中在一個項目中開發(fā)，打成一個包部署。
• 優(yōu)點：架構簡單；部署成本低（打jar包、部署、負載均衡就完成了）
• 缺點：耦合度高（維護困難、升級困難，不利于大項目開發(fā)）
  

分布式架構

• 根據(jù)業(yè)務功能對系統(tǒng)做拆分，每個業(yè)務功能模塊作為獨立項目開發(fā)，稱為一個服務
• 優(yōu)點：降低服務耦合；有利于服務升級和拓展
• 缺點：服務調(diào)用關系錯綜復雜，難度大
  

分布式架構要考慮的問題：
服務拆分的粒度如何？每個服務對應唯一的業(yè)務能力。
服務集群地址如何維護？
服務之間如何調(diào)用？注冊中心、消息隊列
服務的調(diào)用關系如何管理？消息隊列

1.2 微服務

微服務是一種經(jīng)過良好架構設計的分布式架構方案 。

微服務的架構特征：

• 單一職責：微服務拆分粒度更小，每一個服務都對應唯一的業(yè)務能力，做到單一職責
• 自治：團隊獨立、技術獨立、數(shù)據(jù)獨立，獨立部署和交付
• 面向服務：服務提供統(tǒng)一標準的接口，與語言和技術無關
• 隔離性強：服務調(diào)用做好隔離、容錯、降級，避免出現(xiàn)級聯(lián)問題
  

全球的互聯(lián)網(wǎng)公司都在積極嘗試自己的微服務落地方案。其中在Java領域國內(nèi)最知名的是SpringCloud和Dubbo。

微服務技術對比：

不同企業(yè)需求：

1.3 SpringCloud

SpringCloud是目前國內(nèi)使用最廣泛的微服務框架。官網(wǎng)地址：https://spring.io/projects/spring-cloud。

SpringCloud集成了各種微服務功能組件，并基于SpringBoot實現(xiàn)了這些組件的自動裝配，從而提供了良好的開箱即用體驗。

其中常見的組件包括：
另外，SpringCloud底層是依賴于SpringBoot的，并且有版本的兼容關系，如下：

目前學習使用的版本是 Hoxton.SR10，因此對應的SpringBoot版本是2.3.x版本。
如果版本不兼容運行會報錯：Error creating bean with name 'configurationPropertiesBeans' ...

1.4 小結

• 單體架構：簡單方便，高度耦合，擴展性差，適合小型項目。例如：學生管理系統(tǒng)

• 分布式架構：松耦合，擴展性好，但架構復雜，難度大。適合大型互聯(lián)網(wǎng)項目，例如：京東、淘寶

• 微服務：一種良好的分布式架構方案

  ①優(yōu)點：拆分粒度更小、服務更獨立、耦合度更低

  ②缺點：架構非常復雜，運維、監(jiān)控、部署難度提高

• SpringCloud是微服務架構的一站式解決方案，集成了各種優(yōu)秀微服務功能組件

2 服務拆分及遠程調(diào)用

2.1 服務拆分

微服務拆分時的幾個原則：

• 單一職責：不同微服務，不要重復開發(fā)相同業(yè)務
• 數(shù)據(jù)獨立：不要訪問其它微服務的數(shù)據(jù)庫
• 面向服務：將自己的業(yè)務暴露為接口，供其它微服務調(diào)用

2.2 服務拆分案例

導入資料中的微服務cloud-demo，其結構：

注意修改自己的數(shù)據(jù)庫密碼

cloud-demo：父工程，管理依賴

• order-service：訂單微服務，負責訂單相關業(yè)務
• user-service：用戶微服務，負責用戶相關業(yè)務

要求：

• 訂單微服務和用戶微服務都必須有各自的數(shù)據(jù)庫，相互獨立
• 訂單服務和用戶服務都對外暴露Restful的接口
• 訂單服務如果需要查詢用戶信息，只能調(diào)用用戶服務的Restful接口，不能查詢用戶數(shù)據(jù)庫

導入提供的cloud-order.sql和cloud-user.sql導入到mysql中：

tb_user：

tb_order：

運行demo，分別訪問：

2.3 實現(xiàn)遠程調(diào)用

需求：根據(jù)訂單id查詢訂單的同時把訂單所屬的用戶信息一起返回
根據(jù)上面的demo我們會發(fā)現(xiàn)在order-service服務中，有一個根據(jù)id查詢訂單的接口，返回的order對象中user為null
而案例需求：修改order-service中的根據(jù)id查詢訂單業(yè)務，要求在查詢訂單的同時，根據(jù)訂單中包含的userId查詢出用戶信息，一起返回。

因此，我們需要在order-service中 向user-service發(fā)起一個http的請求，調(diào)用http://localhost:8081/user/{userId}這個接口。

大概的步驟是這樣的：

• 注冊一個RestTemplate的實例到Spring容器
• 修改order-service服務中的OrderService類中的queryOrderById方法，根據(jù)Order對象中的userId查詢User
• 將查詢的User填充到Order對象，一起返回

步驟1： 注冊RestTemplate
在order-service服務中的OrderApplication啟動類中，注冊RestTemplate

/**
 * 創(chuàng)建RestTemplate并注入Spring容器
 * @return
 */
@Bean
public RestTemplate restTemplate(){
    return new RestTemplate();
}

步驟2： 實現(xiàn)遠程調(diào)用
修改order-service服務中的cn.itcast.order.service包下的OrderService類中的queryOrderById方法：

@GetMapping("/{orderId}")
public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
    // 1.根據(jù)id查詢訂單
    Order order = orderService.queryOrderById(orderId);
    //2. 利用RestTemplate發(fā)送http請求，查詢用戶
    //2.1 url
    String url = "http://localhost:8081/user/"+order.getUserId();
    //2.2 發(fā)送http請求實現(xiàn)遠程調(diào)用
    User user = restTemplate.getForObject(url, User.class);
    //3. 封裝User到Order
    order.setUser(user);
    //4. 返回
    return order;
}

restTemplate自動把json格式的數(shù)據(jù)轉為了對象

測試效果：

微服務調(diào)用方式：

• 基于RestTemplate發(fā)起的http請求實現(xiàn)遠程調(diào)用
• http請求做遠程調(diào)用是與語言無關的調(diào)用，只要知道對方的ip、端口、接口路徑、請求參數(shù)即可。

2.4 提供者與消費者

在服務調(diào)用關系中，會有兩個不同的角色：

服務提供者：一次業(yè)務中，被其它微服務調(diào)用的服務。（提供接口給其它微服務）

服務消費者：一次業(yè)務中，調(diào)用其它微服務的服務。（調(diào)用其它微服務提供的接口）

服務A調(diào)用了服務B，而服務B又調(diào)用了服務C，服務B的角色是什么？

• 對于A調(diào)用B的業(yè)務而言：A是服務消費者，B是服務提供者
• 對于B調(diào)用C的業(yè)務而言：B是服務消費者，C是服務提供者

因此，服務B既可以是服務提供者，也可以是服務消費者。

服務提供者與服務消費者的角色并不是絕對的，而是相對于業(yè)務而言。
一個服務既可以是服務者也可以是消費者

3 Eureka注冊中心

上面案例我們使用了硬編碼獲取了地址：

存在的問題：

• order-service在發(fā)起遠程調(diào)用的時候，該如何得知user-service實例的ip地址和端口？
• 有多個user-service實例地址，order-service調(diào)用時該如何選擇？
• order-service如何得知某個user-service實例是否依然健康，是不是已經(jīng)宕機？

3.1 Eureka的結構和作用

Eureka的作用

• 消費者該如何獲取服務提供者具體信息?
  • 服務提供者啟動時向eureka注冊自己的信息
  • eureka保存這些信息
  • 消費者根據(jù)服務名稱向eureka拉取提供者信息
• 如果有多個服務提供者,消費者該如何選擇?
  • 服務消費者利用負載均衡算法，從服務列表中挑選一個
• 消費者如何感知服務提供者健康狀態(tài)?
  • 服務提供者會每隔30秒向EurekaServer發(fā)送心跳請求,報告健康狀態(tài)
  • eureka會更新記錄服務列表信息，心跳不正常會被剔除
  • 消費者就可以拉取到最新的信息

回答上面的各個問題。

問題1：order-service如何得知user-service實例地址？

獲取地址信息的流程如下：

• user-service服務實例啟動后，將自己的信息注冊到eureka-server（Eureka服務端）。這個叫服務注冊
• eureka-server保存服務名稱到服務實例地址列表的映射關系
• order-service根據(jù)服務名稱，拉取實例地址列表。這個叫服務發(fā)現(xiàn)或服務拉取

問題2：order-service如何從多個user-service實例中選擇具體的實例？

• order-service從實例列表中利用負載均衡算法選中一個實例地址
• 向該實例地址發(fā)起遠程調(diào)用

問題3：order-service如何得知某個user-service實例是否依然健康，是不是已經(jīng)宕機？

• user-service會每隔一段時間（默認30秒）向eureka-server發(fā)起請求，報告自己狀態(tài)，稱為心跳
• 當超過一定時間沒有發(fā)送心跳時，eureka-server會認為微服務實例故障，將該實例從服務列表中剔除
• order-service拉取服務時，就能將故障實例排除了

注意：一個微服務，既可以是服務提供者，又可以是服務消費者，因此eureka將服務注冊、服務發(fā)現(xiàn)等功能統(tǒng)一封裝到了eureka-client端

3.2 搭建eureka-server

步驟如下：

在cloud-demo父工程下，創(chuàng)建一個子Maven模塊（創(chuàng)建eureka-server服務）：

1. 引入SpringCloud為eureka提供的starter依賴：

<!--eureka服務端-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

2. 給eureka-server服務編寫一個啟動類，一定要添加一個@EnableEurekaServer注解，開啟eureka的注冊中心功能

package cn.itcast.eureka;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;

@SpringBootApplication
@EnableEurekaServer
public class EurekaApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaApplication.class, args);
    }
}

3. 編寫一個application.yml配置文件

server:
  port: 10086
spring:
  application:
   name: eurekaservice #eureka的服務名稱
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka #eureka的地址信息

4. 啟動服務
   啟動微服務，然后在瀏覽器訪問：http://127.0.0.1:10086
   看到下面結果應該是成功了：
   
   

3.3 服務注冊

我們將user-service模塊注冊到eureka-server中去。

1. 在user-service的pom文件中，引入下面的eureka-client依賴

<!--引入eureka客戶依賴-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2. 在user-service中，修改application.yml文件，添加服務名稱、eureka地址

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

3. 啟動多個user-service實例
   

問題解決：在idea2022中復制 configuration改變項目端口的解決方案
啟動：
查看eureka-server管理頁面：

3.4 服務發(fā)現(xiàn)

在order-service完成服務拉取

服務拉取是基于服務名稱獲取服務列表，然后再對服務列表做負載均衡

我們將order-service的邏輯修改：向eureka-server拉取user-service的信息，實現(xiàn)服務發(fā)現(xiàn)。

1. 引入依賴。之前說過，服務發(fā)現(xiàn)、服務注冊統(tǒng)一都封裝在eureka-client依賴，因此這一步與服務注冊時一致。
2. 配置文件。服務發(fā)現(xiàn)也需要知道eureka地址，因此第二步與服務注冊一致，都是配置eureka信息
3. 服務拉取和負載均衡
   最后，我們要去eureka-server中拉取user-service服務的實例列表，并且實現(xiàn)負載均衡。
   在order-service的OrderApplication中，給RestTemplate這個Bean添加一個@LoadBalanced注解
   
   修改order-service服務中的cn.itcast.order.service包下的OrderService類中的queryOrderById方法。修改訪問的url路徑，用服務名代替ip、端口：
   
   spring會自動幫助我們從eureka-server端，根據(jù)userservice這個服務名稱，獲取實例列表，而后完成負載均衡。
   

4 Ribbon負載均衡

問題：上一節(jié)中，我們添加了@LoadBalanced注解，即可實現(xiàn)負載均衡功能，這是什么原理呢？

4.1 負載均衡原理

SpringCloud底層其實是利用了一個名為Ribbon的組件，來實現(xiàn)負載均衡功能的。

問題：發(fā)出的請求明明是http://userservice/user/1，如何變成http://localhost:8081的呢？

4.2 源碼分析

為什么我們只輸入了service名稱就可以訪問了呢？之前還要獲取ip和端口。

顯然有人幫我們根據(jù)service名稱，獲取到了服務實例的ip和端口。它就是LoadBalancerInterceptor，這個類會在對RestTemplate的請求進行攔截，然后從Eureka根據(jù)服務id獲取服務列表，隨后利用負載均衡算法得到真實的服務地址信息，替換服務id。

我們通過斷點調(diào)試進行源碼跟蹤：

LoadBalancerIntercepor

可以看到這里的intercept方法，攔截了用戶的HttpRequest請求，然后做了幾件事：

• request.getURI()：獲取請求uri，本例中就是 http://user-service/user/8
• originalUri.getHost()：獲取uri路徑的主機名，其實就是服務id，user-service
• this.loadBalancer.execute()：處理服務id，和用戶請求。

這里的this.loadBalancer是LoadBalancerClient類型，我們繼續(xù)跟入。

LoadBalancerClient

繼續(xù)跟入execute方法：

• getLoadBalancer(serviceId)：根據(jù)服務id獲取ILoadBalancer，而ILoadBalancer會拿著服務id去eureka中獲取服務列表并保存起來。
• getServer(loadBalancer)：利用內(nèi)置的負載均衡算法，從服務列表中選擇一個。本例中，可以看到獲取了8082端口的服務

放行后，再次訪問并跟蹤，發(fā)現(xiàn)獲取的是8081：

實現(xiàn)了負載均衡。

負載均衡策略IRule

在剛才的代碼中，可以看到獲取服務使通過一個getServer方法來做負載均衡:

繼續(xù)跟入：

繼續(xù)跟蹤源碼chooseServer方法，發(fā)現(xiàn)這么一段代碼：

我們看看這個rule是誰：

這里的rule默認值是一個RoundRobinRule，看類的介紹：

RoundRobin：輪詢。也就是實現(xiàn)了負載均衡

總結

SpringCloudRibbon的底層采用了一個攔截器，攔截了RestTemplate發(fā)出的請求，對地址做了修改。

基本流程如下：

• 攔截我們的RestTemplate請求http://userservice/user/1
• RibbonLoadBalancerClient會從請求url中獲取服務名稱，也就是user-service
• DynamicServerListLoadBalancer根據(jù)user-service到eureka拉取服務列表
• eureka返回列表，localhost:8081、localhost:8082
• IRule利用內(nèi)置負載均衡規(guī)則，從列表中選擇一個，例如localhost:8081
• RibbonLoadBalancerClient修改請求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，發(fā)起真實請求

4.3 負載均衡策略

負載均衡的規(guī)則都定義在IRule接口中，而IRule有很多不同的實現(xiàn)類：

不同規(guī)則的含義：

默認的實現(xiàn)就是ZoneAvoidanceRule，是一種輪詢方案

通過自定義IRule實現(xiàn)可以修改負載均衡規(guī)則，有兩種方式：
方式一：代碼方式：在order-service中的OrderApplication類中，定義一個新的IRule（所有的服務都執(zhí)行）

@Bean
public IRule randomRule(){
    return new RandomRule();
}

方式二：配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改規(guī)則（針對某個服務）

userservice: # 給某個微服務配置負載均衡規(guī)則，這里是userservice服務
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 負載均衡規(guī)則 

注意：一般用默認的負載均衡規(guī)則，不做修改。

4.4 饑餓加載

Ribbon默認是采用懶加載，即第一次訪問時才會去創(chuàng)建LoadBalanceClient，請求時間會很長。
而饑餓加載則會在項目啟動時創(chuàng)建，降低第一次訪問的耗時，通過下面配置開啟饑餓加載：

ribbon:
  eager-load:
    enabled: true
    clients: userservice
    # 如果有多個使用這種寫法
    # clients:
    #  - userservice
    #  - xxxxservice

5 Nacos注冊中心

國內(nèi)公司一般都推崇阿里巴巴的技術，比如注冊中心，SpringCloudAlibaba也推出了一個名為Nacos的注冊中心。

5.1.認識和安裝Nacos

Nacos是阿里巴巴的產(chǎn)品，現(xiàn)在是SpringCloud中的一個組件。相比Eureka功能更加豐富，在國內(nèi)受歡迎程度較高。

在Nacos的GitHub頁面，提供有下載鏈接，可以下載編譯好的Nacos服務端或者源代碼：
GitHub主頁GitHub的Release下載頁

5.1.1 Windows下安裝Nacos

下載后解壓到一個非中文路徑下：

1. 端口配置
   acos的默認端口是8848，如果你電腦上的其它進程占用了8848端口，請先嘗試關閉該進程。如果無法關閉占用8848端口的進程，也可以進入nacos的conf目錄，修改配置文件中的端口：
   

2. 啟動
   進入bin目錄，結構如下：
   
   然后執(zhí)行命令：startup.cmd -m standalone
   執(zhí)行成功后：
   

3. 訪問
   啟動后，在瀏覽器輸入地址：http://127.0.0.1:8848/nacos即可，默認賬號和密碼都是nacos
   

5.1.2 Linux下安裝Nacos

1. 安裝JDK
   Nacos依賴于JDK運行，所以Linux上也需要安裝JDK才行。
   
   上傳到某個目錄，例如：/usr/local/，

然后解壓縮：

tar -xvf jdk-8u144-linux-x64.tar.gz

然后重命名為java
配置環(huán)境變量：

export JAVA_HOME=/usr/local/java
export PATH=$PATH:$JAVA_HOME/bin

設置環(huán)境變量：

source /etc/profile

2. 上傳安裝包
   上傳到Linux服務器的某個目錄，例如/usr/local/src目錄下：
   
3. 解壓

命令解壓縮安裝包：

tar -xvf nacos-server-1.4.1.tar.gz

然后刪除安裝包：

rm -rf nacos-server-1.4.1.tar.gz

4. 端口配置

與windows中類似

5. 啟動，在nacos/bin目錄中，輸入命令啟動Nacos：

sh startup.sh -m standalone

5.2 服務注冊到nacos

Nacos是SpringCloudAlibaba的組件，而SpringCloudAlibaba也遵循SpringCloud中定義的服務注冊、服務發(fā)現(xiàn)規(guī)范。因此使用Nacos和使用Eureka對于微服務來說，并沒有太大區(qū)別。

主要差異在于：

• 依賴不同
• 服務地址不同

1. 引入依賴
   在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依賴：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>

然后在user-service和order-service中的pom文件中引入nacos-discovery依賴：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2. 配置nacos
   在user-service和order-service的application.yml中添加nacos地址：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

3. 重啟
   重啟微服務后，登錄nacos管理頁面，可以看到微服務信息：
   
   

5.3 服務分級存儲模型

一個服務可以有多個實例，例如我們的user-service，可以有:

• 127.0.0.1:8081
• 127.0.0.1:8082
• 127.0.0.1:8083

假如這些實例分布于全國各地的不同機房，例如：

• 127.0.0.1:8081，在上海機房
• 127.0.0.1:8082，在上海機房
• 127.0.0.1:8083，在杭州機房

Nacos就將同一機房內(nèi)的實例 劃分為一個集群。

也就是說，user-service是服務，一個服務可以包含多個集群，如杭州、上海，每個集群下可以有多個實例，形成分級模型，如圖：

微服務互相訪問時，應該盡可能訪問同集群實例，因為本地訪問速度更快。當本集群內(nèi)不可用時，才訪問其它集群。例如：

杭州機房內(nèi)的order-service應該優(yōu)先訪問同機房的user-service。

5.3.1 給user-service配置集群

修改user-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名稱

重啟兩個user-service實例后，我們可以在nacos控制臺看到下面結果：

再次復制一個user-service啟動配置，添加屬性：

啟動UserApplication3后再次查看nacos控制臺：

5.3.2 同集群優(yōu)先的負載均衡

默認的ZoneAvoidanceRule并不能實現(xiàn)根據(jù)同集群優(yōu)先來實現(xiàn)負載均衡。因此Nacos中提供了一個NacosRule的實現(xiàn)，可以優(yōu)先從同集群中挑選實例。

1）給order-service配置集群信息，修改order-service的application.yml文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名稱

2）修改負載均衡規(guī)則，修改order-service的application.yml文件，修改負載均衡規(guī)則：

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 負載均衡規(guī)則 

5.4 權重配置

實際部署中會出現(xiàn)這樣的場景：
服務器設備性能有差異，部分實例所在機器性能較好，另一些較差，我們希望性能好的機器承擔更多的用戶請求。
但默認情況下NacosRule是同集群內(nèi)隨機挑選，不會考慮機器的性能問題。
因此，Nacos提供了權重配置來控制訪問頻率，權重越大則訪問頻率越高。
在nacos控制臺，找到user-service的實例列表，點擊編輯，即可修改權重：

如果權重修改為0，則該實例永遠不會被訪問

5.5 環(huán)境隔離

Nacos提供了namespace來實現(xiàn)環(huán)境隔離功能。

• nacos中可以有多個namespace
• namespace下可以有group、service等
• 不同namespace之間相互隔離，例如不同namespace的服務互相不可見
  

5.5.1 創(chuàng)建namespace

默認情況下，所有service、data、group都在同一個namespace，名為public：

我們可以點擊頁面新增按鈕，添加一個namespace

如果不設置id則通過uuid自動生成

就能在頁面看到一個新的namespace：

5.5.2 給微服務配置namespace

給微服務配置namespace只能通過修改配置來實現(xiàn)。
例如，修改order-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空間，填ID

此時訪問order-service，因為namespace不同，會導致找不到userservice，控制臺會報錯：

5.6.Nacos與Eureka的區(qū)別

Nacos的服務實例分為兩種l類型：

• 臨時實例：如果實例宕機超過一定時間，會從服務列表剔除，默認的類型。
• 非臨時實例：如果實例宕機，不會從服務列表剔除，也可以叫永久實例。
  配置一個服務實例為永久實例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 設置為非臨時實例

Nacos和Eureka整體結構類似，服務注冊、服務拉取、心跳等待，但是也存在一些差異：

• Nacos與eureka的共同點

  • 都支持服務注冊和服務拉取
  • 都支持服務提供者心跳方式做健康檢測

• Nacos與Eureka的區(qū)別文章來源地址http://www.zghlxwxcb.cn/news/detail-640837.html

  • Nacos支持服務端主動檢測提供者狀態(tài)：臨時實例采用心跳模式，非臨時實例采用主動檢測模式
  • 臨時實例心跳不正常會被剔除，非臨時實例則不會被剔除
  • Nacos支持服務列表變更的消息推送模式，服務列表更新更及時
  • Nacos集群默認采用AP方式，當集群中存在非臨時實例時，采用CP模式；Eureka采用AP方式

到了這里，關于SpringCloud實用篇1——eureka注冊中心 Ribbon負載均衡原理 nacos注冊中心的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！