?本篇用到的資料：https://gitee.com/Allengan/cloud-demo.githttps://gitee.com/Allengan/cloud-demo.git

目錄

1.認(rèn)識(shí)微服務(wù)

1.1.單體架構(gòu)

1.2.分布式架構(gòu)

1.3.微服務(wù)

1.4.SpringCloud

1.5.總結(jié)

2.服務(wù)拆分和遠(yuǎn)程調(diào)用

2.1.服務(wù)拆分原則

2.2.服務(wù)拆分示例

2.2.1.導(dǎo)入Sql語(yǔ)句

2.2.2.導(dǎo)入demo工程

2.3.實(shí)現(xiàn)遠(yuǎn)程調(diào)用案例

2.3.1.案例需求：

2.3.2.注冊(cè)RestTemplate

2.3.3.實(shí)現(xiàn)遠(yuǎn)程調(diào)用

2.4.提供者與消費(fèi)者

3.Eureka注冊(cè)中心

3.1.Eureka的結(jié)構(gòu)和作用

3.2.搭建eureka-server

3.2.1.創(chuàng)建eureka-server服務(wù)

3.2.2.引入eureka依賴

3.2.3.編寫啟動(dòng)類

3.2.4.編寫配置文件

3.2.5.啟動(dòng)服務(wù)

3.3.服務(wù)注冊(cè)

1）引入依賴

2）配置文件

3）啟動(dòng)多個(gè)user-service實(shí)例

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

1）引入依賴 （和前面服務(wù)注冊(cè)一致）

2）配置文件（和前面服務(wù)注冊(cè)一致）

3）服務(wù)拉取和負(fù)載均衡

4.Ribbon負(fù)載均衡

4.1.負(fù)載均衡原理

4.2.源碼跟蹤

1）LoadBalancerIntercepor

2）LoadBalancerClient

3）負(fù)載均衡策略IRule

4）總結(jié)

4.3.負(fù)載均衡策略

4.3.1.負(fù)載均衡策略

4.3.2.自定義負(fù)載均衡策略

4.4.饑餓加載

5.Nacos注冊(cè)中心

5.1.認(rèn)識(shí)和安裝Nacos

5.2.服務(wù)注冊(cè)到nacos

1）引入依賴

2）配置nacos地址

3）重啟

5.3.服務(wù)分級(jí)存儲(chǔ)模型

5.3.1.給user-service配置集群

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

5.4.權(quán)重配置

5.5.環(huán)境隔離

5.5.1.創(chuàng)建namespace

5.5.2.給微服務(wù)配置namespace

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

?

1.認(rèn)識(shí)微服務(wù)

隨著互聯(lián)網(wǎng)行業(yè)的發(fā)展，對(duì)服務(wù)的要求也越來(lái)越高，服務(wù)架構(gòu)也從單體架構(gòu)逐漸演變?yōu)楝F(xiàn)在流行的微服務(wù)架構(gòu)。

1.1.單體架構(gòu)

單體架構(gòu)：將業(yè)務(wù)的所有功能集中在一個(gè)項(xiàng)目中開(kāi)發(fā)，打成一個(gè)包部署。

單體架構(gòu)的優(yōu)缺點(diǎn)如下：

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

• 架構(gòu)簡(jiǎn)單

• 部署成本低

缺點(diǎn)：

• 耦合度高（維護(hù)困難、升級(jí)困難）

1.2.分布式架構(gòu)

分布式架構(gòu)：根據(jù)業(yè)務(wù)功能對(duì)系統(tǒng)做拆分，每個(gè)業(yè)務(wù)功能模塊作為獨(dú)立項(xiàng)目開(kāi)發(fā)，稱為一個(gè)服務(wù)。

?

分布式架構(gòu)的優(yōu)缺點(diǎn)：

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

• 降低服務(wù)耦合

• 有利于服務(wù)升級(jí)和拓展

缺點(diǎn)：

• 服務(wù)調(diào)用關(guān)系錯(cuò)綜復(fù)雜

1.3.微服務(wù)

微服務(wù)的架構(gòu)特征：

• 單一職責(zé)：微服務(wù)拆分粒度更小，每一個(gè)服務(wù)都對(duì)應(yīng)唯一的業(yè)務(wù)能力，做到單一職責(zé)

