Nacos(Naming Configuration Service) 是一个易于使用的动态服务发现、配置和服务管理平台,用于构建云原生应用程序
服务发现是微服务架构中的关键组件之一。Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施
Nacos = 注册中心+配置中心组合
Nacos支持几乎所有主流类型的“服务”的发现、配置和管理,常见的服务如下:
Kubernetes Service
gRPC & Dubbo RPC Service
Spring Cloud RESTful Servic
官网地址:https://nacos.io/zh-cn/index.html
官方文档地址:https://nacos.io/zh-cn/docs/quick-start.html
注意使用官网推荐的地址
下载地址:https://github.com/alibaba/nacos/releases
我们以Windos版本为案例
1.Linux/Unix/Mac
启动命令(standalone代表着单机模式运行,非集群模式):
sh startup.sh -m standalone
2.Windows
启动命令(standalone代表着单机模式运行,非集群模式):
startup.cmd -m standalone
3.测试验证结果
4.出现此界面表示已经成功启动Nacos,默认的账号密码是:nacos/nacos
Please set the JAVA_HOME variable in your environment, We need java(x64)! jdk8 or later is better!
大概意思找不到JAVA_HOME 环境变量,正常情况我们做开发的肯定本地都有配置JDK,首先看下版本是不是jdk8版本。如果本地都有环境变量,版本也一致,修改启动脚本startup.cmd
修改文件的第14行增加set JAVA_HOME=“D:\soft\Java\jdk1.8.0_281”。自己的路径
官方文档地址:https://spring.io/projects/spring-cloud-alibaba#learn
本案例采用maven的聚合项目
引入依赖
引入依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
在我们的启动类上面增加相关注解
@EnableDiscoveryClient
修改配置文件
server:
port: 9001
spring:
application:
name: nacos-payment-provider
cloud:
nacos:
discovery:
server-addr: localhost:8848
management:
endpoints:
web:
exposure:
include: '*'
启动测试查看子项目是否注册到Nacosz服务上。
注意:保证我们的Nacos服务正常启动
子项目已经注册进去了
它是一个基于HTTP和TCP客户端负载均衡器。它虽然只是一个工具类库,它却是每一个微服务的基础设施。因为实际上,对于服务间调用、API网关请求转发都需要经过Ribbon负载均衡来实现。总体来说,Ribbon的主要作用是:从注册服务器端拿到对应服务列表后以负载均衡的方式访问对应服务
要注意的是Nacos已经整合了Ribbon,所以我们想要使用只需要导入Spring Cloud Alibaba Nacos的依赖就可以直接使用了
我们按照上一步,复制9001项目,修改配置文件端口为9002。启动后我们发现Nacos会有两个注册实例。然后我们搭建消费者服务去调用9001和9002的接口。以此来实现软件层面的负载均衡效果。
注意父项目的pom文件需要增加modules模块
<modules>
<module>cloudalibaba-nacos-9001</module>
<module>cloudalibaba-nacos-9002</module>
<module>cloudalibaba-consumer-nacos-8083</module>
</modules>
启动类增加相关注解
@EnableDiscoveryClient
RestTemplate 需要交给Spring管理
必须要加@LoadBalanced注解
什么是@LoadBalanced注解,@LoadBalanced注解的使用?
@LoadBalanced是Spring Cloud中提供的一个注解,它用于将一个RestTemplate对象标记为支持负载均衡的,从而可以针对服务名称进行REST调用。
在Spring Cloud中,当通过服务名称进行REST调用时,RestTemplate对象会使用负载均衡算法来选择目标服务的实例。@LoadBalanced注解用于为RestTemplate对象增加这个支持负载均衡的特性,从而实现在服务调用时进行负载均衡,而不是简单的IP地址访问。
@SpringBootApplication
@EnableDiscoveryClient
public class ColudNacosConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ColudNacosConsumerApplication.class, args);
}
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
}
说明9001,9002,9003已经成功注册进去。
需要远程访问那么可以使用RestTemplate,其中getForObject是最常用方法,同时还要在服务消费者中配置RestTemplate
@Resource
private RestTemplate restTemplate;
@GetMapping("/nacos-consumer")
public String demo(){
return restTemplate.getForObject("http://nacos-payment-provider/demo",String.class);
}
1. url的第一部分是在Nacos中注册的服务提供者名称,如果多个服务提供者注册相同名称,Ribbon会自动寻找其中一个服务提供者,并且调用接口方法。这个就是负载均衡功能。
2. url后半部是控制器的请求路径
JavaBean类型或者JavaBean数组类型,如果控制器返回的是List集合,需要使用数组类型接收。
是传递给url的动态参数,使用参数时候需要在url上需要使用{1}、{2}、{3}进行参数占位,这样传递的参数就会自动替换占位符
如果我们想要让服务消费者consumer-nacos-9003调用服务提供者nacos-9001或者9002,那么必然要使用负载均衡Ribbon和远程调用RestTemplate,所以我们要做的第一件事情就是先让9001或者9002服务对外提供接口,用于访问。
@RestController
public class DemoController {
@GetMapping("/demo")
public String demo(){
return "我是服务提供者端口为9001的demo方法";
}
}
@RestController
public class DemoController {
@GetMapping("/demo")
public String demo(){
return "我是服务提供者端口为9002的demo方法";
}
}
我这里的nacos-payment-provider硬编码了,可以放在配置文件中,具体调用那个服务名称
@Resource
private RestTemplate restTemplate;
@GetMapping("/nacos-consumer")
public String demo(){
return restTemplate.getForObject("http://nacos-payment-provider/demo",String.class);
}
看到浏览器输出的内容会随机打印端口,代表了负载均衡,默认轮询。
服务注册与发现框架 | CAP模型 | 控制台管理 | 社区活跃度 |
---|---|---|---|
Eureka | AP | 支持 | 低(2.x版本闭源) |
Zookeeper | CP | 不支持 | 中 |
Consul | CP | 支持 | 高 |
Nacos | AP/CP | 支持 | 高 |
详细概念可以百度查查。。。。
计算机专家 埃里克·布鲁尔(Eric Brewer)于 2000 年在 ACM 分布式计算机原理专题讨论会(简称:PODC)中提出的分布式系统设计要考虑的三个核心要素:
以上三个特点就是CAP原则(又称CAP定理),但是三个特性不可能同时满足,所以分布式系统设计要考虑的是在满足P(分区容错性)的前提下选择C(一致性)还是A(可用性),即:CP或AP
CP 原则属于强一致性原则,要求所有节点可以查询的数据随时都要保持一直(同步中的数据不可查询),即:若干个节点形成一个逻辑的共享区域,某一个节点更新的数据都会立即同步到其他数据节点之中,当数据同步完成后才能返回成功的结果,但是在实际的运行过程中网络故障在所难免,如果此时若干个服务节点之间无法通讯时就会出现错误,从而牺牲了以可用性原则(A),例如关系型数据库中的事务。
AP原则属于弱一致性原则,在集群中只要有存活的节点那么所发送来的所有请求都可以得到正确的响应,在进行数据同步处理操作中即便某些节点没有成功的实现数据同步也返回成功,这样就牺牲一致性原则(C 原则)。
使用场景:对于数据的同步一定会发出指令,但是最终的节点是否真的实现了同步,并不保证,可是却可以及时的得到数据更新成功的响应,可以应用在网络环境不是很好的场景中。
Nacos无缝支持一些主流的开源生态,同时再阿里进行Nacos设计的时候重复的考虑到了市场化的运作(市面上大多都是以单一的实现形式为主,例如:Zookeeper使用的是 CP、而 Eureka采用的是AP),在Nacos中提供了两种模式的动态切换。
注意:临时和持久化的区别主要在健康检查失败后的表现,持久化实例健康检查失败后会被标记成不健康,而临时实例会直接从列表中被删除。