欢迎光临
我们一直在努力

Nacos

Nacos

Nacos官方文档: https://nacos.io/zh-cn/docs/what-is-nacos.html

Nacos是什么

Nacos提供了统一配置管理、服务发现与注册。

其中服务注册和发现的功能,相当于dubbo里面使用到的zookeeper、 或者spring cloud里面应用到的

consoul以及eureka

而统一配置管理则相当于Spring Cloud Config或者携程的apollo

他是一个多功能集成组件。

Nacos的特性

服务发现和服务健康监测

Nacos提供了基于RPC的服务发现,服务提供者可以将自身的服务通过原生API或者openApi来实现服务

的注册,服务消费者可以使用API或者Http来查找和发现服务

同时,Nacos提供了对服务的实时监控检查,当发现服务不可用时,可以实现对服务的动态下线从而阻

止服务消费者向不健康的服务发送请求。

配置管理

传统的配置管理,是基于项目中的配置文件来实现,当出现配置文件变更时需要重新部署,而动态配置

中心可以将配置进行统一的管理,是的配置变得更加灵活以及高效。

动态配置中心可以实现路由规则的动态配置、限流规则的动态配置、动态数据源、开关、动态UI等场景

国内比较有名的开源配置中心: Apollo / Spring Cloud Config/ disconf

简述服务配置中心和注册中心

服务注册中心

服务注册中心是服务实现服务化管理的核心组件,类似于目录服务的作用,主要用来存储服务信息,譬

如提供者 url 串、路由信息等。服务注册中心是微服务架构中最基础的设施之一。

注册中心可以说是微服务架构中的通讯录,它记录了服务和服务地址的映射关系。在分布式架构中,

服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址,进行调用。

简单理解就是:在没有注册中心时候,服务间调用需要知道被当服务调方的具体地址(写死的

ip:port)。更换部署地址,就不得不修改调用当中指定的地址。而有了注册中心之后,每个服务在调用

别人的时候只需要知道服务名称(软编码)就好,地址都会通过注册中心根据服务名称获取到具体的服

务地址进行调用。

注册中心相关特性面试点

服务治理相关功能(服务注册,服务获取,服务下线等)

这是一个注册中心的基本功能,拥有这些功能才能算得上是一个注册中心

架构特性

CAP定理 可用性 一致性 分区容错性

配置中心

随着业务的发展、微服务架构的升级,服务的数量、程序的配置日益增多(各种微服务、各种服务器地

址、各种参数),传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求:

安全性:配置跟随源代码保存在代码库中,容易造成配置泄漏;时效性:修改配置,需要重启服务才能生效;

局限性:无法支持动态调整:例如日志开关、功能开关;

因此,我们需要配置中心来统一管理配置!把业务开发者从复杂以及繁琐的配置中解脱出来,只需专注

于业务代码本身,从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的

成功率,并为运维的细力度管控、应急处理等提供强有力的支持。

配置中心相关特性面试点

配置隔离

环境隔离:不同环境配置隔离(开发、测试、预发布、灰度/线上)

访问层面的隔离:比如命名空间,不同的空间相互是隔离的,不能相互访问

配置推送刷新

配置在修改后能够实时的推送到应用程序中进行更新,这个是最重要的一个功能,用户体验也是非

常好的。在没用配置中心之前,有用 Mysql 进行配置存储的,为了提高性能,减小数据库的压

力,配置信息读取后会放入缓存中,后台会启动一个定时线程去更新,比如 1 分钟一次。

这样带来的问题就是配置改完后需要等待一定的时间客户端才能更新好,一般场景都没啥问题,对

于一些特殊的场景还是需要改完立马生效,才能尽可能避免某些业务问题带来的损失。

对于配置修改及时更新的实现方式目前主要分为两种:推和拉。

拉模式前面讲过了,有时间间隔问题,就算设置的很快,比如 1 秒一次,频率太高会导致服务端

压力过大。

推模式是比较好的方式,当服务端有变动的时候将变更的信息推送给客户端,即及时又能减轻定时

拉取的频率。

更好的方式是推拉结合,目前主流的配置中心都是采用这种方式。推保证及时性,拉用于兜底,保

证最终配置一致性,推拉结合的模式可以将拉取的时间放长,降低服务端压力。

实现一个注册中心应该要考虑些什么?

咱们今天主要来聊Nacos注册中心方面的功能,做为一个注册中心,实际上不管是NacosEureka,只

要是身份注册中心,那么必然会有三大核心要素

举例:订单需要商品的相关信息,所以需要订单与商品模块进行通信。而通信的前提是我需要你的Ip

端口号以及对应的serviceName

服务提供者