• 自治：團(tuán)隊(duì)獨(dú)立、技術(shù)獨(dú)立、數(shù)據(jù)獨(dú)立，獨(dú)立部署和交付

• 面向服務(wù)：服務(wù)提供統(tǒng)一標(biāo)準(zhǔn)的接口，與語(yǔ)言和技術(shù)無(wú)關(guān)

• 隔離性強(qiáng)：服務(wù)調(diào)用做好隔離、容錯(cuò)、降級(jí)，避免出現(xiàn)級(jí)聯(lián)問(wèn)題

?

微服務(wù)的上述特性其實(shí)是在給分布式架構(gòu)制定一個(gè)標(biāo)準(zhǔn)，進(jìn)一步降低服務(wù)之間的耦合度，提供服務(wù)的獨(dú)立性和靈活性。做到高內(nèi)聚，低耦合。

因此，可以認(rèn)為微服務(wù)是一種經(jīng)過(guò)良好架構(gòu)設(shè)計(jì)的分布式架構(gòu)方案 。

但方案該怎么落地？選用什么樣的技術(shù)棧？全球的互聯(lián)網(wǎng)公司都在積極嘗試自己的微服務(wù)落地方案。

其中在Java領(lǐng)域最引人注目的就是SpringCloud提供的方案了。

1.4.SpringCloud

SpringCloud是目前國(guó)內(nèi)使用最廣泛的微服務(wù)框架。官網(wǎng)地址：Spring Cloud。

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

其中常見(jiàn)的組件包括：

?另外，SpringCloud底層是依賴于SpringBoot的，并且有版本的兼容關(guān)系，如下：

1.5.總結(jié)

• 單體架構(gòu)：簡(jiǎn)單方便，高度耦合，擴(kuò)展性差，適合小型項(xiàng)目。

• 分布式架構(gòu)：松耦合，擴(kuò)展性好，但架構(gòu)復(fù)雜，難度大。適合大型互聯(lián)網(wǎng)項(xiàng)目；

• 微服務(wù)：一種良好的分布式架構(gòu)方案

  ①優(yōu)點(diǎn)：拆分粒度更小、服務(wù)更獨(dú)立、耦合度更低

  ②缺點(diǎn)：架構(gòu)非常復(fù)雜，運(yùn)維、監(jiān)控、部署難度提高

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

2.服務(wù)拆分和遠(yuǎn)程調(diào)用

任何分布式架構(gòu)都離不開(kāi)服務(wù)的拆分，微服務(wù)也是一樣。

2.1.服務(wù)拆分原則

• 不同微服務(wù)，不要重復(fù)開(kāi)發(fā)相同業(yè)務(wù)

• 微服務(wù)數(shù)據(jù)獨(dú)立，不要訪問(wèn)其它微服務(wù)的數(shù)據(jù)庫(kù)

• 微服務(wù)可以將自己的業(yè)務(wù)暴露為接口，供其它微服務(wù)調(diào)用

2.2.服務(wù)拆分示例

微服務(wù)cloud-demo為例，其結(jié)構(gòu)如下：

傳送門：https://gitee.com/Allengan/cloud-demo?

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

• order-service：訂單微服務(wù)，負(fù)責(zé)訂單相關(guān)業(yè)務(wù)

• user-service：用戶微服務(wù)，負(fù)責(zé)用戶相關(guān)業(yè)務(wù)

要求：

• 訂單微服務(wù)和用戶微服務(wù)都必須有各自的數(shù)據(jù)庫(kù)，相互獨(dú)立

• 訂單服務(wù)和用戶服務(wù)都對(duì)外暴露Restful的接口

• 訂單服務(wù)如果需要查詢用戶信息，只能調(diào)用用戶服務(wù)的Restful接口，不能查詢用戶數(shù)據(jù)庫(kù)

2.2.1.導(dǎo)入Sql語(yǔ)句

提供的cloud-order.sql和cloud-user.sql導(dǎo)入到mysql中：

2.2.2.導(dǎo)入demo工程

資料提供的Demo：

?導(dǎo)入后，會(huì)在IDEA右下角出現(xiàn)彈窗：

點(diǎn)擊彈窗，然后按下圖選擇：

會(huì)出現(xiàn)這樣的菜單：

配置下項(xiàng)目使用的JDK：

