Why
服務(wù)多了，需要統(tǒng)一的管理
為了更好地查找這些服務(wù)
1、為什么要將服務(wù)注冊(cè)到nacos?
之前的痛點(diǎn)
● 需要手動(dòng)的維護(hù)所有的服務(wù)訪問(wèn)ip地址列表。
● 單個(gè)服務(wù)實(shí)現(xiàn)負(fù)載均衡需要自己搭建，例如使用nginx負(fù)載均衡策略，或者基于容器化多實(shí)例部署單個(gè)服務(wù)，在實(shí)例之間做負(fù)載均衡。
使用注冊(cè)中心能夠?qū)崿F(xiàn)服務(wù)治理，服務(wù)動(dòng)態(tài)擴(kuò)容，以及服務(wù)調(diào)用的負(fù)載均衡

● 服務(wù)提供者：向注冊(cè)中心根據(jù)服務(wù)名稱提供服務(wù)訪問(wèn)的ip:port以及其他信息。
● 注冊(cè)中心：根據(jù)服務(wù)名稱，存儲(chǔ)對(duì)應(yīng)的ip:port以及其他信息。
● 服務(wù)消費(fèi)者：根據(jù)服務(wù)名向注冊(cè)中心獲取調(diào)用服務(wù)的ip:port以及其他相關(guān)的信息集合，然后根據(jù)負(fù)載均衡策略獲取最終的服務(wù)器ip：port訪問(wèn)地址。

為了更好的查找這些服務(wù)。

2、Nacos服務(wù)是如何判定服務(wù)實(shí)例的狀態(tài)？
通過(guò)發(fā)送心跳包，5秒發(fā)送一次，如果15秒沒(méi)有回應(yīng)，則說(shuō)明服務(wù)出現(xiàn)了問(wèn)題，
如果30秒后沒(méi)有回應(yīng)，則說(shuō)明服務(wù)已經(jīng)停止。

服務(wù)（Service）是 Nacos 世界的一等公民

Nacos 支持基于 DNS 和基于 RPC 的服務(wù)發(fā)現(xiàn)。服務(wù)提供者使用 原生SDK、OpenAPI、或一個(gè)獨(dú)立的Agent TODO注冊(cè)Service 后，服務(wù)消費(fèi)者可以使用DNS TODO 或HTTP&API查找和發(fā)現(xiàn)服務(wù)。

還可以進(jìn)行健康檢查
What
一、什么是注冊(cè)中心：
我們知道微服務(wù)彼此間獨(dú)立部署、具有清晰的邊界，服務(wù)間通過(guò)遠(yuǎn)程調(diào)用來(lái)構(gòu)建復(fù)雜的業(yè)務(wù)功能。而服務(wù)冊(cè)中心在微服務(wù)項(xiàng)目中扮演著非常重要的角色，那么注冊(cè)中心又是什么，使用服務(wù)注冊(cè)中心可以解決微服務(wù)中的哪些問(wèn)題呢？

1、什么是注冊(cè)中心：
注冊(cè)中心是微服務(wù)架構(gòu)中的紐帶，類似于“通訊錄”，它記錄了服務(wù)和服務(wù)地址的映射關(guān)系。在分布式架構(gòu)中，服務(wù)會(huì)注冊(cè)到這里，當(dāng)服務(wù)需要調(diào)用其它服務(wù)時(shí)，就到這里找到服務(wù)的地址并進(jìn)行調(diào)用。注冊(cè)中心本質(zhì)上是為了解耦服務(wù)提供者和服務(wù)消費(fèi)者。對(duì)于任何一個(gè)微服務(wù)，原則上都應(yīng)存在或者支持多個(gè)提供者，這是由微服務(wù)的分布式屬性決定的，更進(jìn)一步，為了支持彈性擴(kuò)縮容特性，一個(gè)微服務(wù)的提供者的數(shù)量和分布往往是動(dòng)態(tài)變化的，也是無(wú)法預(yù)先確定的。因此，原本在單體應(yīng)用階段常用的靜態(tài)LB機(jī)制就不再適用了，需要引入額外的組件來(lái)管理微服務(wù)提供者的注冊(cè)與發(fā)現(xiàn)，而這個(gè)組件就是服務(wù)注冊(cè)中心。