服务提供者,将自己的服务信息(IP,端口号,serviceName等)提供到注册中心服务端上去。

服务消费者

服务的消费者,用来获取服务列表,并且通过应用负载均衡策略调用相应服务的提供者

注册中心服务端

注册中心的服务端,提供服务注册与发现功能。

而我们注册中心的所有操作其实就是这三个核心要素之间的交互。以及其自身的内部结构剖析。

服务提供者把自己的协议地址注册到Nacos server

服务消费者需要从Nacos Server上去查询服务提供者的地址(根据服务名称)

Nacos Server需要感知到服务提供者的上下线的变化

服务消费者需要动态感知到Nacos Server端服务地址的变化

当实现了上述功能之后,我们注册中心的雏形才初步建立。那么我们的nacos是怎么做的呢?

我们可以尝试着分析一下nacos的注册流程。

Nacos的基本应用

首先,我们需要先启动Nacos服务,启动服务有两种方式,一种是直接下载已经编译好的包直接运行。

另一种是通过源码来构建。 我们先使用第一种方式

因为目前版本发布比较频繁,所以我们讲的时候,它的内容也一直在变化。基本上我们只需要简单了解

它的应用就行

配置数据库

进入conf文件夹,配置Nacos的数据库。

首先新建一个数据库,名称随意,最好为nacos

然后导入conf下的mysql-nacos.sql脚本

application.properties文件中找到如下图中位置,修改数据库连接

单节点启动服务

bin目录下

不过windows启动前需要先进行改动startup.cmd脚本

启动成功后访问页面

地址: http://localhost:8848/nacos/

### If use MySQL as datasource:

spring.datasource.platform=mysql //数据库连接类型
### Count of DB:
db.num=1 //数据库数量
### Connect URL of DB:
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?
characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
&useUnicode=true&useSSL=false&serverTimezone=UTC //ip端口号以及数据库名称
db.user.0=root //数据库账号
db.password.0=root //数据库密码
linux系统下: sh startup.sh -m standalone
window系统: cmd startup.cmd
将set MODE="cluster" 改为 set MODE="standalone"建立一个Maven模板项目,添加Dubbo以及Nacos配置中心以及注册中心相关依赖
建立完成之后配置
application.properties文件中:
bootstrap.properties文件中
这个时候我们启动项目,可以发现我们的项目已经注册到我们的Nacos之上
那么这个时候我们已经完成了我们的注册中心应该拥有的第一个功能
服务提供者把自己的协议地址注册到Nacos server
那么他到底是如何完成的我们的注册操作呢?

Nacos架构原理剖析

# Nacos 服务发现与注册配置,其中子属性 server-addr 指定 Nacos 服务器主机和端口

spring.cloud.nacos.discovery.service-addr= 192.168.1.44:8848

# 设置配置中心服务端地址 我们这节课只讲解注册中心 可以注释

spring.cloud.nacos.config.server-addr=192.168.1.44:8848

服务 (Service)

服务是指一个或一组软件功能(例如特定信息的检索或一组操作的执行),其目的是不同的客户端可以

为不同的目的重用(例如通过跨进程的网络调用)。Nacos 支持主流的服务生态,如 Kubernetes

ServicegRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service.

服务注册中心 (Service Registry)

服务注册中心,它是服务,其实例及元数据的数据库。服务实例在启动时注册到服务注册表,并在关闭

时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务

实例的健康检查 API 来验证它是否能够处理请求。

服务元数据 (Service Metadata)

服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策

略等描述服务的数据

服务提供方 (Service Provider)

是指提供可复用和可调用服务的应用方

服务消费方 (Service Consumer)

是指会发起对某个服务调用的应用方

交互逻辑

实际上我们会发现,我们的交互是由服务注册中心,服务提供方,以及消费者三方进行逻辑交互,并且

借用服务元数据做为交互资料。并且由最底层的算法来保证其架构特性。

服务治理相关功能源码解析

源码下载

将编译完成的nacos源码导入到idea开发工具中;进入到nacos-console模块下,启动该模块下的

com.alibaba.nacos.Nacos类。

git clone https://github.com/alibaba/nacos.git但通常情况下,会报如下错误:

这是由于nacos默认使用的是集群方式,启动时会到默认的配置路径下,寻找集群配置文件

cluster.conf

我们源码运行时,通常使用的是单机模式,因此需要在启动参数中进行设置,在jvm的启动参数中,添

-Dnacos.standalone=true

设置完毕后,再次启动时,nacos启动成功,打开http://192.168.18.101:8848/nacos/index.html控制

台首页,使用默认的用户名/密码(nacos/nacos)即可以正常登录成功。

1.服务注册源码分析

赞(0)
未经允许不得转载:171主机测评 » Nacos
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址