2.3.實(shí)現(xiàn)遠(yuǎn)程調(diào)用案例

?在order-service服務(wù)中，有一個(gè)根據(jù)id查詢訂單的接口：

根據(jù)id查詢訂單，返回值是Order對(duì)象，如圖：

其中的user為null

在user-service中有一個(gè)根據(jù)id查詢用戶的接口：

?查詢的結(jié)果如圖：

2.3.1.案例需求：

修改order-service中的根據(jù)id查詢訂單業(yè)務(wù)，要求在查詢訂單的同時(shí)，根據(jù)訂單中包含的userId查詢出用戶信息，一起返回。

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

大概的步驟是這樣的：

• 注冊(cè)一個(gè)RestTemplate的實(shí)例到Spring容器

• 修改order-service服務(wù)中的OrderService類中的queryOrderById方法，根據(jù)Order對(duì)象中的userId查詢User

• 將查詢的User填充到Order對(duì)象，一起返回

2.3.2.注冊(cè)RestTemplate

首先，我們?cè)趏rder-service服務(wù)中的OrderApplication啟動(dòng)類中，注冊(cè)RestTemplate實(shí)例：

@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

2.3.3.實(shí)現(xiàn)遠(yuǎn)程調(diào)用

修改order-service服務(wù)中的cn.itcast.order.service包下的OrderService類中的queryOrderById方法：

//2.遠(yuǎn)程調(diào)用User模塊接口（發(fā)送HTTP請(qǐng)求）查詢用戶信息使用Id
        String url = "http://user-service/user/" + order.getUserId();
        User user = restTemplate.getForObject(url, User.class);

2.4.提供者與消費(fèi)者

在服務(wù)調(diào)用關(guān)系中，會(huì)有兩個(gè)不同的角色：

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

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

但是，服務(wù)提供者與服務(wù)消費(fèi)者的角色并不是絕對(duì)的，而是相對(duì)于業(yè)務(wù)而言。

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

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

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

因此，服務(wù)B既可以是服務(wù)提供者，也可以是服務(wù)消費(fèi)者。?

3.Eureka注冊(cè)中心

假如我們的服務(wù)提供者user-service部署了多個(gè)實(shí)例，如圖

大家思考幾個(gè)問(wèn)題：

• order-service在發(fā)起遠(yuǎn)程調(diào)用的時(shí)候，該如何得知user-service實(shí)例的ip地址和端口？

• 有多個(gè)user-service實(shí)例地址，order-service調(diào)用時(shí)該如何選擇？

• order-service如何得知某個(gè)user-service實(shí)例是否依然健康，是不是已經(jīng)宕機(jī)？

3.1.Eureka的結(jié)構(gòu)和作用

這些問(wèn)題都需要利用SpringCloud中的注冊(cè)中心來(lái)解決，其中最廣為人知的注冊(cè)中心就是Eureka，其結(jié)構(gòu)如下：

回答之前的各個(gè)問(wèn)題。

問(wèn)題1：order-service如何得知user-service實(shí)例地址？

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

• user-service服務(wù)實(shí)例啟動(dòng)后，將自己的信息注冊(cè)到eureka-server（Eureka服務(wù)端）。這個(gè)叫服務(wù)注冊(cè)

• eureka-server保存服務(wù)名稱到服務(wù)實(shí)例地址列表的映射關(guān)系

• order-service根據(jù)服務(wù)名稱，拉取實(shí)例地址列表。這個(gè)叫服務(wù)發(fā)現(xiàn)或服務(wù)拉取

問(wèn)題2：order-service如何從多個(gè)user-service實(shí)例中選擇具體的實(shí)例？

• order-service從實(shí)例列表中利用負(fù)載均衡算法選中一個(gè)實(shí)例地址

• 向該實(shí)例地址發(fā)起遠(yuǎn)程調(diào)用

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

• user-service會(huì)每隔一段時(shí)間（默認(rèn)30秒）向eureka-server發(fā)起請(qǐng)求，報(bào)告自己狀態(tài)，稱為心跳

• 當(dāng)超過(guò)一定時(shí)間沒(méi)有發(fā)送心跳時(shí)，eureka-server會(huì)認(rèn)為微服務(wù)實(shí)例故障，將該實(shí)例從服務(wù)列表中剔除