2、注冊(cè)中心的核心功能：
服務(wù)注冊(cè)：服務(wù)實(shí)例將自身服務(wù)信息注冊(cè)到注冊(cè)中心
服務(wù)發(fā)現(xiàn)：服務(wù)實(shí)例通過(guò)注冊(cè)中心，獲取到注冊(cè)到其中的服務(wù)實(shí)例的信息，通過(guò)這些信息去請(qǐng)求它們提供的服務(wù)
服務(wù)剔除：服務(wù)注冊(cè)中心將出問(wèn)題的服務(wù)自動(dòng)剔除到可用列表之外，使其不會(huì)被調(diào)用到
3、注冊(cè)中心解決的問(wèn)題：
（1）屏蔽、解耦服務(wù)之間相互依賴的細(xì)節(jié)：

    服務(wù)之間的遠(yuǎn)程調(diào)用必須要知道對(duì)方IP、端口。但是該調(diào)用方式存在明顯的問(wèn)題，如被調(diào)用的IP、端口變化后，調(diào)用方也要同步修改。通過(guò)服務(wù)發(fā)現(xiàn)，將服務(wù)之間IP與端口的依賴轉(zhuǎn)化為服務(wù)名的依賴，服務(wù)名可以根據(jù)具體微服務(wù)業(yè)務(wù)來(lái)做標(biāo)識(shí)。

（2）對(duì)服務(wù)進(jìn)行動(dòng)態(tài)管理：

    在微服務(wù)架構(gòu)中，服務(wù)數(shù)量多且依賴錯(cuò)綜復(fù)雜，無(wú)論是服務(wù)主動(dòng)停止、意外掛掉，還是因?yàn)榱髁吭黾訉?duì)服務(wù)擴(kuò)容，這些服務(wù)狀態(tài)上的動(dòng)態(tài)變化，都需要盡快的通知到被調(diào)用方，被調(diào)用方才采取相應(yīng)的措施。所以，對(duì)于服務(wù)注冊(cè)中心要實(shí)時(shí)管理服務(wù)的數(shù)據(jù)與狀態(tài)，包括服務(wù)的注冊(cè)上線、服務(wù)主動(dòng)下線，異常服務(wù)的剔除。

（3）降低服務(wù)端負(fù)載均衡中間件的壓力：

    當(dāng)服務(wù)越來(lái)越多時(shí)，服務(wù) URL 配置管理變得非常困難，服務(wù)端的負(fù)載均衡中間件，比如 F5、Nginx 壓力也越來(lái)越大。通過(guò)服務(wù)注冊(cè)中心，就可以實(shí)現(xiàn)動(dòng)態(tài)地注冊(cè)和發(fā)現(xiàn)服務(wù)，使服務(wù)的位置透明，并通過(guò)在消費(fèi)方獲取服務(wù)提供方地址列表，實(shí)現(xiàn)軟負(fù)載均衡和 Failover，降低對(duì)服務(wù)端的負(fù)載均衡中間件，也能減少部分成本。

4、服務(wù)的發(fā)現(xiàn)與注冊(cè)的實(shí)現(xiàn)模式：
上面提到，硬件的 F5、軟件的 Nginx 也可以實(shí)現(xiàn)服務(wù)的發(fā)現(xiàn)，那么這與注冊(cè)中心的服務(wù)發(fā)現(xiàn)有什么區(qū)別呢？這其實(shí)是服務(wù)發(fā)現(xiàn)與注冊(cè)的兩種實(shí)現(xiàn)模式：服務(wù)端的發(fā)現(xiàn)模式 和 客戶端的發(fā)現(xiàn)模式。F5、Nginx 屬于服務(wù)端的發(fā)現(xiàn)模式，服務(wù)注冊(cè)中心屬于客戶端的發(fā)現(xiàn)模式，兩種模式各有優(yōu)缺點(diǎn)，也適用于不同的場(chǎng)景，對(duì)于大型應(yīng)用一般會(huì)有多層負(fù)載，外層用服務(wù)器端負(fù)載均衡，內(nèi)部用客戶端負(fù)載均衡。接下來(lái)我們就具體看看兩種服務(wù)發(fā)現(xiàn)模式是怎么樣的：

