详解SpringCloud微服务技术栈：Nacos服务搭建及服务分级存储模型

👨?🎓作者简介：一位大四、研0学生，正在努力准备大四暑假的实习
🌌上期文章：详解SpringCloud微服务技术栈：强推！源码跟踪分析Ribbon负载均衡原理、Eureka服务部署
📚订阅专栏：微服务技术全家桶
希望文章对你们有所帮助

上一节已经使用Eureka实现了服务注册和服务发现，并给源码分析了Ribbon是如何进行负载均衡的，整个项目是如何进行服务拉取的等等。
Nacos也可以做到这一点，而且相对来说更常用。

认识与安装Nacos（Windows版）

Nacos是阿里巴巴的产品，现在是SpringCloud的组件，比起上一节的Eureka，功能更加丰富，相对来讲更常用。
Nacos的安装，可以去官网下载，比较慢，这里提供了一个网盘的地址：

链接：https://pan.baidu.com/s/1XBShX7krth5RLlkGpTXFqw?pwd=lu54
提取码：lu54

安装完毕就直接解压到无中文的路径就可以了。

target里面是一个jar包，这就是一个基于java语言去实现的
conf是配置文件，里面的端口是8848，如果这个端口被占用了可以自行去做修改
bin是可执行文件

最简单的启动方式是点击startup.cmd，但是我这里是启动异常的，也可以进入cmd去用命令行启动：

startup.cmd -m standalone

-m表示model模式，standalone表示单机模式启动。

控制台的网址可以直接访问，进去以后登录的用户名和密码都是nacos：

提交，即可进入Nacos的控制台了：

至此，Nacos安装完毕。

Nacos快速入门

利用Nacos实现服务注册。
1、在cloud-demo父工程中添加spring-cloud-alibaba的管理依赖：

		<dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2.2.5.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>

2、注释order-service与user-service中关于Eureka的依赖。
3、添加nacos的客户端依赖：

		<dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>

4、在Yaml配置文件中配置Nacos的服务地址，并且可以将之前Eureka的相关配置注释了。

重启服务，打开控制台能看到服务列表证明成功实现服务注册了：

这个页面看起来比Eureka的更直观一点，点进去也可以查看更详细的信息。

服务分级存储模型

其实分级存储的概念早就接触过了，demo中的服务是user-service以及order-service，这是一级，而user-service又有多个实例，分别有着不同的端口号，这实际上就是一种多级存储模型。
然后随着服务越来越大，实例可能也越来越多，为了防止危险，尽可能将实例存储到多个地方，这样即便发生问题也能减小损失。
若干个实例组成的即为集群。
分级存储模型：服务-集群-实例

服务跨集群调用问题

服务之间的调用（比如order-service调用user-service），可以在一个集群内访问实例，也可以跨集群，即访问其他集群的实例。
服务调用的时候需要尽量满足：

1、服务调用尽可能选择本地集群的服务，跨集群调用延迟较高
2、本地集群不可访问时，再去访问其它集群

而打开Nacos，可以看到实习并不在特定集群中，因此需要手动配置集群的属性。
1、修改application.yml，添加如下内容：

将2台实例启动，相当于将这两台集群放入了湖中大集群：

修改一下配置：

这时候启动UserApplication3，就相当于将这台实例放入了NUAA集群了：

2、在Nacos控制台可以看到2集群，3实例：

NacosRule负载均衡

修改配置，使得当运行order-service的时候，优先去调用本地的集群。
先给order-service配置集群，配置到HNUCM，重启orderService。
多次访问网址：http://localhost:8080/order/101 或者102、103等等。
可以发现8083端口进行了数据库查询的操作：

这说明了，目前的负载均衡只考虑了实例，没有考虑集群。

解决方法：在order-service中设置负载均衡的IRule为NacosRule，这个规则会优先寻找与自己同集群的服务：

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

重启order-service，不会再访问8083端口，且8081与8082的选择是一种随机方式的访问，而不是轮询方式。

把8081端口和8082端口的实例停止，再次刷新order的访问网址，将会在端口8083进行访问，同时我们可以打开orderApplication的控制台，可以发现发出了警告WARN：

显示了这是跨集群的访问。

服务实例的权重设置

实际部署的时候会遇到这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们自然是希望性能好的机器承担更多的请求

而Nacos提供了权重配置来控制访问的频率，权重越大则频率越高。

在Nacos控制台可以看到权重都是默认为1的，我们可以编辑权重（范围为0到1），将8081端口的权重设置为0.1，自行测试就可以发现其被访问的频率就大大降低了。


权重调成0的时候，这个实例根本就不会被调用，这种情况比较常见在实例版本的升级的时候，这时候就可以讲这个实例的权重调成0，版本升级完成以后再添加权重。

环境隔离——namespace

Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离。其内部可以分组Group，Group内就是具体的服务-集群-实例了。
也就是说，环境隔离namespace就是在对服务做隔离，而这里的Group是将相关度比较高的服务进行分组。

当我们没有配置的情况下，服务都是在public的命令空间下的：

可以创建新的命名空间：

要将服务放入一个命名空间，需要修改代码：
修改order-service的application.yml，添加namespace：

重启后可以看到它放在了dev的命名空间里了。

同时，这时候无法再访问8081、8082、8083的内容了。

总结：
1、namespace用来做环境隔离
2、每个namespace都有唯一id
3、不同namespace下的服务不可见

Nacos与Eureka的对比

在做服务注册和服务发现的时候，Nacos与Eureka的过程都是差不多的，即：

1、服务提供者在注册中心注册服务信息
2、服务消费者会定时向注册中心拉取服务
3、拉取到的服务会存入服务列表缓存，提高效率
4、服务消费者对服务提供者实行负载均衡的远程调用

Nacos与Eureka的区别体现在下面几点：

1、健康检测

为了让消费者在远程调用的时候能够调用正常健康的提供者，服务的提供者需要在注册中心进行健康检测，Eureka的方式是心跳检测，而Nacos却有些不一样。

1、服务提供者的实例分为临时实例和非临时实例（永久），只有临时实例会采用心跳检测来体现健康状况，当不健康的话，Nacos会将该实例从服务列表中剔除
2、对于非临时实例，Nacos会主动进行询问，询问是否健康，若不健康，Nacos也不会将该实例从服务列表中剔除，而仅仅是标记为不健康，直到它恢复健康

2、服务列表缓存

Eureka只使用了pull方式进行缓存更新，效率较慢，而Nacos是采用了pull/push（消息推送）结合的方式，当有宕机的情况出现的时候，Nacos会迅速的将该消息push给它

服务注册到Nacos时，可以选择注册为临时实例还是非临时实例，通过下面的配置来设置：


如果把服务关机，将会迅速查出不健康，但是服务列表中，该服务永远存在。

总结：
1、共同点
（1）支持服务注册和服务拉取
（2）都支持服务提供者心跳方式做健康检测

2、不同点：
（1）Nacos支持服务端主动检测提供者的状态：临时实例用心跳模式，非临时实例采用主动检测模式，但是这种方式压力会更大一点
（2）临时实例心跳不正常会被剔除，非临时实例则不会被剔除
（3）Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
（4）Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP方式；Eureka只能采用AP方式（暂时没学这方面内容，只能大致知道CP方式更强调数据的一致性和可靠性，因此当有非临时实例的时候需要转换为CP方式）