• order-service拉取服務(wù)時(shí)，就能將故障實(shí)例排除了

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

因此，接下來(lái)我們動(dòng)手實(shí)踐的步驟包括：

3.2.搭建eureka-server

首先大家注冊(cè)中心服務(wù)端：eureka-server，這必須是一個(gè)獨(dú)立的微服務(wù)

3.2.1.創(chuàng)建eureka-server服務(wù)

在cloud-demo父工程下，創(chuàng)建一個(gè)子模塊：

3.2.2.引入eureka依賴

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

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

3.2.3.編寫啟動(dòng)類

給eureka-server服務(wù)編寫一個(gè)啟動(dòng)類，一定要添加一個(gè)@EnableEurekaServer注解，開(kāi)啟eureka的注冊(cè)中心功能：

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

3.2.4.編寫配置文件

編寫一個(gè)application.yml文件，內(nèi)容如下：

server:
  port: 10086 #端口
spring:
  application:
    name: eureka-server #服務(wù)名稱
eureka:
  client:
    service-url: 
      defaultZone: http://127.0.0.1:10086/eureka #服務(wù)地址

3.2.5.啟動(dòng)服務(wù)

啟動(dòng)微服務(wù)，然后在瀏覽器訪問(wèn)：http://127.0.0.1:10086

看到下面結(jié)果應(yīng)該是成功了：

3.3.服務(wù)注冊(cè)

下面，我們將user-service注冊(cè)到eureka-server中去。

1）引入依賴

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

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

2）配置文件

在user-service中，修改application.yml文件，添加服務(wù)名稱、eureka地址：

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

3）啟動(dòng)多個(gè)user-service實(shí)例

為了演示一個(gè)服務(wù)有多個(gè)實(shí)例的場(chǎng)景，我們添加一個(gè)SpringBoot的啟動(dòng)配置，再啟動(dòng)一個(gè)user-service。

首先，復(fù)制原來(lái)的user-service啟動(dòng)配置：

然后，在彈出的窗口中，填寫信息：

現(xiàn)在，SpringBoot窗口會(huì)出現(xiàn)兩個(gè)user-service啟動(dòng)配置：

啟動(dòng)兩個(gè)user-service實(shí)例：

查看eureka-server管理頁(yè)面：

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

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

1）引入依賴 （和前面服務(wù)注冊(cè)一致）

2）配置文件（和前面服務(wù)注冊(cè)一致）

3）服務(wù)拉取和負(fù)載均衡

最后，我們要去eureka-server中拉取user-service服務(wù)的實(shí)例列表，并且實(shí)現(xiàn)負(fù)載均衡。

不過(guò)這些動(dòng)作不用我們?nèi)プ觯恍枰砑右恍┳⒔饧纯伞?/p>

在order-service的OrderApplication中，給RestTemplate這個(gè)Bean添加一個(gè)@LoadBalanced注解：

修改order-service服務(wù)中的cn.itcast.order.service包下的OrderService類中的queryOrderById方法。修改訪問(wèn)的url路徑，用服務(wù)名代替ip、端口：

spring會(huì)自動(dòng)幫助我們從eureka-server端，根據(jù)userservice這個(gè)服務(wù)名稱，獲取實(shí)例列表，而后完成負(fù)載均衡。

4.Ribbon負(fù)載均衡

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

4.1.負(fù)載均衡原理

SpringCloud底層其實(shí)是利用了一個(gè)名為Ribbon的組件，來(lái)實(shí)現(xiàn)負(fù)載均衡功能的。

?那么我們發(fā)出的請(qǐng)求明明是http://userservice/user/1，怎么變成了http://localhost:8081的呢？

4.2.源碼跟蹤

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

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

1）LoadBalancerIntercepor

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

• request.getURI()：獲取請(qǐng)求uri，本例中就是 http://user-service/user/8

• originalUri.getHost()：獲取uri路徑的主機(jī)名，其實(shí)就是服務(wù)id，user-service

• this.loadBalancer.execute()：處理服務(wù)id，和用戶請(qǐng)求。

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

2）LoadBalancerClient

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

代碼是這樣的：

• getLoadBalancer(serviceId)：根據(jù)服務(wù)id獲取ILoadBalancer，而ILoadBalancer會(huì)拿著服務(wù)id去eureka中獲取服務(wù)列表并保存起來(lái)。