（1）服務(wù)端的發(fā)現(xiàn)模式：

    服務(wù)端的發(fā)現(xiàn)模式是通過(guò)使用一個(gè)中間的服務(wù)器，來(lái)屏蔽被調(diào)用服務(wù)的復(fù)雜性與變動(dòng)性，當(dāng)有新的服務(wù)加入或老服務(wù)剔除時(shí)，只需要修改中間服務(wù)器上的配置即可，此模式的顯著特點(diǎn)是：引入獨(dú)立的中間代理服務(wù)器來(lái)屏蔽真實(shí)服務(wù)的具體細(xì)節(jié)。

    如下圖所示：當(dāng)服務(wù)A要調(diào)用服務(wù)B時(shí)，先通過(guò) DNS 域名解析找到 Nginx 服務(wù)器，然后將請(qǐng)求發(fā)送給Nginx，因?yàn)樵?Nginx 上配置了服務(wù)B的真實(shí)訪問(wèn)地址，Nginx 收到請(qǐng)求后根據(jù)負(fù)載均衡算法，將請(qǐng)求轉(zhuǎn)發(fā)到某個(gè)真實(shí)的服務(wù)B，服務(wù)B將請(qǐng)求結(jié)果返回給 Nginx，Nginx 再將返回結(jié)果給服務(wù)A，整個(gè)請(qǐng)求流程結(jié)束。當(dāng)然中間服務(wù)器不一定非得是 Nginx，還可以是基于硬件的 F5，也可以是工作在傳輸層的 IP 負(fù)載均衡等。

    該模式的優(yōu)點(diǎn)是：配置集中在獨(dú)立的中間服務(wù)器端完成，對(duì)代碼沒(méi)有任何入侵，也不存在跨平臺(tái)跨語(yǔ)言的問(wèn)題。但缺點(diǎn)也很明顯，因?yàn)樗姓?qǐng)求都需要穿透中間服務(wù)器，所以中間服務(wù)器會(huì)成為一個(gè)單點(diǎn)，對(duì)性能也會(huì)有所影響。

（2）客戶端的發(fā)現(xiàn)模式：

    我們?cè)倏纯纯蛻舳说陌l(fā)現(xiàn)模式，服務(wù)A調(diào)用服務(wù)B時(shí)，不需要通過(guò)中間服務(wù)器，而是在自己進(jìn)程內(nèi)維護(hù)了服務(wù)B的信息，再通過(guò)負(fù)載算法選擇一個(gè)服務(wù)B直接調(diào)用。那服務(wù)A具體是怎么維護(hù)服務(wù)B的信息呢？為此引入了服務(wù)注冊(cè)中心的概念，當(dāng)服務(wù)B啟動(dòng)時(shí)向注冊(cè)中心注冊(cè)自己（將自己的信息發(fā)送到注冊(cè)中心的注冊(cè)表里），服務(wù)A再?gòu)淖?cè)中心獲取所有注冊(cè)的服務(wù)，這就是客戶端模式的基本原理。

    客戶端模式因?yàn)樵谶M(jìn)程內(nèi)直接調(diào)用服務(wù)，也叫做進(jìn)程內(nèi)負(fù)載，由于不需要穿透中間服務(wù)器，所以客戶端模式的性能損耗比較小。但是，需要在服務(wù)內(nèi)部維護(hù)服務(wù)注冊(cè)信息，負(fù)載算法等，有一定的代碼入侵性，對(duì)于跨平臺(tái)，跨語(yǔ)言的支持不太友好。

5、服務(wù)注冊(cè)表：
微服務(wù)架構(gòu)中，所有的服務(wù)啟動(dòng)后都通過(guò)注冊(cè)中心來(lái)注冊(cè)自己，同時(shí)把注冊(cè)中心里面的服務(wù)信息拉回本地，后續(xù)調(diào)用時(shí)就直接檢查本地的服務(wù)和節(jié)點(diǎn)信息來(lái)進(jìn)行服務(wù)節(jié)點(diǎn)的調(diào)用。每個(gè)服務(wù)節(jié)點(diǎn)都會(huì)來(lái)注冊(cè)中心進(jìn)行服務(wù)注冊(cè)，那注冊(cè)信息是如何在服務(wù)端保存的呢，其實(shí)就是注冊(cè)表，服務(wù)注冊(cè)的時(shí)候把自己的信息上報(bào)上來(lái)，然后注冊(cè)中心把注冊(cè)表，返回給客戶端，那服務(wù)之間就知道要調(diào)用服務(wù)的節(jié)點(diǎn)了。

    服務(wù)注冊(cè)表需要高可用而且隨時(shí)更新?？蛻舳四軌蚓彺鎻姆?wù)注冊(cè)表中獲取的服務(wù)地址，然而，這些信息最終會(huì)過(guò)時(shí)，客戶端也就無(wú)法發(fā)現(xiàn)服務(wù)實(shí)例。因此，服務(wù)注冊(cè)表會(huì)包含若干服務(wù)端，并使用復(fù)制協(xié)議保持一致性。服務(wù)注冊(cè)表不能是單點(diǎn)，否則存在單點(diǎn)故障，當(dāng)服務(wù)注冊(cè)表有多臺(tái)服務(wù)器的時(shí)需要考慮服務(wù)注冊(cè)表的信息在多臺(tái)機(jī)器上的實(shí)時(shí)同步和一致。

