新建Module：cloudalibaba-provider-payment9002作为服务提供方微服务。当然为了实现Nacos的负载均衡，使nacos-payment-provider服务集群化，我们同事也仿照9002搭建一个9003微服务。
然后在工程的父POM中引入依赖（Spring Cloud Alibaba简介中引入的依赖）的前提下，在该模块的POM引入依赖Nacos服务注册发现的依赖：
<!--SpringCloud ailibaba nacos --> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>然后添加其配置文件application.yml：
server: port: 9002 spring: application: name: nacos-payment-provider # 微服务名称 cloud: nacos: discovery: server-addr: localhost:8848 # 配置Nacos地址 management: endpoints: web: exposure: include: '*' # 监控端点全部打开编写其主启动类并在主启动类上添加 @EnableDiscoveryClient 注解，使9002微服务能够被注册中心发现：
@EnableDiscoveryClient @SpringBootApplication public class PaymentMain9002 { public static void main(String[] args) { SpringApplication.run(PaymentMain9002.class); } }然后编写一个简单的业务类：
@RestController public class PaymentController { @Value("${server.port}") private String serverPort; @GetMapping("/payment/nacos/{id}") public String getPayment(@PathVariable("id") Integer id) { return "Nacos服务注册，端口：" + serverPort + "；id：" + id; } }启动9002、9003微服务模块，在Nacos的服务列表中我们可以看到这两个微服务已经入驻服务注册中心：
点开nacos-payment-provider服务的详情页面，可以看到服务的实例详情：
基于Nacos的服务消费者
新建Module：cloudalibaba-consumer-nacos-order83作为服务消费方微服务，在该模块的POM中同样引入令Nacos服务注册中心发现自己的依赖，配置其配置文件：
server: port: 83 spring: application: name: nacos-order-cosumer cloud: nacos: discovery: server-addr: localhost:8848 # 消费者将要去访问的微服务名称（注册成功进Nacos的微服务提供者） service-url: nacos-user-service:然后编写服务消费方的主启动类，Nacos本身就具有负载均衡功能，因为引入Nacos依赖的同时，Nacos内部集成了Ribbon，如图所示：
而我们在学习Ribbon时知道，用了Ribbon就需要使用 RestTemplate ，所有我们编写配置类，向Spring容器中注入 RestTemplate：
@Configuration public class ApplicationContextConfig { @Bean @LoadBalanced //负载均衡 public RestTemplate getRestTemplate() { return new RestTemplate(); } }注意 注入 RestTemplate 时一定要添加 @LoadBalanced 注解，否则不会开启负载均衡，在服务提供方集群的情况下，由于没有开启负载均衡，消费方会无法选择具体调用哪个微服务实例，也就是服务提供方实例有很多个，而消费方服务不知道要调用哪个具体的服务提供方实例，不加该注解会产生 UnknownHostException 的异常。
然后编写其业务类：
@RestController @Slf4j public class OrderNacosController { @Resource private RestTemplate restTemplate; //直接读取配置文件中的值，减少代码冗余 @Value("${service-url.nacos-user-service}") private String serverURL; @GetMapping("/consumer/payment/nacos/{id}") public String paymentInfo(@PathVariable("id") Long id) { return restTemplate.getForObject(serverURL + "/payment/nacos/" + id, String.class); } }启动83服务消费方，在Nacos服务注册中心中我们可以看到入驻了两个服务提供方实例和一个服务消费方实例。
测试
多次访问 :83/consumer/payment/nacos/1 ，我们发现服务消费方微服务83可以完成对服务提供方微服务9002/9003的轮询负载均衡调用，也就是 Nacos内部就整合了Ribbon，实现了负载均衡，默认负载均衡算法采用轮询。
2.4 各种服务注册中心的对比事实上，Nacos可以在AP模式和CP模式中进行切换，也就是说Nacos不仅仅支持AP（可用性和分区容错性），它同样支持CP（一致性和分区容错性）。当 采取入驻到Nacos服务注册中心的微服务对自己的健康状态进行上报时，也就是对入驻到注册中心的微服务进行非持久化的保存，一旦客户端上报不健康信息，就将不健康的实例摘除掉，这类似于Eureka（当然Eureka可以开启自我保护模式）；当 采取由Nacos服务注册中心自己探测入驻到中心的微服务是否健康时，也就是对入驻到注册中心的微服务进行持久化保存，即使服务注册中心发现微服务已经不健康了，也不会删除到微服务，这类似于Consul。如下图（CoreDNS也是一种服务注册中心）：