• getServer(loadBalancer)：利用內(nèi)置的負(fù)載均衡算法，從服務(wù)列表中選擇一個(gè)。本例中，可以看到獲取了8082端口的服務(wù)

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

果然實(shí)現(xiàn)了負(fù)載均衡。

3）負(fù)載均衡策略IRule

在剛才的代碼中，可以看到獲取服務(wù)使通過(guò)一個(gè)getServer方法來(lái)做負(fù)載均衡:

?

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

我們看看這個(gè)rule是誰(shuí)：

?這里的rule默認(rèn)值是一個(gè)RoundRobinRule，看類的介紹：

這不就是輪詢的意思嘛。

到這里，整個(gè)負(fù)載均衡的流程我們就清楚了。

4）總結(jié)

?SpringCloudRibbon的底層采用了一個(gè)攔截器，攔截了RestTemplate發(fā)出的請(qǐng)求，對(duì)地址做了修改。用一幅圖來(lái)總結(jié)一下：

基本流程如下：

• 攔截我們的RestTemplate請(qǐng)求http://userservice/user/1

• RibbonLoadBalancerClient會(huì)從請(qǐng)求url中獲取服務(wù)名稱，也就是user-service

• DynamicServerListLoadBalancer根據(jù)user-service到eureka拉取服務(wù)列表

• eureka返回列表，localhost:8081、localhost:8082

• IRule利用內(nèi)置負(fù)載均衡規(guī)則，從列表中選擇一個(gè)，例如localhost:8081

• RibbonLoadBalancerClient修改請(qǐng)求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，發(fā)起真實(shí)請(qǐng)求

4.3.負(fù)載均衡策略

4.3.1.負(fù)載均衡策略

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

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

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

4.3.2.自定義負(fù)載均衡策略

通過(guò)定義IRule實(shí)現(xiàn)可以修改負(fù)載均衡規(guī)則，有兩種方式：

1. 代碼方式：在order-service中的OrderApplication類中，定義一個(gè)新的IRule：

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

?2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改規(guī)則：

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

注意，一般用默認(rèn)的負(fù)載均衡規(guī)則，不做修改。 ?

4.4.饑餓加載

Ribbon默認(rèn)是采用懶加載，即第一次訪問(wèn)時(shí)才會(huì)去創(chuàng)建LoadBalanceClient，請(qǐng)求時(shí)間會(huì)很長(zhǎng)。

而饑餓加載則會(huì)在項(xiàng)目啟動(dòng)時(shí)創(chuàng)建，降低第一次訪問(wèn)的耗時(shí)，通過(guò)下面配置開(kāi)啟饑餓加載：

ribbon:
  eager-load:
    enabled: true
    clients: userservice

5.Nacos注冊(cè)中心

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

5.1.認(rèn)識(shí)和安裝Nacos

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

5.2.服務(wù)注冊(cè)到nacos

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

主要差異在于：

• 依賴不同

• 服務(wù)地址不同

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）重啟

重啟微服務(wù)后，登錄nacos管理頁(yè)面，可以看到微服務(wù)信息：

5.3.服務(wù)分級(jí)存儲(chǔ)模型

一個(gè)服務(wù)可以有多個(gè)實(shí)例，例如我們的user-service，可以有:

• 127.0.0.1:8081

• 127.0.0.1:8082

• 127.0.0.1:8083

假如這些實(shí)例分布于全國(guó)各地的不同機(jī)房，例如：

• 127.0.0.1:8081，在上海機(jī)房

• 127.0.0.1:8082，在上海機(jī)房

• 127.0.0.1:8083，在杭州機(jī)房

Nacos就將同一機(jī)房?jī)?nèi)的實(shí)例 劃分為一個(gè)集群。

也就是說(shuō)，user-service是服務(wù)，一個(gè)服務(wù)可以包含多個(gè)集群，如杭州、上海，每個(gè)集群下可以有多個(gè)實(shí)例，形成分級(jí)模型，如圖：

?

微服務(wù)互相訪問(wèn)時(shí)，應(yīng)該盡可能訪問(wèn)同集群實(shí)例，因?yàn)楸镜卦L問(wèn)速度更快。當(dāng)本集群內(nèi)不可用時(shí)，才訪問(wèn)其它集群。例如：