二、主流服務(wù)注冊(cè)中心的對(duì)比：

（1）Zookeeper 和 Consul 遵循 CP 原則，保證了強(qiáng)一致性和分區(qū)容錯(cuò)性，放棄可用性，在分布式環(huán)境中，如果涉及數(shù)據(jù)存儲(chǔ)的場(chǎng)景，數(shù)據(jù)一致性應(yīng)該是首先被保證的，但對(duì)于服務(wù)發(fā)現(xiàn)來(lái)說(shuō)，可用性才是最核心的，針對(duì)同一個(gè)服務(wù)，即使注冊(cè)中心的不同節(jié)點(diǎn)保存的服務(wù)提供者信息不相同，也并不會(huì)造成災(zāi)難性的后果。因?yàn)閷?duì)于服務(wù)消費(fèi)者來(lái)說(shuō)，能消費(fèi)才是最重要的，消費(fèi)者拿到不正確的服務(wù)實(shí)例信息后嘗試消費(fèi)一下，也勝過(guò)因?yàn)闊o(wú)法獲取實(shí)例信息而不去消費(fèi)而導(dǎo)致系統(tǒng)異常

（2）Eureka 遵循 AP 原則，保證可用性，放棄數(shù)據(jù)一致性，基本能滿足注冊(cè)中心所需的核心功能，但 Eureka 2.x 版本已停止開(kāi)發(fā)，并且宣布如果繼續(xù)使用的話，風(fēng)險(xiǎn)自負(fù)。

（3）Nacos 同時(shí)支持 AP 與 CP，默認(rèn)是 AP，同時(shí)功能更豐富，與 SpringCloud Alibaba 的兼容性更好，使用更簡(jiǎn)單靈活，可以滿足更多的業(yè)務(wù)場(chǎng)景，且支持 K8S 的集成。

不同的服務(wù)注冊(cè)中心組件的應(yīng)用場(chǎng)景不同，讀者可以根據(jù)自己的業(yè)務(wù)情況進(jìn)行選型。但下文我們主要以 Nacos 注冊(cè)中心為例進(jìn)行介紹，其他幾種注冊(cè)中心讀者自行上網(wǎng)查閱
————————————————
版權(quán)聲明：本文為CSDN博主「張維鵬」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/a745233700/article/details/122915663
How
https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html
1、添加依賴
spring-cloud-starter-alibaba-nacos-discovery
2、配置服務(wù)提供者，從而服務(wù)提供者可以通過(guò)nacos的服務(wù)注冊(cè)發(fā)現(xiàn)功能將其服務(wù)注冊(cè)安東nacos server上
3、Application.yml配置nacos server地址

或者
server:
port: 31511

spring:
application:
name: @artifactId@
cloud:
nacos:
discovery:
server-addr:
register-enabled: true
namespace: sw-saas
metadata:

客戶端向 nacos 服務(wù)器上報(bào)心跳包的時(shí)間間隔

preserved.heart.beat.interval: 5000

客戶端不發(fā)送心跳后，從健康到不健康的時(shí)間

preserved.heart.beat.timeout: 5000

不發(fā)送心跳后，被 nacos下掉該實(shí)例的時(shí)間

  preserved.ip.delete.timeout: 5000

config:
server-addr: ${spring.cloud.nacos.discovery.server-addr}
file-extension: yml
namespace: sw-saas

4、通過(guò)注解@EnableDiscoveryClient開(kāi)啟服務(wù)注冊(cè)發(fā)現(xiàn)
@SpringBootApplication
@EnableDiscoveryClient
public class NacosProviderApplication {

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

@RestController
class EchoController {
@RequestMapping(value = “/echo/{string}”, method = RequestMethod.GET)
public String echo(@PathVariable String string) {
return "Hello Nacos Discovery " + string;
}
}
}

5、配置服務(wù)消費(fèi)者，從而服務(wù)消費(fèi)者可以通過(guò)nacos的服務(wù)注冊(cè)發(fā)現(xiàn)功能從nacos sever上獲取到它要調(diào)用的服務(wù)。

