‘壹’ Nacos-参数配置
Nacos中的参数有很多，如：命名空间、分组名、服务名、保护阀值、服务路由类型、临时实例等，那这些参数都是什么意思?又该如何设置？
在Nacos中通过命名空间（Namespace）+分组（Group）+服务名（Name）可以定位到一个唯一的服务实例。
命名空间（Namespace）:Nacos服务中最顶层、也是包含范围最广的概念，用于强制隔离类似环境或者租户等场景。Nacos的服务也需要使用命名空间来进行隔离。 命名空间在Nacos控制台的一级目录里可以找到，如下所示：
在服务列表中也能看到命名空间的身影，如下所示：
命名空间默认为public，在项目开发中，如果不指定命名空间，那么会使用默认值public。 官方推荐使用运行环境来定义命名空间 ，如生产版本可使用public，开发版可定义为private。在项目开发中，可通过配置"spring.cloud.nacos.discovery.namespace"老定义命名空间，如下所示：
命名空间在使用前，必须先在控制台新建命名空间 ，如下所示：
如果在控制台没有新建命名空间，直接在项目中使用的话，是不能将服务成功注册到Nacos中的，如下在项目中配置一个未新建的dev命名空间，如下所示：
然后启动项目，会发现，在Nacos控制台的服务列表中一直刷新不到任何服务实例
分组名（Group）：Nacos中次于命名空间的一种隔离概念，区别于命名空间的强制隔离属性，分组属于一个弱隔离概念，主要用于逻辑区分一些服务使用场景或不同应用的同名服务，用常用的情况主要是同一个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用提供的服务重名。 分组名在Nacos控制台的服务列表中可以看到，如下所示：
分组名默认为DEFAULT_GROUP，在项目中可通过"spring.cloud.nacos.discovery.group"来设置，如下所示：
此项可省略，省略时的默认值为DEFAULT_GROUP。 分组名可以直接在项目中使用 ，无需像命名空间那样，在使用前还要在控制台中新建，设定了分组名之后，刷新服务列表就可以看到新的分组名称了，如下所示：
服务名（Name）:该服务实际的名字，一般用于描述该服务提供了某种功能或能力。 通常推荐使用由运行环境作为命名空间、应用名作为分组，服务功能作为服务名的组合来确保该服务的天然唯一性，当然使用者可以忽略命名空间和分组，仅使用服务名作为服务唯一标识，这就需要使用者在定义服务名的额外增加自己的规则来确保在使用中能够唯一定位到该服务而不会发现到错误的服务上。服务名在项目中可以通过"spring.application.name"来指定，如下所示：
健康保护阈值（ProtectThresHold）：为了防止因过多实例故障，导致所有流量全部流入剩余实例，继而造成流量压力将剩余实例被压垮形成雪崩效应。应将健康保护阈值定义为一个0到1之间的浮点数。当域名健康实例数占总服务实例数的比例小于该值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失一部分流量，但是保证了集群中剩余健康实例能正常工作。 简单来说，保护阈值是一个0-1浮点数，保护阈值是允许群里中健康实例占比的最小值，如果实际健康实例的占比小于或等于设置的保护阈值时，就会触发阈值保护，如下所示，设置保护阈值为0.75：
停掉唯一的健康实例，集群的健康实例占比降成了0%，小于设置的保护阈值0.75，此时就会触发阈值保护，如下所示：
服务路由类型的设置如下所示：
它是用来设置服务的路由策略的，默认值为none。如果 设置为label（标签）模式，需要设置响应的标签表达式来匹配实例选择器（Selector）,通过实例选择器可以完成自定义负载均衡策略， 比如我们可以自定义实例选择器，实现就近访问的负载均衡策略，这样消费者在调用时，会优先调用离自己比较近的IP节点，从而实现更高效的服务调用。
权重（Weight）：实例的级别配置。权重为浮点数，范围为0-10000。权重越大，分配给该实例的流量越大。 它是针对服务实例进行设置的，如下所示：
在Nacos中服务实例有二种类型：持久化实例和临时实例（也叫非持久化实例）。 在控制台中"临时实例"为true时，表示此服务为临时实例，如下所示：
临时实例和持久化实例的区别主要有一下两点：
在项目开发中，可以通过设置
“spring.cloud.nacos.discovery.ephemeral”来指定服务的实例类型，默认为临时实例，也就是默认“spring.cloud.nacos.discovery.ephemeral=true”。如果要设置持久化实例，需要设置“spring.cloud.nacos.discovery.ephemeral”设置为 false，如下图所示：
服务的实例类型一旦确定之后，整个生命周期内不允许被修改，如果试图修改实例类型会提示如下错误：
‘贰’ nacos与k8s 服务注册与发现
首先先说说比较常规的nacos的服务注册与发现。
用spring cloud为例，ali集成了spring-cloud和nacos，因此加入以下依赖
然后我们配置nacos server的地址，并通过 Spring Cloud 原生注解 @EnableDiscoveryClient 开启服务注册发现功能，在 application.properties 中配置 Nacos server 的地址，启动服务之后，服务会将自己的元数据注册到nacos上，最主要的是服务名，ip，端口，namespace等。服务注册成功后，服务将与注册中心维持心跳，心跳机制可以保证当服务中的某个实例不健康之后，服务中心将该实例剔除，以保证服务正常提供服务。
当服务注册上去之后，消费者就可以调用服务了，那么消费者是怎么发现服务的呢，消费者向注册中心订阅某个服务，并提交一个监听器，当服务提供方实例发生变化，比如ip变了，消费者会收到通知，更新本地的服务列表，nacos client获取到服务列表之后，通过负载均衡，spring一般都是结合ribbon，获取一个可用的实例，得到它的ip和端口号，以及服务路由，然后进行调用。
由于客户端将获取到的服务实例保存在一个 map 中，而该 map 中的内容是由调度任务定时去更新的，存在一定的延时。
一般来说，在k8s中一个服务有多个实例，是通过pod去部署的，多个实例则有多个pod，每一个pod都会有自己的容器组ip，在集群内，直接通过这个容器ip和端口是可以访问服务的，但是每次服务重启，也就是pod销毁重建的时候，ip也会改变。k8s并没有一个注册中心让我们注册实例的ip和端口到服务下面，并且其他服务通过这个注册中心去发现服务。在k8s里是通过service去实现的。
这是一个service定义的例子， 这个 Service 将被指派一个 IP 地址（通常称为 “Cluster IP”），上述的selector代表这个service代理的pod选择器，也就是说具有这个app标签的选择器的一组pod，可以通过service这个统一的访问入口去做服务发现。
比如说我们现在有一组pod叫base-opc-biz
查看它的service
信息包括 ：name，namespace，selector，labels等基础信息
type 是ClusterIP,IP这个值 即是在集群内部，其他所有的pod都可以通过这个虚拟的ip来访问service，service就会将这个请求负载均衡到后端的所有pod上去。
Port 是访问service的端口
TargetPort 是代理的pod的端口
Endpoints 是当前service代理的所有pod的ip地址，当某个pod被销毁重建的时候，这里的ip地址也会随之变化
集群内其他pod访问我们创建的service有三种方式：
1、 通过clusterIp+port直接去访问
2、 同一个namespace直接访问服务名，不同的 namespace 里面，我们可以通过 service 名字加“.”kube-dns可以解决Service的发现问题，k8s将Service的名称当做域名注册到kube-dns中，通过Service的名称就可以访问其提供的服务。
Kubernetes 集群中部署了一套 DNS 服务，通过 kube-dns 的服务名暴露 DNS 服务。您可执行以下命令查看 kube-dns 的服务详情。
kubectl get svc kube-dns -n kube-system
服务后端是两个名为 coredns（下文会介绍 CoreDNS 解析原理） 的 Pod。您可执行以下命令查看 coredns 的 Pod 详情。
kubectl get deployment coredns -n kube-system
3、 通过环境变量访问，在同一个 namespace 里的 pod 启动时，kubelet 会为每个活跃的 Service 添加一组环境变量，会把 service 的一些 IP 地址、端口，以及一些简单的配置，通过环境变量的方式放到 K8s 的 pod 里面。因此我们可以通过环境变量去直接访问。
上面三种方式都是在k8s集群内部互相访问的情况，对我们应用的某些部分，可能希望将 Service 暴露在一个外部 IP 地址上。 Kubernetes 支持两种实现方式：NodePort 和 LoadBalancer。
我们看下我们原本的service 的yaml文件
把type改成NodePort 或者 LoadBalancer
然后重新创建service，再看看信息
发现有了EXTERNAL-IP，这个ip是一个公网的ip，因此我们就不只可以在集群上访问我们的服务了。
‘叁’ Spring Gateway 集成Nacos 实现动态路由配置
通过Spring Gateway 集成Nacos实现配置管理，并且实现动态路由管理。
一、创建test-gateway项目，POM文件如下：
二、创建项目配置文件bootstrap.yml
a、test_gateway_commons.yml内容如下：
三、创建网关配置类 GatewayConfig.java
四、创建动态路由服务DynamicRouteServiceImpl.java
五、创建通过Nacos读取动态路由配置服务.java
六、配置动态路由配置文件gateway_dynamic_router，内容如下：
通过以上步骤就完成Spring Gateway 集成Nacos 实现动态路由配置功能。以后只要通过修改Nacos的配置文件就可以时间服务的动态上下线了。不需要再重启网关了。
‘肆’ Nacos配置成系统服务，开机自动启动及注意事项
设置开机启动
vim /lib/systemd/system/nacos.service
[Unit]
Description=nacos
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/nacos/bin/startup.sh
ExecReload=/usr/local/nacos/bin/shutdown.sh
ExecStop=/usr/local/nacos/bin/shutdown.sh
PrivateTmp=true
[Install]
WantedBy=multi-user.target
--------------------------------------------------------------------------------------
如果是单机模式这个语句需要修改为如下
ExecStart=/usr/local/nacos/bin/startup.sh -m standalone
保存后执行以下命令
systemctl daemon-reload
systemctl enable nacos.service
systemctl start nacos.service
如果报错：
nacos.service: Service hold-off time over, scheling restart.
是service启动文件没有加载进来 需要重启系统 reboot 就可以了
注意事项：
需要修改/usr/local/nacos/bin/startup.sh 中的一个参数
原：
修改后：
保存后就不会启动是报错了。
‘伍’ 使用路由网关统一访问接口
Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式。 Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix ZUUL ，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。
客户端向 Spring Cloud Gateway 发出请求。然后在 Gateway Handler Mapping 中找到与请求相匹配的路由，将其发送到 Gateway Web Handler。Handler 再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。
过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（ pre ）或之后（ post ）执行业务逻辑。
主要增加了 org.springframework.cloud:spring-cloud-starter-gateway 依赖
注意：请仔细阅读注释
依次运行 Nacos 服务、 NacosProviderApplication 、 NacosConsumerApplication 、 NacosConsumerFeignApplication 、 GatewayApplication
打开浏览器访问： http://localhost:9000/nacos-consumer/echo/app/name 浏览器显示
打开浏览器访问： http://localhost:9000/nacos-consumer-feign/echo/hi 浏览器显示
注意：请求方式是 http://路由网关IP:路由网关Port/服务名/**
至此说明 Spring Cloud Gateway 的路由功能配置成功
‘陆’ 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类型的接口. 指定调用的服务名. 然后将指定接口. 这样在调用的时候, 就可以通过服务名, + 接口, 自动找到对应的项目接口了.
这里上一节已经搭建过了(地址: https://www.cnblogs.com/ITPower/articles/12630193.html ), 在服务的最后, 我们搭建了nacos的集群
因为对于服务发现来说, 有很多配置都是公用的, 因此, 我们搭建一个父工程, 将通用的配置都添加到里面取.
创建一个maven工厂, 引入jar包即可. pom文件如下
在父工程下创建一个子工程. 我们要做一下三件事
指定服务端口号, nacos服务的地址
需要增加两个引入. 一个启用服务发现, 另一个是启用feign
最终项目结构如下:
其中前3步骤和创建服务生产者是一样的
在父工程下创建一个子工程. 我们要做一下三件事
指定服务端口号, nacos服务的地址
需要增加两个引入. 1个启用服务发现, 另一个是启用feign
nacos生产上已经注册发现了两题服务
同时调用接口, 可以获取到proctor返回的内容.
我们可以通过启动多个服务的方式, 来测试服务的负载均衡策略.
1. 修改proctor的启动端口号为动态端口号. 目的是方便启动的时候动态配置端口号, 启动集群
** 2. 修改配置, 添加动态端口号**
vm options配置中设置动态端口号为-Dport=56010, 56011. 点击复制按钮, 可以增加一个应用, 然后配置参数后, 启动两个应用.
3. 在nacos控制台查看启动效果
我们看到, nacos的proctor 有两台服务实例. 点击详情可查看具体的服务实例信息:
4. 调用consumer的接口, 访问proctor, 默认采用轮询的负载均衡算法
http://localhost:56020/consumer
nacos的注册发现是一种三层模型: 即 服务--集群--实例.如下图:
nacos最外层是服务. 最里层是多台实例. 多个实例之间组成一个服务集群.
命名空间不仅适用于配置管理, 同样适用于服务发现. namespace的常用场景之一是不同环境的配置隔离.如: 开发, 生成, 测试环境资源的隔离.
proctor启动了两个实例, 点击详情进去可以看到他是一个集群. 集群里有两台实例.
5.2 服务.
在命名空间下, 有各个服务.比如我们上面定义的是在public命名空间下, 定义了两个服务. 一个是proctor, 一个是consumer.
服务有 服务名 和 实例. ****远程调用的时候, 需要指定服务名.
5.3 实例
实例是基于网络协议通讯, 所以必须要有一个ip:端口号
5.4 元信息
在及群里点击某一个实例-->编辑, 可以看到如下页面, 可以设置元信息
那么元信息是什么呢? 每台服务器都可能会设置自己的个性化的信息. 这就是每台服务器的元数据信息
5.5 实操---指定集群的命名空间为dev
只需要在配置中增加命名空间就可以了.
我们也可以修改集群的名字, 集群的默认名字是DEFAULT. 我们这里将其修改为default. 在控制台dev命名空间下, 可以看到启动了服务customer.
‘柒’ Spring Gateway集成nacos实现动态路由配置
本文主要介绍Spring Gateway通过集成nacos实现路由动态配置，达到不重启API网关实现动态暴露内部微服务接口的目的。主要流程如下：
一、创建Maven项目test-gateway, pom文件如下：
二、创建启动类Apllication.java，内容如下：
三、创建网关调用nacos配置类GatewayConfig.java
四、创建动态路由管理服务
1、创建动态路管理类DynamicRouteServiceImpl.java
2、创建通过nacos对路由动态管理类.java
1、test_gateway_commons.yml配置文件内容下：
2、JSON路由配置文件gateway_dynamic_router的内容如下：
通过以上步骤就实现了Spring Gateway集成nacos实现路由动态配置的功能。以后只要修改gateway_dynamic_router 文件就可以实现服务的微服务的接口暴露和下线功能。
demo代码地址如下：https://gitee.com/sharepublicly/test-gateway
‘捌’ 【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，访问 http://ip:8848/nacos/index.html 便能够成功登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 服务端地址，如下所示：
‘玖’ nacos配置中心单击模式改造为集群模式
nacos作为配置中心可以将配置项目的配置提取到外部，独立管理，当nacos单机部署时，当nacos服务不正常时，项目便不可获取到正确的配置信息。如果将nacos搭建成集群环境，只要不是集群的所有机器都有挂掉，都可以正常读取配置，可以提高项目稳定性。
需要多台linux机器作为集群的环境
此外，需要linux机器包含maven环境、java环境
github地址： https://github.com/alibaba/nacos
新建cluster.conf文件，或者将cluster.conf.example重明明为cluster.conf
在此文件中添加集群地址和端口号
新建application.properties文件或者将application.properties.example重命名为application.properties
执行bin目录下的startup.sh脚本
ps：sh startup.sh则默认以集群模式启动，sh startup.sh -m standalone则是以单机模式启动
启动成功后，单独访问每台机器的地址(ip:8848/nacos/#/login)，用户名密码：nacos/nacos
如果都能正常访问，则一切正常。
启动项目，后台可以看到nacos连接的相关日志
并且项目可以正常读取到配置内容，则一切正常
如果使用jenkins部署项目，则需要需要修改jenkins的nacos相关配置，使之可以正确读取到nacos集群的每一台机器
‘拾’ springboot 2.4.13 无法从nacos获取配置，但是可以注册到nacos
springboot 2.4.13，集成了nacos，启动后，nacos注册中心有服务，但是，发现，配置没有生效。于是，开启了一段源码查找的过程。
首先，是pom引入的nacos配置
然后，application.yml添加nacos配置
启动后，发现注册中心有服务，但是，服务的配置不是从nacos配置中心获取的，而是本地的。
查找一下nacos源码，找到nacos配置自动注入那块儿：
然后发现，是这个NacosPropertySourceLocator实现的配置导入的
查询源码，可以发现，相关的配置，是通过这个方法，加载的，这个方法是总入口。
于是，尝试加断点，查看配置信息，看看为什么没有导入配置。然而，程序根本就没有进入这个方法里面！！！
根据接口实现，可以发现NacosPropertySourceLocator 是PropertySourceLocator的实现类，这个方法的调用执行，不是nacos自己去做的，而是通过spring去做的。
spring cloud 通过BootstrapApplicationListener，以监听器的方式，通过监听springboot启动过程中的事件，通过onApplicationEvent方法处理事件，导入spring cloud相关配置。
通过加断点，可以发现，这里的方法bootstrapEnabled()返回值是false，直接就不执行后续的加载了。
因此，需要保证bootstrapEnabled返回值是true。
查看PropertyUtils源码，可以发现，需要配置项 spring.cloud.bootstrap.enabled=true 并且存在 org.springframework.cloud.bootstrap.marker.Marker 类的时候，spring cloud 才会去加载spring cloud的配置。
因此，pom中需要添加marker所在的组件依赖：
此时，需要在 bootstrap.yml 中添加spring cloud配置：
（至于为什么是bootstrap.yml而不是application.yml，这又是另一个问题了）
有了上面的配置，程序启动后，就能正常的从nacos配置中心获取配置了。