【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)

目录

  • 前言
  • 阅读对象
  • 阅读导航
  • 前置知识
  • 笔记正文
    • 一、下载安装
    • 二、项目整合
      • 2.1 服务注册与发现
      • 2.2 动态配置管理
    • 三、其他实验
    • 四、服务之间的调用
  • 学习总结
  • 感谢

前言

本篇笔记主要是记录我整合Nacos项目进来的过程。以实现服务注册发现,以及分布式配置管理。关于Nacos,右侧点击:Nacos官网传送门

阅读对象

  1. 需要有实际Springboot-web开发经验
  2. 了解Nacos基本使用(可以从前言里面给的链接去官网学习,或者看看这篇文章《Nacos使用详解》)

阅读导航

系列上一篇文章:《【分布式微服务专题】从单体到分布式(一、SpringCloud项目初步升级)》

前置知识

笔记正文

一、下载安装

1)下载
当前环境:win11
版本:2.2.3,官方介绍说这是当前推荐的稳定版本
下载地址:Nacos2.2.3下载
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第1张图片
2)解压运行
解压,然后进入nacos/bin目录,以单机模式运行startup.cmd -m standalone【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第2张图片
当看到下面这个界面的时候就表示启动成功了:
在这里插入图片描述
接着,访问Nacos自带的客户端验证一下:http://localhost:8848/nacos
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第3张图片

二、项目整合

Nacos在项目模块上,大概会分为两个,分别是:nacos-confignacos-discovery,即:【分布式配置】和【服务注册与发现】。下面我们就分开两步来整合。

  • 通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-config 实现配置的动态变更
  • 通过 Nacos Server 和 spring-cloud-starter-alibaba-nacos-discovery 实现服务的注册与发现

2.1 服务注册与发现

1)首先是现在pom中添加【服务注册与发现】的jar包依赖

   <dependency>
       <groupId>com.alibaba.cloudgroupId>
       <artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
   dependency>

2)添加项目yml配置

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848

3)最后就是在启动类上添加@EnableDiscoveryClient启用【服务注册与发现】相关功能
4)启动服务。我则是添加到了shen-product服务上,效果如下:
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第4张图片
可以在nacso的服务列表中,看到shen-product注册到了nacos上。我们也可以尝试启动其他服务去验证哦。比如,我这里再启动一个shen-productshen-order服务。
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第5张图片
点击shen-product服务集群的的详情可以看到如下画面:
在这里插入图片描述
OK,非常强大。注意刀上面的权重了吗?你会想到啥?对嘛,负载均衡呀xdm。
对了,想要在IDEA里面启动多个服务实例其实也不难,就是右上角新增一个SpringBootApplication实例就好,当然注意修改端口
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第6张图片
5)调用shen-product
我们在上面启动了两个shen-product实例,我们来试试效果。先来试试http://localhost:9001/product/list,再来试试http://localhost:9002/product/list
在这里插入图片描述
在这里插入图片描述

2.2 动态配置管理

说到动态配置这个东西,有个前置内容需要先跟大家说说。Nacos提供的这个动态配置,是用于存储配置和其他元数据的 key/value,为分布式系统中的外部化配置提供服务器端和客户端支持。比如:同一组服务集群里面共享一些配置application.yml
那你们,还记得SpringBoot项目得application.yml加载顺序吗?包括其他所有配置。正常来说包括但不限于以下:

  1. 命令行参数
  2. 操作系统环境变量
  3. jar包外部的application-{profile}.properties或application.yml(带spring.profile)配置文件
  4. jar包内部的application-{profile}.properties或application.yml(带spring.profile)配置文件 再来加载不带profile
  5. jar包外部的application.properties或application.yml(不带spring.profile)配置文件
  6. jar包内部的application.properties或application.yml(不带spring.profile)配置文件

上面的内容不是重点,重点是,这里体现了一种配置思想:高优先级的配置覆盖低优先级的配置,所有的配置会形成互补配置 (覆盖 + 并级)。
那么问题就来了,既然SpringBoot配置文件需要遵循以上原则,那么,我在Nacos中的配置文件如何获取?有同学会说:我们不是有Nacos的地址嘛,通过地址去下载获取咯。确实是的,但是Nacos的地址你配置在哪里?我们上面的示例是把它配置在application.yml文件吧?但是application.yml文件要互补,然而想要获取最全的配置文件一定要先去nacos下载!所以在引入nacos-config配置中心的时候,就出现了逻辑矛盾。
为了解决这个问题,SpringCloud标准约定,引入一个全新的配置文件bootstrap.yml。它跟application.yml差不多,只不过优先级大于后者。bootstrap直译:引导。