6、通過(guò)注解@EnavleDiscoveryClient開(kāi)啟服務(wù)注冊(cè)發(fā)現(xiàn)功能。給RestTemplate實(shí)例添加@LoadBlanced注解，開(kāi)啟@LoadBalanced與與 Ribbon 的集成：
@SpringBootApplication
@EnableDiscoveryClient
public class NacosConsumerApplication {

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

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

@RestController
public class TestController {

private final RestTemplate restTemplate;

@Autowired
public TestController(RestTemplate restTemplate) {this.restTemplate = restTemplate;}

@RequestMapping(value = “/echo/{str}”, method = RequestMethod.GET)
public String echo(@PathVariable String str) {
return restTemplate.getForObject(“http://service-provider/echo/” + str, String.class);
}
}
}
Where
Network服務(wù)

nacos注冊(cè)中心的注冊(cè)原理
https://blog.csdn.net/qq_36893229/article/details/120201306

SpringBoot 整合 Nacos 進(jìn)行服務(wù)注冊(cè)發(fā)現(xiàn)：

我們首先看一下 nacos 的簡(jiǎn)單架構(gòu)圖：

參照上面的架構(gòu)圖，我們分別創(chuàng)建兩個(gè)模塊，分別是 cloud-producer-server（服務(wù)提供者）、cloud-consumer（服務(wù)消費(fèi)者），職責(zé)如下：

cloud-producer-server：注冊(cè)進(jìn)入nacos-server，對(duì)外暴露服務(wù)
cloud-consumer：注冊(cè)進(jìn)入nacos-server，調(diào)用 cloud-producer-server 的服務(wù)
創(chuàng)建這兩個(gè)模塊前，我們先聲明項(xiàng)目的版本信息：

（2）添加 nacos 相關(guān)的配置信息：

在 application.properties 配置文件指定服務(wù)名稱、端口號(hào)、nacos-server 的地址信息，如下：

spring.application.name = cloud-producer-server
server.servlet.context-path = /${spring.application.name}
server.port=9000

nacos注冊(cè)中心配置

spring.cloud.nacos.discovery.server-addr = localhost:8848
spring.cloud.nacos.discovery.namespace = 91b5489b-d009-4725-86fa-534f760b4d04
spring.cloud.nacos.discovery.register-enabled = true
（3）開(kāi)啟服務(wù)注冊(cè)發(fā)現(xiàn)的功能：

在主 Application 啟動(dòng)類加入 @EnableDiscoveryClient 注解開(kāi)啟服務(wù)注冊(cè)發(fā)現(xiàn)的功能，如下：

/**

● SpringBoot啟動(dòng)類
● @EnableDiscoveryClient 開(kāi)啟服務(wù)注冊(cè)發(fā)現(xiàn)的功能
*/
@EnableDiscoveryClient
@SpringBootApplication
public class ProducerApplication
{
public static void main(String[] args)
{
SpringApplication.run(ProducerApplication.class, args);
}
}
（4）實(shí)現(xiàn)個(gè)演示功能：
cloud-producer-server 作為服務(wù)提供者注冊(cè)到 nacos 中，肯定需要提供個(gè)服務(wù)來(lái)供消費(fèi)者 cloud-consumer 調(diào)用，下面簡(jiǎn)單寫(xiě)一個(gè)演示接口：

@RestController
@RequestMapping (value = “/”)
public class CloudController
{
@PostMapping (“getSum”)
public String getSum(@RequestParam (value = “num1”) Integer num1, @RequestParam (value = “num2”) Integer num2)
{
return “success：兩數(shù)求和結(jié)果=” + (num1 + num2);
}
}
（5）啟動(dòng)項(xiàng)目：

啟動(dòng)項(xiàng)目之后，我們進(jìn)入 nacos 控制臺(tái)，在 nacos 的 “服務(wù)管理->服務(wù)列表” 的 “91b5489b-d009-4725-86fa-534f760b4d04” 空間中將會(huì)發(fā)現(xiàn)注冊(cè)進(jìn)入的 cloud-producer-server 這個(gè)服務(wù)，如下圖：

2.2、創(chuàng)建服務(wù)消費(fèi)者 cloud-consumer：
服務(wù)消費(fèi)者的創(chuàng)建步驟與服務(wù)提供者基本一致

（1）引入maven依賴：

（2）添加 nacos 相關(guān)的配置信息：

spring.application.name = cloud-consumer
server.port=9001

nacos注冊(cè)中心配置

spring.cloud.nacos.discovery.server-addr = localhost:8848
spring.cloud.nacos.discovery.namespace = 91b5489b-d009-4725-86fa-534f760b4d04
spring.cloud.nacos.discovery.register-enabled = true
（3）開(kāi)啟服務(wù)注冊(cè)發(fā)現(xiàn)的功能：

/**

● SpringBoot啟動(dòng)類
● @EnableDiscoveryClient 開(kāi)啟服務(wù)注冊(cè)發(fā)現(xiàn)的功能
*/
@EnableDiscoveryClient
@SpringBootApplication
public class ConsumerApplication
{
public static void main(String[] args)
{
SpringApplication.run(ConsumerApplication.class, args);
}
}
（4）調(diào)用服務(wù)提供方的演示功能：
cloud-producer-server 服務(wù)提供方提供一個(gè)演示功能，那我們?nèi)绾握{(diào)用該功能呢？其實(shí) Nacos 集成了 Ribbon（有關(guān) Ribbon 的詳細(xì)介紹請(qǐng)參考這篇文章：https://blog.csdn.net/a745233700/article/details/122916856），因此我們便能使用 Ribbon 的負(fù)載均衡來(lái)調(diào)用服務(wù)，步驟如下：

① 創(chuàng)建 RestTemplate，使用 @LoadBalanced 注解標(biāo)注開(kāi)啟負(fù)載均衡：

@Configuration
public class RestConfig
{
/**

• 創(chuàng)建restTemplate對(duì)象。
• LoadBalanced注解表示賦予restTemplate使用Ribbon的負(fù)載均衡的能力（一定要加上注解，否則無(wú)法遠(yuǎn)程調(diào)用）
  */
  @Bean
  @LoadBalanced
  public RestTemplate restTemplate(){
  return new RestTemplate();
  }
  }
  ② 通過(guò) RestTemplate 請(qǐng)求遠(yuǎn)程服務(wù)地址并接收返回值

@RestController
@RequestMapping (value = “api/invoke”)
public class InvokeController
{
@Autowired
private RestTemplate restTemplate;

/**

• 使用 RestTemplate 進(jìn)行遠(yuǎn)程服務(wù)調(diào)用，并且使用 Ribbon 進(jìn)行負(fù)載均衡
  */
  @ApiOperation (value = “RestTemplate”, notes = “使用RestTemplate進(jìn)行遠(yuǎn)程服務(wù)調(diào)用，并使用Ribbon進(jìn)行負(fù)載均衡”)
  @GetMapping (“getByRestTemplate”)
  public String getByRestTemplate(Integer num1, Integer num2)
  {
  //第一個(gè)cloud-producer-server代表在nacos注冊(cè)中心中的服務(wù)名，第二個(gè)cloud-producer-server代表contextPath配置的項(xiàng)目路徑
  String url = “http://cloud-producer-server/cloud-producer-server/getSum”;
  MultiValueMap<String, Object> params = new LinkedMultiValueMap<>();
  params.add(“num1”, num1);
  params.add(“num2”, num2);

  //通過(guò)服務(wù)名的方式調(diào)用遠(yuǎn)程服務(wù)（非ip端口）
  return restTemplate.postForObject(url, params, String.class);
  }

}

（5）啟動(dòng)測(cè)試，查看nacos注冊(cè)中心控制面板情況

啟動(dòng)成功后將會(huì)在 nacos 中的服務(wù)列表中看到 cloud-consumer，如下圖：

那么接下來(lái)就測(cè)試下服務(wù)能否調(diào)的通？訪問(wèn)服務(wù)消費(fèi)方的 api/invoke/getByRestTemplate接口，可以看到請(qǐng)求結(jié)果如下：

————————————————
版權(quán)聲明：本文為CSDN博主「張維鵬」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/a745233700/article/details/122915663

擴(kuò)展
nginx完成Nacos的負(fù)載均衡，mysql實(shí)現(xiàn)主從復(fù)制 （Nacos集群讀取共享數(shù)據(jù)）
1、輪詢（默認(rèn)策略，nginx自帶策略）：輪詢的方式，它是upstream模塊默認(rèn)的負(fù)載均衡默認(rèn)策略。會(huì)將每個(gè)請(qǐng)求按時(shí)間順序分配到不同的后端服務(wù)器。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-824155.html

到了這里，關(guān)于原理底層計(jì)劃----注冊(cè)中心Nacos的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！