【SpringCloud】Nacos简介 && 安装 && 快速入手 && 负载均衡

【SpringCloud】Nacos简介 && 安装 && 快速入手 && 负载均衡

文章目录

在这里插入图片描述

Ⅰ. Nacos简介

2018年6月,Eureka2.0 宣布闭源(但是1.X版本仍然为活跃项目),同年7月份,阿里 Nacos 宣布开源,并快速成为国内最受关注开源产品。作为 Eureka 的替代,Nacos 已经成为了国内开发者的首选,目前 Nacos Star 已经突破 28K(Eureka12K)

在这里插入图片描述

Nacos(Dynamic Naming and Configuration Service)

在最初开源时,Nacos 选择进行内部三个产品合并统一开源(Configserver 非持久注册中心、VIPServer 持久化注册中心、Diamond 配置中心)。定位为:一个更易于构建云原生应用的动态服务发现,配置管理和服务管理平台。所以 Nacos 是一个注册中心组件,但它又不仅仅是注册中心组件。

截至目前,Nacos 几乎支持了所有的主流语言,比如 Java、Go、C++、Nodejs、Python、Scala 等。

官网:https://nacos.io/

仓库:https://github.com/alibaba/nacos

Ⅱ. Nacos安装

下载地址:https://github.com/alibaba/nacos/releases

一、Windows

① 解压

把压缩包解压到任意非中文的目录下

在这里插入图片描述
  • bin:Nacos 启停脚本
    • startup.cmd:windows 平台的启动脚本
    • shutdown.cmd:windows 平台的停止脚本
    • startup.sh:Linux 平台的启动脚本
    • shutdown.sh:Linux 平台的停止脚本
  • conf:Nacos 配置文件
  • target:存放 Nacos 应用的 jar 包

② 修改为单机模式

Nacos 默认启动方式为集群,启动前需要修改配置为单机模式。

  1. 使用记事本打开 startup.cmd

Line26左右,修改启动模式:

setMODE="cluster" 改为: setMODE="standalone"

③ 启动Nacos

启动非常简单,进入bin目录下,双击 startup.cmd 即可。访问 Nacos 主页 http://127.0.0.1:8848/nacos,出现以下界面,表示 Nacos 启动成功。

在这里插入图片描述

二、Linux

同理下载好压缩包,然后上传到服务器上某个目录中。

然后进入 nacos/bin 目录,输入命令:

bash startup.sh -m standalone 

启动成功后,像之前那样访问网站即可。

Ⅲ. Nacos快速上手

Nacos 是 SpringCloudAlibaba 的组件,SpringCloudAlibaba 遵循 SpringCloud 中定义的服务注册,服务发现规范。因此使用 Nacos 和使用 Eureka 对于微服务来说,并没有太大区别。

主要差异在于:

  • Eureka 需要自己搭建一个服务,Nacos 不用自己搭建服务,组件已经准备好了,只需启动即可。
  • 对应依赖和配置不同

操作参考:https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-discovery

一、服务注册/服务发现

① 引入Spring CloudAlibaba依赖

在父工程的 pom.xml 文件中的 <dependencyManagement> 中引入 SpringCloudAlibaba 依赖:

<properties><spring-cloud-alibaba.version>2022.0.0.0-RC2</spring-cloud-alibaba.version></properties><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-alibaba-dependencies</artifactId><version>${spring-cloud-alibaba.version}</version><type>pom</type><scope>import</scope></dependency>

💡 注意:SpringBootSpringCloud 的版本是有一定对应关系的。SpringCloudAlibaba 也遵循 SpringCloud 的标准,所以在引入依赖时一定要确认各个版本的对应关系。

SpringCloudAlibabaSpringCloud 版本对应关系,参考官方文档,版本在一定范围内可以自由选择。

② 引入Nacos依赖

order-serviceproduct-service 中引入 Nacos 依赖:

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

③ 引入LoadBalance依赖

用 Nacos 时之所以要额外引入 spring-cloud-loadbalancer 依赖,是因为 Nacos 自己不提供客户端负载均衡能力。它只负责服务发现,不负责挑服务、轮询、权重策略这些 “选谁调用” 的逻辑。

因此在 Spring Boot 2.4+ 之后,必须引入:

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-loadbalancer</artifactId></dependency>

二、配置Nacos服务地址

添加 Nacos 配置

spring:application:name: product-service cloud:nacos:discovery:server-addr: 49.235.136.223:8848# 配置nacos服务访问地址

三、远程调用

为 restTemplate 配置类添加负载均衡注解 @LoadBalanced