1)首先是现在pom中添加【配置中心】的jar包依赖

  <dependency>
      <groupId>com.alibaba.cloudgroupId>
      <artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
  dependency>

另外我们不是在上面说要引入新的配置文件bootstrap.yml嘛,似乎2.x版本之后需要额外引入另一个包才行,不然会报错找不到bootstrap配置文件,如下:(下面这个包来自spring-cloud-dependencies,所以需要自己添加这个项目的管理依赖哦)

   
        <dependency>
            <groupId>org.springframework.cloudgroupId>
            <artifactId>spring-cloud-starter-bootstrapartifactId>
        dependency>

2)在bootstrap.yml文件配置nacos配置中心地址(spring.cloud.nacos.config

server:
  port: 9001

spring:
  application:
    name: shen-product
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848

3)在nacos中新建两张配置表
说到配置文件,首先需要向大家解释。SpringCloud应用会首先向Nacos查找${prefix}-${spring.profiles.active}.${file-extension}的配置文件。

  • prefix 默认为 spring.application.name 的值,也可以通过配置项 spring.cloud.nacos.config.prefix来配置。
  • spring.profiles.active 即为当前环境对应的 profile,详情可以参考 Spring Boot文档。 注意:当 spring.profiles.active 为空时,对应的连接符 - 也将不存在,dataId 的拼接格式变成 p r e f i x . {prefix}. prefix.{file-extension}
  • file-exetension 为配置内容的数据格式,可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型。
  • 更多内容请查看Nacos Config

比如我上面的配置中,会默认先查找shen-product.properties文件。
但是通常我们在配置中心里面,还会自定义很多通用的配置文件,比如我这么配置:

  1. application-conf.yaml:用来配置所有微服务的数据库配置。毕竟我是在试验阶段,共用一个数据库很合理吧… 甚至redis,mq等等。这些配置往往不需要支持动态更新
  2. config-info.yaml:用来存放一些需要动态更新的业务配置。例如我在里面存放了一个config.author来存放作者名字

如下图:
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第7张图片
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第8张图片
4)修改bootstrap.yml文件,支持yaml格式配置文件,支持拓展配置文件

server:
  port: 9001

spring:
  application:
    name: shen-product
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        file-extension: yaml
        extension-configs:
          - data-id: application-conf.yaml
          - data-id: config-info.yaml
            refresh: true

5)商品服务新增测试接口
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第9张图片
注意上面@RefreshScope注解,用来开启类的动态配置刷新

6)访问http://localhost:9001/product/getMyMan测试接口;修改配置继续测试

三、其他实验

官方还有一些其他的东西,比如:
【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第10张图片
这里就不试了,感觉Nacos比较重要的应该就是以上两点。另外还有Nacos集群搭建等等,也不在这里实验咯。

四、服务之间的调用

前面我的很多接口示例都是在单个服务上发生的,在我们的实际使用场景中,肯定会存在跨服务之间的调用。目前正在学习DubboOpenFeign,看看整合哪一种。
不过考虑到Alibaba的微服务体系,我应该会选择整合Dubbo。理由如下:

  1. 横向对比的话,Dubbo可以完美替代OpenFeign~
  2. OpenFeign唯一的优势应该是在于使用更简单,不过我觉得缺点是它只能使用http协议。http在我的刻板印象里面就是性能很拉跨,当然,http还有http1.1http2,Dubbo框架可以支持http2,而前者默认不支持,不过也可以切换客户端的方式来支持
  3. 学习Dubbo更有利于面试
  4. Dubbo唯一的缺点就是学习成本会高一点,毕竟内容多,呜呜呜

其实我还有一点疑问,Dubbo看官网介绍,总感觉跟Nacos有很多功能是重叠的,咋回事呢

【分布式微服务专题】从单体到分布式(二、SpringCloud整合Nacos)_第11张图片

学习总结

感谢

感谢本站大佬【作者:不凉帅】的文章《Nacos使用详解》)

你可能感兴趣的:(tuling学院学习笔记,Java,分布式/微服务,分布式,微服务,spring,cloud)