访问nacos上的服务,nacos注册服务访问地址
Nacos服务发现
Nacos 另一个非常重要的特性就是服务注册与发现，说到服务的注册与发现相信大家应该都不陌生，它们是服务治理的最基础功能。
Nacos 支持几乎所有主流类型的 “服务” 的发现、配置和管理。
了解过 Dubbo 的同学，应该对 Dubbo 的架构非常熟悉，最经典的一张架构图如下所示：
图中的6个步骤的含义解释如下：
0、服务容器负责启动，加载，运行服务提供者。
1、服务提供者在启动时，向注册中心注册自己提供的服务。
2、服务消费者在启动时，向注册中心订阅自己所需的服务。
3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。
其中图中最上方的 Registry 就是注册中心，负责服务的注册与发现。Dubbo 有自己的 Registry 实现，而 Nacos 则是另一种 Registry 实现。
相对服务注册而言服务发现就简单很多了。就是Nacos客户端调用Open API或者SDK查询服务列表，服务端接受到请求后根据将查询到服务包装成json格式返回。
既然如此，客户端是啥时候发起服务列表查询？
如果客户端查的时差内，刚好有服务实例有down掉，那客户端的请求岂不是有请求到刚好down的服务实例？下面进行解答。
客户端有一个HostReactor类，在com.alibaba.nacos.client.naming.core包下。
HostReactor它里面有一个UpdateTask线程，每 1s 发送一次pull拉取请求，获取服务最新的地址列表。
更新服务的核心逻辑在updateService方法中：
再看看processServiceJson方法， 本地维护一个MapString,ServiceInfo serviceInfoMap 存储服务信息，同时调用 DiskCache.write(serviceInfo, this.cacheDir) 方法把服务信息写入本地缓存文件中;
服务端采取的是基于push的方式向客户端通知，由于服务端和服务提供者（各个微服务provider）建立了心跳机制，一旦某个服务出现故障，服务端察觉出后，会发送一个push消息给Nacos客户端，也就是我们的消费者。这个push消息是使用DatagramSocket来实现的。
服务消费者收到服务端发来的push消息之后，使用HostReactor中提供的ServiceInfo processServiceJson(String json)方法解析消息，并更新本地服务地址列表。
可以参照下面的图更容易理解服务动态感知原理，包括：客户端主动轮训查询服务列表及服务端Push变故后的服务列表。
【Nacos专题】Nacos 快速入门
Nacos 英文全称 Dynamic Naming and Configuration Service，它是 Spring Cloud Alibaba 的核心组件之一，致力于微服务架构中的服务注册与发现、配置管理。
Nacos 将注册中心和配置中心整合在一起，提供了两个核心功能，即服务注册与发现和动态配置服务。
Nacos 支持基于 DNS 和 基于 RPC 的服务发现，服务提供者向 Nacos 服务端注册服务后，服务消费者可以从 Nacos 服务端获取注册列表。
提供了一个简洁易用的 UI，方便用户管理所有环境的应用配置和服务配置，消除了配置变更时服务需重新部署的过程。还提供了包括 配置版本跟踪 、 金丝雀发布 、 一键回滚配置 以及 客户端配置更新状态跟踪 在内的一系列开箱即用的配置管理特性，大大降低配置变更带来的风险。
Nacos 分为服务端和客户端，服务端用来提供服务发现与注册等功能，客户端就是不同的应用和服务。
在 Nacos 的 Release Notes 可以看到每个版本的相关介绍。当前最新的稳定版本是 1.4.0。
Nacos 服务需要 Java 运行环境，因此，在启动服务之前需要确保你的服务器已经有了 Java 运行环境，并且配置好了 JAVA_HOME 。
参数说明：
-m：指定运行模式，standalone 表示单机模式
在 Nacos 配置文件中配置服务器ip，默认的端口号为8848，默认的用户名和密码均为nacos，访问 便能够成功登Nacos管理后台。
(1) 引入依赖
在 SpringBoot 项目中引入 Nacos 客户端依赖，pom.xml 添加如下内容：
(2) 修改配置
在 application.properties 配置文件中添加 Nacos 的基本配置 (也可以是 application.yml )
1）application.properties
2）application.yml
(3) @EnableDiscoveryClient 注解
在 SpringBoot 的启动类上添加 @EnableDiscoveryClient 注解来开启服务注册。
Nacos Discovery 默认集成了 Netflix Ribbon，服务消费者可以使用 RestTemplate 或 OpenFeign 进行服务的调用。
(1) Nacos 启动时报如下错误
问题原因：通过yum命令安装的普通的openJDK没有javac等工具，而且安装完以后连环境变量都不需要配置，就能使用 java -version 验证。
解决方案：重新安装devel开发版openJDK，开发版的openJDK有javac工具，然后配置java环境变量即可。
(2) Nacos Provider 启动报错
问题原因：没有配置 Nacos 服务端的地址，因此，当 Nacos Provider 启动的时候，无法与注册中心通信
解决方案：在配置文件中配置 Nacos 服务端地址，如下所示：
3. nacos服务发现
1. nacos服务发现原理
2. spring cloud服务协作流程
3.搭建nacos服务端
4. 搭建nacos服务发现客户端
5. nacos服务发现的数据模型
有两个微服务A和B, A调用B, 那么A是如何调用B的呢?我们可以通过http请求,进行调用. 也可以使用rpc进行调用.
不管使用什么方式, A需要知道B的地址和端口号. 那么A是如何知道B的地址和端口好的呢? 如上图:
1. B服务启动的时候, 会注册到服务发现中心, 告诉他,我的ip和端口号是什么?这里应该也是接口调用,通知服务发现中心的.
2. A服务启动的时候, 也会注册的服务发现中心, 告诉他, 我的ip和端口号是什么? 同时, 服务发现中心会告诉我, 当前已注册的服务的ip和端口号. 这里通过一个接口请求和参数返回就可以实现.
3. 拿到了B服务的ip和port, 接下来就可以调用服务B了.
我们要基于spring cloud生态环境进行开发. 所以,先来了解spring cloud的服务写作流程
前面注册和发现就都不说了, 上面说过了, 这里多了两个东西, 一个是Ribbon, 另一个是feign.
Ribbon是负载均衡器, Feign是远程调用, 自动进行http请求.
客户端Service A 要调用ServiceB的实例1和实例2. 那么到底调用ServiceB的哪个实例呢? 使用Ribbon负载均衡, 要看使用什么样的算法了, 可以使用轮询算法, 或者其他算法, 如加权算法
负载均衡有两种: 服务端负载均衡, 客户端负载均衡
在负载均衡中维护一个可用的服务实例清单, 当客户端请求来临时, 负载均衡服务器按照某种配置好的规则(负载均衡算法), 从可用服务实例清单中, 选取其一去处理客户端请求, 这就是服务端负载均衡, 例如Nginx. 通过nginx进行负载均衡, 客户端发送请求值Nginx, nginx通过负载均衡算法, 在多个服务器之间选择一个进行访问.
接下来, 我们要讲的ribbon, 就属于客户端负载均衡, 在ribbon客户端会有一个服务实例地址列表, 在发送请求前, 通过负载均衡算法, 选择一个服务实例, 然后进行访问, 这是客户端负载均衡. 即在客户端进行负载均衡算法分配.
服务的调用方, 我们就可以理解为是一个客户端.
负载均衡算法:
可通过下面的方式, 在spring boot配置中修改默认的负载均衡的策略
pre style="color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 12px; margin: 5px 8px; padding: 5px;"account-service.ribbon.NFLoadBalanceRuleClassName=com.netflix.loadBalancer.RandomRule/pre
其中: account-service: 是调用的服务的名称. 后面的组成部分是固定的.
feign是服务端http接口的调用.
feign可以帮助我们更快捷, 优雅的调用httpApi. 原来我们在调用http请求的时候, 需要使用的是RestTemplate, 传输域名和端口号, 进行http调用. 使用feign后, 不用再使用RestTemplate模拟请求了, feign能够通过服务名, 找到对应的接口. 不需要我们在拼接地址+端口了, 提供了简单方便的操作.
使用方法:
2. 声明feign客户端
新建一个类, 声明为FeignClient类型的接口. 指定调用的服务名. 然后将指定接口. 这样在调用的时候, 就可以通过服务名, + 接口, 自动找到对应的项目接口了.
这里上一节已经搭建过了(地址: ), 在服务的最后, 我们搭建了nacos的集群
因为对于服务发现来说, 有很多配置都是公用的, 因此, 我们搭建一个父工程, 将通用的配置都添加到里面取.
创建一个maven工厂, 引入jar包即可. pom文件如下
在父工程下创建一个子工程. 我们要做一下三件事
指定服务端口号, nacos服务的地址
需要增加两个引入. 一个启用服务发现, 另一个是启用feign
最终项目结构如下:
其中前3步骤和创建服务生产者是一样的
在父工程下创建一个子工程. 我们要做一下三件事
指定服务端口号, nacos服务的地址
需要增加两个引入. 1个启用服务发现, 另一个是启用feign
nacos生产上已经注册发现了两题服务
同时调用接口, 可以获取到productor返回的内容.
我们可以通过启动多个服务的方式, 来测试服务的负载均衡策略.
1. 修改productor的启动端口号为动态端口号. 目的是方便启动的时候动态配置端口号, 启动集群
** 2. 修改配置, 添加动态端口号**
vm options配置中设置动态端口号为-Dport=56010, 56011. 点击复制按钮, 可以增加一个应用, 然后配置参数后, 启动两个应用.
3. 在nacos控制台查看启动效果
我们看到, nacos的productor 有两台服务实例. 点击详情可查看具体的服务实例信息:
4. 调用consumer的接口, 访问productor, 默认采用轮询的负载均衡算法
nacos的注册发现是一种三层模型: 即 服务--集群--实例.如下图:
nacos最外层是服务. 最里层是多台实例. 多个实例之间组成一个服务集群.
命名空间不仅适用于配置管理, 同样适用于服务发现. namespace的常用场景之一是不同环境的配置隔离.如: 开发, 生成, 测试环境资源的隔离.
productor启动了两个实例, 点击详情进去可以看到他是一个集群. 集群里有两台实例.
5.2 服务.
在命名空间下, 有各个服务.比如我们上面定义的是在public命名空间下, 定义了两个服务. 一个是productor, 一个是consumer.
服务有 服务名 和 实例. ****远程调用的时候, 需要指定服务名.
5.3 实例
实例是基于网络协议通讯, 所以必须要有一个ip:端口号
5.4 元信息
在及群里点击某一个实例--编辑, 可以看到如下页面, 可以设置元信息
那么元信息是什么呢? 每台服务器都可能会设置自己的个性化的信息. 这就是每台服务器的元数据信息
5.5 实操---指定集群的命名空间为dev
只需要在配置中增加命名空间就可以了.
我们也可以修改集群的名字, 集群的默认名字是DEFAULT. 我们这里将其修改为default. 在控制台dev命名空间下, 可以看到启动了服务customer.
nacos服务搭建
编辑启动文件，startup.cmd
set MODE="standalone"
解压压缩包，执行bin目录下的startup.cmd 命令 启动nacos
执行bin目录下的shutdown.cmd 命令 停止nacos
C:\Users\wqf\Desktop\nacos-server-1.4.2\nacos\bin
访问nocas的服务端 http://服务器ip:8848/nacos/index.html，默认的用户名密码是 nocas/nocas
补充：windows 启动如果出现问题 编辑start.cmd文件 修改图示行
微服务初体验（二）：使用Nacos作为配置中心并集成Dubbo
首先启动Nacos，按照上篇文章的步骤，启动Nacos服务和项目，访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml，在Spring boot项目中bootstrap.yml会比application.yml优先初始化，所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已经把Nacos作为配置中心的配置写入了application.yml，现在只需要把它从applicaiton.yml中剪切出来即可， 其中的spring:application:name会作为Nacos中新增配置时的Data ID，需要留意 ），再新增属性gorup进行分组测试，如下图
接着打开Nacos的服务的web页面，打开配置管理-配置列表，点击右侧新增按钮，进行新增。
Data ID： bootstrap.yml配置文件中spring:application:name对应的名称 ；
Group：指定分组（便于不同环境下的项目配置管理，因为笔者这里属于测试，所以填写的是和上文中的配置文件中group对应的test一致）；
描述：针对于该配置的描述；
配置格式：配置文件的格式，要和Data ID中的后缀格式一致（这里笔者用的是yml，那么下面就选择yaml，注意该位置也可以选择properties，但是必须和上面bootstrap.yml文件中的file-extension的值相匹配）；
配置内容：具体的配置内容（这里笔者将项目中的application.yml中的配置全部拷贝至其中）；
测试启动consumer服务，在application.yml中为空的时候，项目启动端口还是如Nacos配置中的9011，说明项目依赖Nacos的配置中心成功，其他服务如法炮制即可：
新增一个测试Controller，然后加上@RefreshScope注解，表明该Controller中的配置数据为自动刷新 。
编辑Nacos中的配置文件consumer新增相关参数type: test，访问Controller，返回test。效果如下图：
将Nacos中consumer.yml文件的type: test修改为type: prod，在不重启项目的情况下重新访问对应的controller，效果如下图：
因为Dubbo是属于各个服务之间都要公用的依赖，所以将其引入cloud-common当中，详细的版本可以去 mvnrepository 搜索合适自己项目的
引入依赖后需要编写消费者服务中的配置文件，将Dubbo服务注册至Nacos，新增如下内容，其中subscribed-services指的是生产者服务，prot：-1指的是端口随机，registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos
接下来新增接口服务，项目类型为Maven项目，在项目中新增一个接口。并在cloud-provider（生产者）和cloud-consumer（消费者）pom.xml文件中都引入该模块
在生产者实际服务中实现该接口对应的方法
在服务消费者的Controller中引入该Service，并在该Service上加入@Reference注解，注意在引入jar包的时候选择带有Dubbo的，不要使用Jdk原生的
编写消费者服务中测试Dubbo调用的接口，进行测试，测试结果如下图：
nacos原理
nacos目前是集成到spring cloud alibaba里去的，也就是在spring cloud的标准之下实现了一些东西，spring cloud自己是有一个接口，叫做ServiceRegistry，也就是服务注册中心的概念，nacos中有一个它的实现类NacosServiceRegistry，实现了register、deregister、close、setStatus、getStatus之类的方法。
自动装配是一个spring boot的一个概念，自动装配的意思，其实就是说系统启动的时候，自动装配机制会运行，实现一些系统的初始化，自动运行，也就是系统启动时自动去调用NacosServiceRegistry的register方法去进行服务注册。而且除了注册之外，还会通过schedule线程池去提交一个定时调度任务，源码如下：
this.exeutorService.schedule(new BeatReactor.BeatTask(beatInfo), beatInfo.getPeriod(), TimeUnit.MILLISECONDS)，这就是一个心跳机制，定时发送心跳给nacos server。
然后会访问nacos server的open api，其实就是http接口，他有一个接口：;ip=xxport=xx，这么一个东西，也没什么特别的，这里就是访问注册接口罢了
nacos server那里是基于一个ConcurrentHashMap作为注册表来放服务信息的，直接会构造一个Service放到map里，然后对Service去addInstance添加一个实例，本质里面就是在维护信息，同时还会建立定时检查实例心跳的机制。最后还会基于一致性协议，比如说raft协议，去把注册同步给其他节点。
服务发现的本质其实也是nacos server上的一个http接口，就是：，就这么一个接口，然后就会启动定时任务，每隔10s拉取一次最新的实例列表，然后服务端还会监听他服务的状态，有异常就会基于UDP协议反向通知客户端这次服务异常变动。