5.3.1.給user-service配置集群

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

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

重啟兩個(gè)user-service實(shí)例后，我們可以在nacos控制臺(tái)看到下面結(jié)果：

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

默認(rèn)的ZoneAvoidanceRule并不能實(shí)現(xiàn)根據(jù)同集群優(yōu)先來(lái)實(shí)現(xiàn)負(fù)載均衡。

因此Nacos中提供了一個(gè)NacosRule的實(shí)現(xiàn)，可以優(yōu)先從同集群中挑選實(shí)例。

1）給order-service配置集群信息

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

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

2）修改負(fù)載均衡規(guī)則

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

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

5.4.權(quán)重配置

實(shí)際部署中會(huì)出現(xiàn)這樣的場(chǎng)景：

服務(wù)器設(shè)備性能有差異，部分實(shí)例所在機(jī)器性能較好，另一些較差，我們希望性能好的機(jī)器承擔(dān)更多的用戶請(qǐng)求。

但默認(rèn)情況下NacosRule是同集群內(nèi)隨機(jī)挑選，不會(huì)考慮機(jī)器的性能問(wèn)題。

因此，Nacos提供了權(quán)重配置來(lái)控制訪問(wèn)頻率，權(quán)重越大則訪問(wèn)頻率越高。

在nacos控制臺(tái)，找到user-service的實(shí)例列表，點(diǎn)擊編輯，即可修改權(quán)重：

?在彈出的編輯窗口，修改權(quán)重：

注意：如果權(quán)重修改為0，則該實(shí)例永遠(yuǎn)不會(huì)被訪問(wèn)

5.5.環(huán)境隔離

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

• nacos中可以有多個(gè)namespace

• namespace下可以有g(shù)roup、service等

• 不同namespace之間相互隔離，例如不同namespace的服務(wù)互相不可見(jiàn)

5.5.1.創(chuàng)建namespace

?默認(rèn)情況下，所有service、data、group都在同一個(gè)namespace，名為public：

我們可以點(diǎn)擊頁(yè)面新增按鈕，添加一個(gè)namespace：

5.5.2.給微服務(wù)配置namespace

給微服務(wù)配置namespace只能通過(guò)修改配置來(lái)實(shí)現(xiàn)。

例如，修改order-service的application.yml文件：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空間，填I(lǐng)D

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

Nacos的服務(wù)實(shí)例分為兩種l類型：

• 臨時(shí)實(shí)例：如果實(shí)例宕機(jī)超過(guò)一定時(shí)間，會(huì)從服務(wù)列表剔除，默認(rèn)的類型。

• 非臨時(shí)實(shí)例：如果實(shí)例宕機(jī)，不會(huì)從服務(wù)列表剔除，也可以叫永久實(shí)例。

配置一個(gè)服務(wù)實(shí)例為永久實(shí)例：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 設(shè)置為非臨時(shí)實(shí)例

Nacos和Eureka整體結(jié)構(gòu)類似，服務(wù)注冊(cè)、服務(wù)拉取、心跳等待，但是也存在一些差異：

• Nacos與eureka的共同點(diǎn)

  • 都支持服務(wù)注冊(cè)和服務(wù)拉取

  • 都支持服務(wù)提供者心跳方式做健康檢測(cè)

• Nacos與Eureka的區(qū)別

  • Nacos支持服務(wù)端主動(dòng)檢測(cè)提供者狀態(tài)：臨時(shí)實(shí)例采用心跳模式，非臨時(shí)實(shí)例采用主動(dòng)檢測(cè)模式

  • 臨時(shí)實(shí)例心跳不正常會(huì)被剔除，非臨時(shí)實(shí)例則不會(huì)被剔除

  • Nacos支持服務(wù)列表變更的消息推送模式，服務(wù)列表更新更及時(shí)

  • Nacos集群默認(rèn)采用AP方式，當(dāng)集群中存在非臨時(shí)實(shí)例時(shí)，采用CP模式；Eureka采用AP方式文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-716501.html

到了這里，關(guān)于【微服務(wù)開(kāi)篇-RestTemplate服務(wù)調(diào)用、Eureka注冊(cè)中心、Nacos注冊(cè)中心】的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！