@ConfigurationpublicclassBeanConfig{@Bean@LoadBalancedpublicRestTemplaterestTemplate(){returnnewRestTemplate();}}

order-service 中代码修改 IP 为项目名(同前面)

publicOrderInfoselectOrderById(Integer orderId){OrderInfo orderInfo = orderMapper.selectOrderById(orderId);String url ="http://product-service/product/"+ orderInfo.getProductId(); log.info("product-service url: "+ url);ProductInfo productInfo = restTemplate.getForObject(url,ProductInfo.class); orderInfo.setProductInfo(productInfo);return orderInfo;}

四、启动服务

启动一个 order-service 服务,再启动三个 product-service 服务,观察 Nacos 的管理界面,发现 order-serviceproduct-service 都注册在 Nacos 上了:

在这里插入图片描述

测试接口:http://127.0.0.1:8080/order/1

Ⅳ. Nacos负载均衡

生产环境相对是比较恶劣的,我们需要对服务的流量进行更加精细的控制。Nacos 支持多种负载均衡策略,包括权重、同机房、同地域、同环境等。

一、服务下线

当某一个节点上接口的性能较差时,我们可以第一时间对该节点进行下线。

操作步骤:服务详情 -> 下线

在这里插入图片描述

点击下线后,再次请求接口,会发现该服务没有请求进来了。再次单击上线,该节点会继续收到请求。

二、权重配置

除了下线之外也可以配置这个节点的流量权重

① 配置权重

操作步骤:找到对应节点 -> 编辑 -> 在弹出的窗口修改权重值

在这里插入图片描述

每个节点默认权重为 1,修改为 0.1。

② 开启Nacos负载均衡策略

由于 SpringCloudLoadBalance 组件自身有负载均衡配置方式,所以不支持 Nacos 的权重属性配置。

我们需要开启 Nacos 的负载均衡策略,让权重配置生效。

参考:如何解决MSENacos上修改服务实例的权重不生效问题_微服务引擎(MSE)-阿里云帮助中心

# 开启nacos的负载均衡策略spring:cloud:loadbalancer:nacos:enabled:true

③ 测试权重配置

启动服务,访问多次接口,观察结果,会发现 9091 端口号的实例接收的请求明显比另外两个实例少。

注意: 整体流量生效,局部流量不是严格按照设置的比例进行分配的。

三、同集群优先访问

Nacos 把同一个机房内的实例,划分为一个集群。所以同集群优先访问,在一定程度上也可以理解为同机房优先访问。

微服务架构中,一个服务通常有多个实例共同提供服务,这些实例可以部署在不同的机器上,这些机器可以分布在不同的机房,比如 product-service

  • 实例1:分布在上海机房
  • 实例2:分布在上海机房
  • 实例3:分布在北京机房

实例4:分布在北京机房

在这里插入图片描述

在微服务访问时,应尽量访问同机房的实例。当本机房内实例不可用时,才访问其他机房的实例

比如 order-service 在上海机房,product-service 在北京和上海机房都有实例,那我们希望可以优先访问上海机房。如果上海机房没有实例,或者实例不可用,再访问北京机房的实例。通常情况下,因为同一个机房的机器属于一个局域网,局域网访问速度更快一点。

在这里插入图片描述

① 给实例配置集群名称

product-service 配置集群名称

spring:cloud:nacos:discovery:server-addr: 49.235.136.223:8848cluster-name: SH # 集群名称:上海集群loadbalancer:nacos:enabled:true# 同样需要开启负载均衡策略

重启服务,观察 Nacos 控制台,SH 集群下多了一个实例

在这里插入图片描述

复制 product-service 启动配置,添加 VMOption,设置 9091 和 9092 端口实例的机房为 BJ:

-Dserver.port=9091 -Dspring.cloud.nacos.discovery.cluster-name=BJ -Dserver.port=9092 -Dspring.cloud.nacos.discovery.cluster-name=BJ 

观察 Nacos,在 BJ 集群下多了两个实例

在这里插入图片描述

order-service 配置集群名称

spring:cloud:nacos:discovery:server-addr: 49.235.136.223:8848cluster-name: SH # 集群名称: 上海集群loadbalancer:nacos:enabled:true# 同样需要开启负载均衡策略
在这里插入图片描述

② 测试

  1. 对接口访问多次,观察日志,会发现只有 9090 端口的实例收到了请求(同集群)
  2. 把 9090 端口的实例进行下线(SH集群),再次访问接口,观察日志,发现 9091 端口和 9092 端口的实例收到了请求。
在这里插入图片描述

Read more

Flutter 三方库 serial_csv 的鸿蒙化适配指南 - 实现极速的流式 CSV 数据编解码、支持端侧超大规模表格数据的高效序列化实战

Flutter 三方库 serial_csv 的鸿蒙化适配指南 - 实现极速的流式 CSV 数据编解码、支持端侧超大规模表格数据的高效序列化实战

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 serial_csv 的鸿蒙化适配指南 - 实现极速的流式 CSV 数据编解码、支持端侧超大规模表格数据的高效序列化实战 前言 在进行 Flutter for OpenHarmony 的金融报表、工业数据采集或大型列表导出应用开发时,CSV(Comma-Separated Values)由于其通用的文本属性成为首选的数据交换格式。然而,当文件达到数万行甚至更庞大时,常规的字符串拼接会导致内存爆炸。serial_csv 是一款专为极致性能设计的流式解析库。本文将探讨如何在鸿蒙端构建稳健、低开销的大数据处理方案。 一、原原理性解析 / 概念介绍 1.1 基础原理 serial_csv 采用了一种“增量扫描(Incremental Scanning)”算法。在读取时,它不一次性将整个文件加载进内存,而是通过缓冲区轮询,

By Ne0inhk
Flutter for OpenHarmony:debounce_throttle 防抖与节流的艺术(优化用户交互与网络请求) 深度解析与鸿蒙适配指南

Flutter for OpenHarmony:debounce_throttle 防抖与节流的艺术(优化用户交互与网络请求) 深度解析与鸿蒙适配指南

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在 UI 交互开发中,有两种极其常见的性能问题: 1. 用户狂点按钮:导致发起了 10 次重复的表单提交请求。 2. 搜索框实时搜索:用户每输入一个字母就触发一次 API 搜索,浪费流量且导致界面闪烁。 解决这两个问题的标准答案是:防抖 (Debounce) 和 节流 (Throttle)。 虽然我们可以自己写 Timer 来实现,但处理 Timer 的销毁、重启逻辑很容易出错(造成内存泄漏或 NPE)。 debounce_throttle 库提供了封装良好、线程安全的防抖节流工具类,专为 Dart/Flutter 设计。 对于 OpenHarmony 应用,合理使用这些策略能显著降低 CPU 占用,

By Ne0inhk
Flutter 组件 slug 的适配 鸿蒙Harmony 实战 - 驾驭文本语义规范化、实现鸿蒙端中英混合标题转规范化文件名与 URL 路径方案

Flutter 组件 slug 的适配 鸿蒙Harmony 实战 - 驾驭文本语义规范化、实现鸿蒙端中英混合标题转规范化文件名与 URL 路径方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 slug 的适配 鸿蒙Harmony 实战 - 驾驭文本语义规范化、实现鸿蒙端中英混合标题转规范化文件名与 URL 路径方案 前言 在鸿蒙(OpenHarmony)生态的电商产品展示、博客文章发布以及分布式文件存储系统的开发中,如何处理具备高度随机性、包含特殊字符甚至是多语言混合的“文本标题”是一个常见的工程痛点。面对用户输入的 鸿蒙 0307 批次:跨平台实战! 这种长标题。如果直接将其作为文件名保存,可能会因为文件系统对特殊符号(如冒号、感叹号)的限制导致报错;如果将其作为 URL 路径,则会产生由于繁琐的百分比编码(URL Encoding)导致的地址不可读问题。 我们需要一种“语义透明、路径友好”的转码艺术。 slug 是一套专注于将杂乱文本转化为极致精简、规范化短链(

By Ne0inhk
Flutter for OpenHarmony:hotreloader Dart 控制台应用的热重载神器(提升工具开发效率) 深度解析与鸿蒙适配指南

Flutter for OpenHarmony:hotreloader Dart 控制台应用的热重载神器(提升工具开发效率) 深度解析与鸿蒙适配指南

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 Flutter 最让人爱不释手的特性之一就是 Hot Reload (热重载)。修改 UI 代码,保存,界面瞬间刷新,状态还能保留。 但是,如果你正在开发一个 纯 Dart 控制台应用(比如 CLI 工具、后端服务、或者跑在服务器上的爬虫脚本),默认情况下你是没有热重载的。每次改一行代码,都要 Ctrl+C 停止,然后重新 dart run,这简直是折磨。 hotreloader 库通过监听文件系统变化并利用 Dart VM Service 的重载能力,为你的 Dart 控制台应用带来了类似 Flutter 的热重载体验。 对于 OpenHarmony

By Ne0inhk