精华内容
下载资源
问答
  • NACOS注册中心
    千次阅读
    2022-02-26 14:36:04

    Nacos注册中心

    概述

    在聊Nacos注册中心前,我们先聊聊什么是注册中心,以现实生活中为例,假如我现在要开一家公司,那么我需要去相应的单位注册相应的证明,注册好以后,我的公司才能被查到,外界也就可以获取到我公司的服务项,Nacos原理也是这样的,其实Nacos就是一个中介平台,我们将不同的服务放到Nacos中,以供其他访问相应的服务.

    背景分析

    在微服务中,首先第一个问题就是,这么多服务,我们如何去查找,其次就是如何将各个服务之间建立关系枢纽,服务与服务业如何进行业务的调用,如何简单快捷的管理这些服务.基于以上种种,注册中心诞生了.

    注册中心的分类:

    Zookeeper(雅虎Apache),Eureka(Netfix),Nacos(Alibaba),Consul(Google) ,其中国内常用的是由阿里巴巴团队研发的Nacos注册中心,其稳定性,社区活跃度,可靠性,功能方面都很优秀,能抗住每年双十一活动的服务冲击.

    Nacos概述

    Nacos是一个服务注册,发现,配置管理的平台,由阿里巴巴开发并维护,使用方便,稳定可靠,官网如下

    https://nacos.io/zh-cn/docs/quick-start.html

    Nacos下载及配置

    环境配置

    第一:首先需要保证电脑已经配置好JAVA_HOME,Nacos启动时需要

    在这里插入图片描述

    第二:查看数据库版本(mysql在5.7以上,mariaDB在10.5以上)

    Nacos下载以及配置

    第三步下载相应版本的Nacos
    在这里插入图片描述

    注意选择下载zip,下载后直接解压即可,解压路径不要包含中文.
    在这里插入图片描述

    初始化配置

    我们需要查找外部nacos-mysql.sql的表数据,大家可以自行查询

    库大概是这样子的,里边包含一些表,比如登录Nacos时的账号密码.
    在这里插入图片描述

    找到相应数据库后,打开cmd登录Mysql,

    执行:source d:/allsoft/nacos/nacos-mysql.sql

    注意这个路径大家的数据库放在了那个路径就输入哪个.

    第三步:配置D:\allsoft\nacos\conf目录下的application.properties,大家会发现这个配置文件很熟悉,其实Nacos本身就是由SpringBoot开发的.
    在这里插入图片描述

    注意相应的配置参数按照自己的需要进行修改.有#号的该去掉的就去掉

    Nacos服务启动与访问

    Windows系统:

    需要在nacos/bin目录下打开DOS窗口,输入命令

    startup.cmd -m standalone

    此命令代表单机模式运行,非集群模式

    Linux系统:

    ./startup.sh -m standalone

    访问Nacos

    在地址栏输入:http://localhost:8848/nacos ,显示如下界面

    在这里插入图片描述

    默认账号密码都是nacos

    更多相关内容
  • spring cloud nacos的可视化界面,微服务可以注册nacos,支持CP,AP两种方式。
  • spring boot 搭建nacos注册中心的框架
  • Nacos注册中心的部署与用法详细介绍

    万次阅读 2022-02-13 22:48:44
    注册中心是微服务架构中的纽带,类似于”通讯录“,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址并进行调用。注册中心本质上是为了解耦...

    一、什么是注册中心:

             我们知道微服务彼此间独立部署、具有清晰的边界,服务间通过远程调用来构建复杂的业务功能。而服务册中心在微服务项目中扮演着非常重要的角色,那么注册中心又是什么,使用服务注册中心可以解决微服务中的哪些问题呢?

    1、什么是注册中心:

            注册中心是微服务架构中的纽带,类似于“通讯录”,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址并进行调用。注册中心本质上是为了解耦服务提供者和服务消费者。对于任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的,更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和分布往往是动态变化的,也是无法预先确定的。因此,原本在单体应用阶段常用的静态LB机制就不再适用了,需要引入额外的组件来管理微服务提供者的注册与发现,而这个组件就是服务注册中心。

     2、注册中心的核心功能:

    • 服务注册:服务实例将自身服务信息注册到注册中心
    • 服务发现:服务实例通过注册中心,获取到注册到其中的服务实例的信息,通过这些信息去请求它们提供的服务
    • 服务剔除:服务注册中心将出问题的服务自动剔除到可用列表之外,使其不会被调用到

    3、注册中心解决的问题:

    (1)屏蔽、解耦服务之间相互依赖的细节:

            服务之间的远程调用必须要知道对方IP、端口。但是该调用方式存在明显的问题,如被调用的IP、端口变化后,调用方也要同步修改。通过服务发现,将服务之间IP与端口的依赖转化为服务名的依赖,服务名可以根据具体微服务业务来做标识。

    (2)对服务进行动态管理:

            在微服务架构中,服务数量多且依赖错综复杂,无论是服务主动停止、意外挂掉,还是因为流量增加对服务扩容,这些服务状态上的动态变化,都需要尽快的通知到被调用方,被调用方才采取相应的措施。所以,对于服务注册中心要实时管理服务的数据与状态,包括服务的注册上线、服务主动下线,异常服务的剔除。

    (3)降低服务端负载均衡中间件的压力:

            当服务越来越多时,服务 URL 配置管理变得非常困难,服务端的负载均衡中间件,比如 F5、Nginx 压力也越来越大。通过服务注册中心,就可以实现动态地注册和发现服务,使服务的位置透明,并通过在消费方获取服务提供方地址列表,实现软负载均衡和 Failover,降低对服务端的负载均衡中间件,也能减少部分成本。

    4、服务的发现与注册的实现模式:

            上面提到,硬件的 F5、软件的 Nginx 也可以实现服务的发现,那么这与注册中心的服务发现有什么区别呢?这其实是服务发现与注册的两种实现模式:服务端的发现模式 和 客户端的发现模式。F5、Nginx 属于服务端的发现模式,服务注册中心属于客户端的发现模式,两种模式各有优缺点,也适用于不同的场景,对于大型应用一般会有多层负载,外层用服务器端负载均衡,内部用客户端负载均衡。接下来我们就具体看看两种服务发现模式是怎么样的:

    (1)服务端的发现模式:

            服务端的发现模式是通过使用一个中间的服务器,来屏蔽被调用服务的复杂性与变动性,当有新的服务加入或老服务剔除时,只需要修改中间服务器上的配置即可,此模式的显著特点是:引入独立的中间代理服务器来屏蔽真实服务的具体细节。

            如下图所示:当服务A要调用服务B时,先通过 DNS 域名解析找到 Nginx 服务器,然后将请求发送给Nginx,因为在 Nginx 上配置了服务B的真实访问地址,Nginx 收到请求后根据负载均衡算法,将请求转发到某个真实的服务B,服务B将请求结果返回给 Nginx,Nginx 再将返回结果给服务A,整个请求流程结束。当然中间服务器不一定非得是 Nginx,还可以是基于硬件的 F5,也可以是工作在传输层的 IP 负载均衡等。

            该模式的优点是:配置集中在独立的中间服务器端完成,对代码没有任何入侵,也不存在跨平台跨语言的问题。但缺点也很明显,因为所有请求都需要穿透中间服务器,所以中间服务器会成为一个单点,对性能也会有所影响。

    (2)客户端的发现模式:

            我们再看看客户端的发现模式,服务A调用服务B时,不需要通过中间服务器,而是在自己进程内维护了服务B的信息,再通过负载算法选择一个服务B直接调用。那服务A具体是怎么维护服务B的信息呢?为此引入了服务注册中心的概念,当服务B启动时向注册中心注册自己(将自己的信息发送到注册中心的注册表里),服务A再从注册中心获取所有注册的服务,这就是客户端模式的基本原理。

            客户端模式因为在进程内直接调用服务,也叫做进程内负载,由于不需要穿透中间服务器,所以客户端模式的性能损耗比较小。但是,需要在服务内部维护服务注册信息,负载算法等,有一定的代码入侵性,对于跨平台,跨语言的支持不太友好。

    5、服务注册表:

            微服务架构中,所有的服务启动后都通过注册中心来注册自己,同时把注册中心里面的服务信息拉回本地,后续调用时就直接检查本地的服务和节点信息来进行服务节点的调用。每个服务节点都会来注册中心进行服务注册,那注册信息是如何在服务端保存的呢,其实就是注册表,服务注册的时候把自己的信息上报上来,然后注册中心把注册表,返回给客户端,那服务之间就知道要调用服务的节点了。

            服务注册表需要高可用而且随时更新。客户端能够缓存从服务注册表中获取的服务地址,然而,这些信息最终会过时,客户端也就无法发现服务实例。因此,服务注册表会包含若干服务端,并使用复制协议保持一致性。服务注册表不能是单点,否则存在单点故障,当服务注册表有多台服务器的时需要考虑服务注册表的信息在多台机器上的实时同步和一致。

    二、主流服务注册中心的对比:

     (1)Zookeeper 和 Consul 遵循 CP 原则,保证了强一致性和分区容错性,放弃可用性,在分布式环境中,如果涉及数据存储的场景,数据一致性应该是首先被保证的,但对于服务发现来说,可用性才是最核心的,针对同一个服务,即使注册中心的不同节点保存的服务提供者信息不相同,也并不会造成灾难性的后果。因为对于服务消费者来说,能消费才是最重要的,消费者拿到不正确的服务实例信息后尝试消费一下,也胜过因为无法获取实例信息而不去消费而导致系统异常

    (2)Eureka 遵循 AP 原则,保证可用性,放弃数据一致性,基本能满足注册中心所需的核心功能,但 Eureka 2.x 版本已停止开发,并且宣布如果继续使用的话,风险自负。

    (3)Nacos 同时支持 AP 与 CP,默认是 AP,同时功能更丰富,与 SpringCloud Alibaba 的兼容性更好,使用更简单灵活,可以满足更多的业务场景,且支持 K8S 的集成。

    不同的服务注册中心组件的应用场景不同,读者可以根据自己的业务情况进行选型。但下文我们主要以 Nacos 注册中心为例进行介绍,其他几种注册中心读者自行上网查阅

    三、Nacos 注册中心的部署与使用:

    1、Nacos 注册中心的搭建:

            我们先去 Nacos 的 Github(Tags · alibaba/nacos · GitHub)下载我们所需的 Nacos 版本,可以选择 windows 或者 Linux,如下图:

            由于当时在搭建项目的时候,考虑到与 SpringBoot 和 SpringCloud 的版本对应问题,我这里是下载了 2.0.0 的版本进行搭建,读者可以根据自己的情况选择对应的 Nacos 版本。

     1.1、Windows 环境:

    下载并解压 nacos-server-2.0.0.zip,解压完成后进入 /bin 目录,可以看到下面两个脚本:

    windows 环境直接运行 startup.cmd 启动项目,出现以下界面则启动完成:

    在浏览器输入 http://localhost:8848/nacos 进入Nacos的登录界面,用户名与密码默认都是 nacos,登录成功后界面如下:

    1.2、Linux 环境:

            Nacos 在 Linux 环境下的启停跟在 windows 环境的启停基本一致,先下载 nacos-server-2.0.0.tar.zip 压缩包,然后上传到 Linux 服务器上进行解压(解压命令:tar -zxvf nacos-server-2.0.0.tar.gz),解压完成后同样进入 /bin 目录执行启动命令(单机模式启动命令:sh startup.sh -m standalone),启动完成后再访问 nacos 控制台地址(http://服务器ip地址:8848/nacos/index.html)验证是否成功启动即可。

    2、SpringBoot 整合 Nacos 进行服务注册发现:

    我们首先看一下 nacos 的简单架构图:

    参照上面的架构图,我们分别创建两个模块,分别是 cloud-producer-server(服务提供者)、cloud-consumer(服务消费者),职责如下:

    • cloud-producer-server:注册进入nacos-server,对外暴露服务
    • cloud-consumer:注册进入nacos-server,调用 cloud-producer-server 的服务

    创建这两个模块前,我们先声明项目的版本信息:

    <properties>
        <spring-boot.version>2.3.2.RELEASE</spring-boot.version>
        <spring-cloud.version>Hoxton.SR9</spring-cloud.version>
        <spring-cloud-alibaba.version>2.2.6.RELEASE</spring-cloud-alibaba.version>
    </properties>
    
    <!--  只声明依赖,不引入依赖 -->
    <dependencyManagement>
        <dependencies>
            <!-- 声明springBoot版本 -->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>${spring-boot.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <!-- 声明springCloud版本 -->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <!-- 声明 springCloud Alibaba 版本 -->
            <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>
        </dependencies>
    </dependencyManagement>

    2.1、创建服务提供者 cloud-producer-server:

    (1)引入maven依赖:

      	<!-- 引入阿里的nacos作为服务注册中心 -->
    	<dependency>
          <groupId>com.alibaba.cloud</groupId>
          <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    	</dependency>

    (2)添加 nacos 相关的配置信息:

    在 application.properties 配置文件指定服务名称、端口号、nacos-server 的地址信息,如下:

    spring.application.name = cloud-producer-server
    server.servlet.context-path = /${spring.application.name}
    server.port=9000
    
    # nacos注册中心配置
    spring.cloud.nacos.discovery.server-addr = localhost:8848
    spring.cloud.nacos.discovery.namespace = 91b5489b-d009-4725-86fa-534f760b4d04
    spring.cloud.nacos.discovery.register-enabled = true

    (3)开启服务注册发现的功能:

    在主 Application 启动类加入 @EnableDiscoveryClient 注解开启服务注册发现的功能,如下:

    /**
     * SpringBoot启动类
     * @EnableDiscoveryClient 开启服务注册发现的功能
     */
    @EnableDiscoveryClient
    @SpringBootApplication
    public class ProducerApplication
    {
    	public static void main(String[] args)
    	{
    		SpringApplication.run(ProducerApplication.class, args);
    	}
    }

    (4)实现个演示功能:

            cloud-producer-server 作为服务提供者注册到 nacos 中,肯定需要提供个服务来供消费者 cloud-consumer 调用,下面简单写一个演示接口:

    @RestController
    @RequestMapping (value = "/")
    public class CloudController
    {
        @PostMapping ("getSum")
        public String getSum(@RequestParam (value = "num1") Integer num1, @RequestParam (value = "num2") Integer num2)
        {
             return "success:两数求和结果=" + (num1 + num2);
        }
    }

    (5)启动项目:

            启动项目之后,我们进入 nacos 控制台,在 nacos 的 “服务管理->服务列表” 的 “91b5489b-d009-4725-86fa-534f760b4d04” 空间中将会发现注册进入的 cloud-producer-server 这个服务,如下图:

     2.2、创建服务消费者 cloud-consumer:

    服务消费者的创建步骤与服务提供者基本一致

    (1)引入maven依赖:

      	<!-- 引入阿里的nacos作为服务注册中心 -->
    	<dependency>
          <groupId>com.alibaba.cloud</groupId>
          <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    	</dependency>

    (2)添加 nacos 相关的配置信息:

    spring.application.name = cloud-consumer
    server.port=9001
    
    # nacos注册中心配置
    spring.cloud.nacos.discovery.server-addr = localhost:8848
    spring.cloud.nacos.discovery.namespace = 91b5489b-d009-4725-86fa-534f760b4d04
    spring.cloud.nacos.discovery.register-enabled = true

    (3)开启服务注册发现的功能:

    /**
     * SpringBoot启动类
     * @EnableDiscoveryClient 开启服务注册发现的功能
     */
    @EnableDiscoveryClient
    @SpringBootApplication
    public class ConsumerApplication
    {
    	public static void main(String[] args)
    	{
    		SpringApplication.run(ConsumerApplication.class, args);
    	}
    }

    (4)调用服务提供方的演示功能:

            cloud-producer-server 服务提供方提供一个演示功能,那我们如何调用该功能呢?其实 Nacos 集成了 Ribbon(有关 Ribbon 的详细介绍请参考这篇文章:https://blog.csdn.net/a745233700/article/details/122916856),因此我们便能使用 Ribbon 的负载均衡来调用服务,步骤如下:

    ① 创建 RestTemplate,使用 @LoadBalanced 注解标注开启负载均衡:

    @Configuration
    public class RestConfig
    {
        /**
         * 创建restTemplate对象。
         * LoadBalanced注解表示赋予restTemplate使用Ribbon的负载均衡的能力(一定要加上注解,否则无法远程调用)
         */
        @Bean
        @LoadBalanced
        public RestTemplate restTemplate(){
            return new RestTemplate();
        }
    }

    ② 通过 RestTemplate 请求远程服务地址并接收返回值

    @RestController
    @RequestMapping (value = "api/invoke")
    public class InvokeController
    {
        @Autowired
        private RestTemplate restTemplate;
    
        /**
         * 使用 RestTemplate 进行远程服务调用,并且使用 Ribbon 进行负载均衡
         */
        @ApiOperation (value = "RestTemplate", notes = "使用RestTemplate进行远程服务调用,并使用Ribbon进行负载均衡")
        @GetMapping ("getByRestTemplate")
        public String getByRestTemplate(Integer num1, Integer num2)
        {
            //第一个cloud-producer-server代表在nacos注册中心中的服务名,第二个cloud-producer-server代表contextPath配置的项目路径
            String url = "http://cloud-producer-server/cloud-producer-server/getSum";
            MultiValueMap<String, Object> params = new LinkedMultiValueMap<>();
            params.add("num1", num1);
            params.add("num2", num2);
    
            //通过服务名的方式调用远程服务(非ip端口)
            return restTemplate.postForObject(url, params, String.class);
        }
    }

    (5)启动测试,查看nacos注册中心控制面板情况

            启动成功后将会在 nacos 中的服务列表中看到 cloud-consumer,如下图:

     那么接下来就测试下服务能否调的通?访问服务消费方的 api/invoke/getByRestTemplate接口,可以看到请求结果如下:

    3、Nacos 的集群化部署:

            前面的介绍中,我们并未对 Nacos 服务端做任何特殊的配置,一切均以默认的单机模式运行,但是单机运行模式仅适用于学习与测试环境,对于有高可用要求的生产环境显然是不合适的。那我们怎么搭建支持高可用的集群环境呢?

            在搭建 Nacos 集群前,我们需要先修改 Nacos 的数据持久化配置为 MySQL 存储。默认情况下,Nacos 使用内嵌的数据库 Derby实现数据的存储,这种情况下,如果启动多个默认配置下的 Nacos 节点,数据存储是存在一致性问题的。为了解决这个问题,Nacos 采用了集中式存储的方式来支持集群化部署,但目前 Nacos 只支持 MySQL 的存储,且版本要求:5.6.5+

    3.1、Nacos 配置的持久化:

    (1)初始化 MySQL 数据库:

            首先在 MySQL 中新建一个数据库 nacos-config(名称随意),然后执行 Nacos 中的SQL脚本,该脚本是 Nacos-server 的 conf 文件夹中的 nacos-mysql.sql,如下图:

    执行该脚本,将会自动创建表,如下图:

     (2)修改 conf/application.properties 配置文件:

            Nacos-server 也是一个Spring Boot 项目,想要连接自己的数据库,当然要配置数据源了,配置文件同样在 Nacos-server 中的 conf 目录下,如下图:

     只需要将 application.properties 中的 Mysql 配置成自己的数据源并重启 Nacos-server 即可 ,如下:

    # 此项一定要启用,默认是注释掉的
    spring.datasource.platform=mysql
    
    # 注意MySQL8.0以上版本指定url时一定要带入serverTimezone参数
    db.num=1
    db.url.0=jdbc:mysql://localhost:3306/nacos_config?serverTimezone=Asia/Shanghai&characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
    db.user=root
    db.password=123456
    
    # 可选启用配置
    nacos.cmdb.dumpTaskInterval=3600
    nacos.cmdb.eventTaskInterval=10
    nacos.cmdb.labelTaskInterval=300
    nacos.cmdb.loadDataAtStart=false

    3.2、Nacos 集群化部署:

            Nacos 官方推荐在生产环境使用集群模式部署,这样可以避免单点故障,集群化部署的架构图如下:

    ​        请求先通过 Nginx 集群进行转发到 Nacos 集群中,当然为了保持高可用,数据库也需要是集群模式。那么接下来我们就演示下搭建 Nacos 集群的方法。

    ​        由于条件限制,我们仅在一台服务器上启动三个Nacos服务演示。Nacos的端口分别为8848、8849、8850。

    (1)修改端口号:

    ​        Nacos 默认的端口号是 8848,那么如何修改端口呢?只需要修改 conf 目录下的 application.properties 中的 server.port 即可,如下图:

    (2)修改集群配置:

    那么如何配置集群呢?在 conf 目录下有一个 cluster.conf.example 文件,如下图:

    只需要将 cluster.conf.example 这个文件复制一份为 cluster.conf 放在 conf 目录下,其中配置的内容如下:

    172.16.1.84:8848
    172.16.1.84:8849
    172.16.1.84:8850

    (3)修改数据源:

    这个在持久化的那里已经讲过了,只需要将 application.properties 中的数据源替换掉,如下:

    # 此项一定要启用,默认是注释掉的
    spring.datasource.platform=mysql
    
    # 注意MySQL8.0以上版本指定url时一定要带入serverTimezone参数
    db.num=1
    db.url.0=jdbc:mysql://localhost:3306/nacos_config?serverTimezone=Asia/Shanghai&characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
    db.user=root
    db.password=123456
    
    # 可选启用配置
    nacos.cmdb.dumpTaskInterval=3600
    nacos.cmdb.eventTaskInterval=10
    nacos.cmdb.labelTaskInterval=300
    nacos.cmdb.loadDataAtStart=false

    (4)启动Nacos:

            经过上述的步骤 Nacos 集群已经配置好了,启动 Nacos 成功后,访问任意一个端口的 Nacos 服务,在 “集群管理->节点列表” 中将会看到自己搭建的三个节点,如下图:

    至此,Nacos集群算是搭建完成了

    (5)Nginx 中的配置:

    此处就不演示Nginx集群搭建了,直接在单机的Nginx中配置。直接修改nginx的conf文件,内容如下:

    upstream nacos{
    		server 172.16.1.84:8848;
    		server 172.16.1.84:8849;
    		server 172.16.1.84:8850;
    	 }
    	 
    	 server{
    		listen 80;
    		location / {
    			proxy_pass http://nacos;
    		}
    	 }

    (6)项目中配置 server-addr:

    既然搭建了集群,那么项目中也要配置一下,有两种方式,下面分别介绍:

    第一种:通过直连的方式配置,如下:

    spring:
      application:
        ## 指定服务名称,在nacos中的名字
        name: cloud-producer-server
      cloud:
        nacos:
          discovery:
            # nacos的服务地址,nacos-server中IP地址:端口号
            server-addr: 172.16.1.84:8848,172.16.1.84:8849,172.16.1.84:8850

    第二种:直接连接Nginx,如下:

    spring:
      application:
        ## 指定服务名称,在nacos中的名字
        name: cloud-producer-server
      cloud:
        nacos:
          discovery:
            # nacos的服务地址,nacos-server中IP地址:端口号
            server-addr: 172.16.1.84:80

    Nacos 集群搭建非常简单,唯一的配置就是在 cluster.conf 中设置三个 Nacos 服务的地址。


    相关阅读:

    常见的服务器架构入门:从单体架构、EAI 到 SOA 再到微服务和 ServiceMesh

    常见分布式理论(CAP、BASE)和一致性协议(Gosssip协议、Raft一致性算法)

    一致性哈希算法原理详解

    Nacos注册中心的部署与用法详细介绍

    Nacos配置中心用法详细介绍

    SpringCloud OpenFeign 远程HTTP服务调用用法与原理

    什么是RPC?RPC框架dubbo的核心流程

    服务容错设计:流量控制、服务熔断、服务降级

    sentinel 限流熔断神器详细介绍

    Sentinel 规则持久化到 apollo 配置中心

    Sentinel-Dashboard 与 apollo 规则的相互同步

    Spring Cloud Gateway 服务网关的部署与使用详细介绍

    Spring Cloud Gateway 整合 sentinel 实现流控熔断

    Spring Cloud Gateway 整合 knife4j 聚合接口文档

    常见分布式事务详解(2PC、3PC、TCC、Saga、本地事务表、MQ事务消息、最大努力通知)

    分布式事务Seata原理

    RocketMQ事务消息原理


    参考文章:

    微服务为什么要有服务发现与注册?

    五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强?

    展开全文
  • 一、Nacos 注册中心的设计原理 1、数据模型 2、数据⼀致性 3、负载均衡 4、健康检查 二、Nacos 注册中心服务数据模型 1、服务(Service)和服务实例(Instance) 1)定义服务 3)定义实例 4)实例元数据 ...

    目录

    一、Nacos 注册中心的设计原理

    1、数据模型

    2、数据⼀致性

    3、负载均衡

    4、健康检查

    二、Nacos 注册中心服务数据模型

    1、服务(Service)和服务实例(Instance)

    1)定义服务

     3)定义实例

    4)实例元数据

    5)持久化属性

    2、集群(Cluster)

    1、定义集群

    3、生命周期

    1)服务的⽣命周期

    2)实例的⽣命周期

    3)集群的⽣命周期

    4)元数据的⽣命周期


    一、Nacos 注册中心的设计原理

    1、数据模型

            注册中心的核心数据是服务的名字和它对应的网络地址,当服务注册了多个实例时,我们需要对不健康的实例进行过滤或者针对实例的⼀些特征进行流量的分配,那么就需要在实例上存储⼀些例如健康状态、权重等属性。随着服务规模的扩大,渐渐的又需要在整个服务级别设定⼀些权限规则、以及对所有实例都生效的⼀些开关,于是在服务级别又会设立⼀些属性。再往后,我们又发现单个服务的实例又会有划分为多个子集的需求,例如⼀个服务是多机房部署的,那么可能需要对每个机房的实例做不同的配置,这样又需要在服务和实例之间再设定⼀个数据级别。
            Zookeeper 没有针对服务发现设计数据模型,它的数据是以⼀种更加抽象的树形 K-V 组织的,因此理论上可以存储任何语义的数据。而 Eureka 或者 Consul 都是做到了实例级别的数据扩展,这可以满足大部分的场景,不过无法满足大规模和多环境的服务数据存储。Nacos 在经过内部多年生产经验后提炼出的数据模型,则是⼀种服务-集群-实例的三层模型。如上文所说,这样基本可以满足服务在所有场景下的数据存储和管理。

            Nacos 的数据模型虽然相对复杂,但是它并不强制你使用它里面的所有数据,在大多数场景下,你可以选择忽略这些数据属性,此时可以降维成和 Eureka 和 Consul ⼀样的数据模型。另外⼀个需要考虑的是数据的隔离模型,作为⼀个共享服务型的组件,需要能够在多个用户或者业务方使用的情况下,保证数据的隔离和安全,这在稍微大⼀点的业务场景中非常常见。另⼀方面服务注册中心往往会支持云上部署,此时就要求服务注册中心的数据模型能够适配云上的通用模型。
            Zookeeper、Consul 和 Eureka 在开源层面都没有很明确的针对服务隔离的模型,Nacos 则在⼀开始就考虑到如何让用户能够以多种维度进行数据隔离,同时能够平滑的迁移到阿里云上对应的商业化产品。

            Nacos 提供了四层的数据逻辑隔离模型,用户账号对应的可能是⼀个企业或者独立的个体,这个数据⼀般情况下不会透传到服务注册中心。⼀个用户账号可以新建多个命名空间,每个命名空间对应⼀个客户端实例,这个命名空间对应的注册中心物理集群是可以根据规则进行路由的,这样可以让注册中心内部的升级和迁移对用户是无感知的,同时可以根据用户的级别,为用户提供不同服务级别的物理集群。再往下是服务分组和服务名组成的二维服务标识,可以满足接口级别的服务隔离。
            Nacos 1.0.0 介绍的另外⼀个新特性是:临时实例和持久化实例。在定义上区分临时实例和持久化实例的关键是健康检查的方式。临时实例使用客户端上报模式,而持久化实例使用服务端反向探测模式。临时实例需要能够自动摘除不健康实例,而且无需持久化存储实例,那么这种实例就适用于类 Gossip 的协议。右边的持久化实例使用服务端探测的健康检查方式,因为客户端不会上报心跳, 那么自然就不能去自动摘除下线的实例

            在大中型的公司里,这两种类型的服务往往都有。⼀些基础的组件例如数据库、缓存等,这些往往不能上报心跳,这种类型的服务在注册时,就需要作为持久化实例注册。而上层的业务服务,例如微服务或者 Dubbo 服务,服务的 Provider 端支持添加汇报心跳的逻辑,此时就可以使用动态服务的注册方式。
            Nacos 2.0 中继续沿用了持久化及非持久化的设定,但是有了⼀些调整。Nacos 1.0 中持久化及非持久化的属性是作为实例的⼀个元数据进行存储和识别。这导致同⼀个服务下可以同时存在持久化实例和非持久化实例。但是在实际使用中,我们发现这种模式会给运维人员带来极大的困惑和运维复杂度;与此同时,从系统架构来看,⼀个服务同时存在持久化及非持久化实例的场景也是存在⼀定矛盾的。这就导致该能力事实上并未被广泛使用。为了简化 Nacos 的服务数据模型,降低运维人员的复杂度,提升 Nacos 的易用性,在 Nacos2.0 中我们将是否持久化的数据抽象至服务级别,且不再允许⼀个服务同时存在持久化实例和非持久化实例,实例的持久化属性继承自服务的持久化属性。

    2、数据⼀致性

            数据⼀致性是分布式系统永恒的话题,Paxos 协议的复杂更让数据⼀致性成为程序员大牛们吹水的常见话题。不过从协议层面上看,⼀致性的选型已经很长时间没有新的成员加入了。目前来看基本可以归为两家:⼀种是基于 Leader 的非对等部署的单点写⼀致性,⼀种是对等部署的多写⼀致性。当我们选用服务注册中心的时候,并没有⼀种协议能够覆盖所有场景,例如当注册的服务节点不会定时发送心跳到注册中心时,强⼀致协议看起来是唯⼀的选择,因为无法通过心跳来进行数据的补偿注册,第⼀次注册就必须保证数据不会丢失。而当客户端会定时发送心跳来汇报健康状态时,第⼀次的注册的成功率并不是非常关键(当然也很关键,只是相对来说我们容忍数据的少量写失败),因为后续还可以通过心跳再把数据补偿上来,此时 Paxos 协议的单点瓶颈就会不太划算了,这也是Eureka 为什么不采用 Paxos 协议而采用自定义的 Renew 机制的原因。这两种数据⼀致性协议有各自的使用场景,对服务注册的需求不同,就会导致使用不同的协议。在这里可以发现,Zookeeper 在 Dubbo 体系下表现出的行为,其实采用 Eureka 的 Renew 机制更加合适,因为 Dubbo 服务往 Zookeeper 注册的就是临时节点,需要定时发心跳到 Zookeeper来续约节点,并允许服务下线时,将 Zookeeper 上相应的节点摘除。Zookeeper 使用 ZAB 协议虽然保证了数据的强⼀致,但是它的机房容灾能力的缺乏,无法适应⼀些大型场景。

            Nacos 因为要支持多种服务类型的注册,并能够具有机房容灾、集群扩展等必不可少的能力,在1.0.0 正式支持 AP 和 CP 两种⼀致性协议并存。1.0.0 重构了数据的读写和同步逻辑,将与业务相关的 CRUD 与底层的⼀致性同步逻辑进行了分层隔离。然后将业务的读写(主要是写,因为读会直接使用业务层的缓存)抽象为 Nacos 定义的数据类型,调用⼀致性服务进行数据同步。在决定使用 CP 还是 AP ⼀致性时,使用⼀个代理,通过可控制的规则进行转发。目前的⼀致性协议实现,⼀个是基于简化的 Raft 的 CP ⼀致性,⼀个是基于自研协议 Distro 的AP ⼀致性。Raft 协议不必多言,基于 Leader 进行写入,其 CP 也并不是严格的,只是能保证⼀半所见⼀致,以及数据的丢失概率较小。Distro 协议则是参考了内部 ConfigServer 和开源 Eureka,在不借助第三方存储的情况下,实现基本大同小异。Distro 重点是做了⼀些逻辑的优化和性能的调优。

    3、负载均衡

            负载均衡严格的来说,并不算是传统注册中心的功能。⼀般来说服务发现的完整流程应该是先从注册中心获取到服务的实例列表,然后再根据自身的需求,来选择其中的部分实例或者按照⼀定的流量分配机制来访问不同的服务提供者,因此注册中心本身⼀般不限定服务消费者的访问策略。Eureka、Zookeeper 包括 Consul,本身都没有去实现可配置及可扩展的负载均衡机制,Eureka 的负载均衡是由 ribbon 来完成的,而 Consul 则是由 Fabio 做负载均衡
            服务端的负载均衡,给服务提供者更强的流量控制权,但是无法满足不同的消费者希望使用不同负载均衡策略的需求。而不同负载均衡策略的场景,确实是存在的。而客户端的负载均衡则提供了这种灵活性,并对用户扩展提供更加友好的支持。但是客户端负载均衡策略如果配置不当,可能会导致服务提供者出现热点,或者压根就拿不到任何服务提供者。
            抛开负载均衡到底是在服务提供者实现还是在服务消费者实现,我们看到目前的负载均衡有基于权重、服务提供者负载、响应时间、标签等策略。其中 Ribbon 设计的客户端负载均衡机制,主要是选择合适现有的 IRule、ServerListFilter 等接口实现,或者自己继承这些接口,实现自己的过滤逻辑。这里 Ribbon 采用的是两步负载均衡,第⼀步是先过滤掉不会采用的服务提供者实例,第二步是在过滤后的服务提供者实例里,实施负载均衡策略。Ribbon 内置的几种负载均衡策略功能还是比较强大的,同时又因为允许用户去扩展,这可以说是⼀种比较好的设计。
            基于标签的负载均衡策略可以做到非常灵活,Kubernetes 和 Fabio 都已经将标签运用到了对资源的过滤中,使用标签几乎可以实现任意比例和权重的服务流量调配。但是标签本身需要单独的存储以及读写功能,不管是放在注册中心本身或者对接第三方的 CMDB。

    4、健康检查

            Zookeeper 和 Eureka 都实现了⼀种 TTL 的机制,就是如果客户端在⼀定时间内没有向注册中心发送心跳,则会将这个客户端摘除。Eureka 做的更好的⼀点在于它允许在注册服务的时候,自定义检查自身状态的健康检查方法。这在服务实例能够保持心跳上报的场景下,是⼀种比较好的体验,在Dubbo 和 SpringCloud 这两大体系内,也被培养成用户心智上的默认行为。Nacos 也支持这种TTL 机制,不过这与 ConfigServer 在阿里巴巴内部的机制又有⼀些区别。Nacos 目前支持临时实例使用心跳上报方式维持活性,发送心跳的周期默认是 5 秒,Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康,在 30 秒没收到心跳时将这个临时实例摘除。
            不过正如前文所说,有⼀些服务无法上报心跳,但是可以提供⼀个检测接口,由外部去探测。这样的服务也是广泛存在的,而且以我们的经验,这些服务对服务发现和负载均衡的需求同样强烈。服务端健康检查最常见的方式是 TCP 端口探测和 HTTP 接口返回码探测,这两种探测方式因为其协议的通用性可以支持绝大多数的健康检查场景。在其他⼀些特殊的场景中,可能还需要执行特殊的接口才能判断服务是否可用。例如部署了数据库的主备,数据库的主备可能会在某些情况下切换,需要通过服务名对外提供访问,保证当前访问的库是主库。此时的健康检查接口,可能就是⼀个检查数据库是否是主库的 MYSQL 命令了。
     
            客户端健康检查和服务端健康检查有⼀些不同的关注点。客户端健康检查主要关注客户端上报心跳的方式、服务端摘除不健康客户端的机制。而服务端健康检查,则关注探测客户端的方式、灵敏度及设置客户端健康状态的机制。从实现复杂性来说,服务端探测肯定是要更加复杂的,因为需要服务端根据注册服务配置的健康检查方式,去执行相应的接口,判断相应的返回结果,并做好重试机制和线程池的管理。这与客户端探测,只需要等待心跳,然后刷新 TTL 是不⼀样的。同时服务端健康检查无法摘除不健康实例,这意味着只要注册过的服务实例,如果不调用接口主动注销,这些服务实例都需要去维持健康检查的探测任务,而客户端则可以随时摘除不健康实例,减轻服务端的压力。
     
            Nacos 既支持客户端的健康检查,也支持服务端的健康检查,同⼀个服务可以切换健康检查模式。我们认为这种健康检查方式的多样性非常重要,这样可以支持各种类型的服务,让这些服务都可以使用到 Nacos 的负载均衡能力

    二、Nacos 注册中心服务数据模型

     

    1、服务(Service)和服务实例(Instance)

    1)定义服务

    在 Nacos 中,服务的定义包括以下几个内容:

    • 命名空间(Namespace):Nacos 数据模型中最顶层、也是包含范围最广的概念,用于在类似环境或租户等需要强制隔离的场景中定义。Nacos 的服务也需要使用命名空间来进行隔离。 
    • 分组(Group):Nacos 数据模型中次于命名空间的⼀种隔离概念,区别于命名空间的强制隔离属性,分组属于⼀个弱隔离概念,主要用于逻辑区分⼀些服务使用场景或不同应用的同名服务,最常用的情况主要是同⼀个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用 提供的服务重名。 
    • 服务名(Name):该服务实际的名字,⼀般用于描述该服务提供了某种功能或能力。
            之所以 Nacos 将服务的定义拆分为命名空间、分组和服务名,除了方便隔离使用场景外,还有方便用户发现唯⼀服务的优点。在注册中心的实际使用场景上,同个公司的不同开发者可能会开发出类似作用的服务,如果仅仅使用服务名来做服务的定义和表示,容易在⼀些通用服务上出现冲突,比如登陆服务等。
     
            通常推荐使用由运行环境作为命名空间、应用名作为分组和服务功能作为服务名的组合来确保该服务的天然唯⼀性,当然使用者可以忽略命名空间和分组,仅使用服务名作为服务唯⼀标示,这就需要使用者在定义服务名时额外增加自己的规则来确保在使用中能够唯⼀定位到该服务而不会发现到错误的服务上。

    2)服务元数据

            服务的定义只是为服务设置了⼀些基本的信息,用于描述服务以及方便快速的找到服务,而服务的元数据是进⼀步定义了 Nacos 中服务的细节属性和描述信息。主要包含:
    • 健康保护阈值(ProtectThreshold):为了防止因过多实例故障,导致所有流量全部流入剩余实例,继而造成流量压力将剩余实例被压垮形成的雪崩效应。应将健康保护阈值定义为⼀个 0 到 1之间的浮点数。当域名健康实例数占总服务实例数的比例小于该值时,无论实例是否健康,都会将这个实例返回给客户端。这样做虽然损失了⼀部分流量,但是保证了集群中剩余健康实例能正常工作。 
    • 实例选择器(Selector):用于在获取服务下的实例列表时,过滤和筛选实例。该选择器也被称为路由器,目前 Nacos 支持通过将实例的部分信息存储在外部元数据管理 CMDB 中,并在发现服务时使用 CMDB 中存储的元数据标签来进行筛选的能力。 
    • 拓展数据(extendData):用于用户在注册实例时自定义扩展的元数据内容,形式为 K-V 。可以在服务中拓展服务的元数据信息,方便用户实现自己的自定义逻辑。

     3)定义实例

            由于服务实例是具体提供服务的节点,因此 Nacos 在设计实例的定义时,主要需要存储该实例的⼀些网络相关的基础信息,主要包含以下内容:
    • 网络 IP 地址:该实例的 IP 地址,在 Nacos2.0 版本后支持设置为域名。 
    • 网络端口:该实例的端口信息。 
    • 健康状态(Healthy):用于表示该实例是否为健康状态,会在 Nacos 中通过健康检查的手段进行维护,具体内容将在 Nacos 健康检查机制章节中详细说明,读者目前只需要该内容的含义即可。 
    • 集群(Cluster):用于标示该实例归属于哪个逻辑集群,有关于集群的相关内容,将在后文详细说明。 
    • 拓展数据(extendData):用于用户自定义扩展的元数据内容,形式为 K-V。可以在实例中拓展该实例的元数据信息,方便用户实现自己的自定义逻辑和标示该实例。

    4)实例元数据

            和服务元数据不同,实例的元数据主要作用于实例运维相关的数据信息。主要包含:
    • 权重(Weight):实例级别的配置。权重为浮点数,范围为 0-10000。权重越大,分配给该实例的流量越大。 
    • 上线状态(Enabled):标记该实例是否接受流量,优先级大于权重和健康状态。用于运维人员在不变动实例本身的情况下,快速地手动将某个实例从服务中移除。
    • 拓展数据(extendData):不同于实例定义中的拓展数据,这个拓展数据是给予运维人员在不变动实例本身的情况下,快速地修改和新增实例的扩展数据,从而达到运维实例的作用。

            在 Nacos2.0 版本中,实例数据被拆分为实例定义和实例元数据,主要是因为这两类数据其实是同⼀个实例的两种不同场景:开发运行场景及运维场景。对于上下线及权重这种属性,⼀般认为在实例已经在运行时,需要运维人员手动修改和维护的数据,而 IP,端口和集群等信息,⼀般情况下在实例启动并注册后,则不会在进行变更。将这两部分数据合并后,就能够得到实例的完整信息,也是 Nacos1.0 版本中的实例数据结构。

            
            同时在 Nacos2.0 版本中,定义实例的这部分数据,会受到持久化属性的的影响,而实例元数据部分,则⼀定会进行持久化;这是因为运维操作需要保证操作的原子性,不能够因为外部环境的影响而导致操作被重置,例如在 Nacos1.0 版本中,运维人员因为实例所处的网络存在问题,操作⼀个实例下线以此摘除流量,但是同样因为网络问题,该实例与 Nacos 的通信也收到影响,导致实例注销后重新注册,这可能导致上线状态被重新注册而覆盖,失去了运维人员操作的优先级。
            
            当然,这部分元数据也不应该无限制的存储下去,如果实例确实已经移除,元数据也应该移除,为此,在 Nacos 2.0 版本后,通过该接口更新的元数据会在对应实例删除后,依旧存在⼀段时间,如果在此期间实例重新注册,该元数据依旧生效;您可以通过 nacos.naming.clean.expired-metadata.expired-time 及 nacos.naming.clean.expired-metadata.interval 对记忆时间进行修改。

    5)持久化属性

            如 Nacos 注册中心的设计原理文中所述,Nacos 提供两种类型的服务:持久化服务和非持久化服务,分别给类 DNS 的基础的服务组件场景和上层实际业务服务场景使用。为了标示该服务是哪种类型的服务,需要在创建服务时选择服务的持久化属性。考虑到目前大多数使用动态服务发现的场景为非持久化服务的类型(如 Spring Cloud,Dubbo,Service Mesh 等),Nacos 将缺醒值设置为了非持久化服务。

            在 Nacos2.0 版本后,持久化属性的定义被抽象到服务中,⼀个服务只能被定义成持久化服务或非持久化服务,⼀旦定义完成,在服务生命周期结束之前,无法更改其持久化属性。 持久化属性将会影响服务及实例的数据是否会被 Nacos 进行持久化存储,设置为持久化之后,实例将不会再被自动移除,需要使用者手动移除实例。

    2、集群(Cluster)

            集群是 Nacos 中⼀组服务实例的⼀个逻辑抽象的概念,它介于服务和实例之间,是⼀部分服务属性的下沉和实例属性的抽象。

    1、定义集群

            在 Nacos 中,集群中主要保存了有关健康检查的⼀些信息和数据:
    • 健康检查类型(HealthCheckType):使用哪种类型的健康检查方式,目前支持:TCP,HTTP,MySQL;设置为 NONE 可以关闭健康检查。 
    • 健康检查端口(HealthCheckPort):设置用于健康检查的端口。 是否使用实例端口进行健康检查(UseInstancePort):如果使用实例端口进行健康检查,将会使用实例定义中的网络端口进行健康检查,而不再使用上述设置的健康检查端口进行。 
    • 拓展数据(extendData):用于用户自定义扩展的元数据内容,形式为 K-V 。可以自定义扩展该集群的元数据信息,方便用户实现自己的自定义逻辑和标示该集群。

    3、生命周期

            在注册中心中,实例数据都和服务实例的状态绑定,因此服务实例的状态直接决定了注册中心中实例数据的生命周期。而服务作为实例的聚合抽象,生命周期也会由服务实例的状态来决定。

    1)服务的⽣命周期

            服务的生命周期相对比较简单,是从用户向注册中心发起服务注册的请求开始。在 Nacos 中,发起服务注册有两种方式,⼀种是直接创建服务,⼀种是注册实例时自动创建服务;前者可以让发起者在创建时期就制定⼀部分服务的元数据信息,而后者只会使用默认的元数据创建服务。
            在生命周期期间,用户可以向服务中新增,删除服务实例,同时也能够对服务的元数据进行修改。
            当用户主动发起删除服务的请求或⼀定时间内服务下没有实例(无论健康与否)后,服务才结束其生命周期,等待下⼀次的创建。

    2)实例的⽣命周期

            实例的生命周期开始于注册实例的请求。但是根据不同的持久化属性,实例后续的生命周期有⼀定的不同。
            持久化的实例,会通过健康检查的状态维护健康状态,但是不会自动的终止该实例的生命周期;在生命周期结束之前,持久化实例均可以被修改数据,甚至主动修改其健康状态。唯⼀终止持久化实例生命周期的方式就是注销实例的请求。
            而非持久化的实例,会根据版本的不同,采用不同的方式维持健康状态:如果是 Nacos1.0 的版本,会通过定时的心跳请求来进行续约,当超过⼀定时间内没有心跳进行续约时,该非持久化实例则终止生命周期;如果是 Nacos2.0 的版本,会通过 gRPC 的长连接来维持状态,当连接发生中断时,该非持久化实例则终止生命周期。当然,非持久化实例也可以通过注销实例的请求,主动终止其生命周期,但是由于长连接和心跳续约的存在,可能导致前⼀个实例数据的生命周期刚被终止移除,立刻又因为心跳和长连接的补偿请求,再次开启实例的生命周期,给人⼀种注销失败的假象。

    3)集群的⽣命周期

            集群的生命周期则相对复杂,由于集群作为服务和实例的⼀个中间层,因此集群的生命周期与实例和服务的生命周期均有关。
            集群的生命周期开始与该集群第⼀个实例的生命周期同时开始,因为⼀个实例必定归属于⼀个集群,哪怕是默认的集群,因此当第⼀个实例的生命周期开始时,也就是集群生命周期的开始;
            当⼀个集群下不存在实例时,集群的生命周期也不会立刻结束,而是会等到这个服务的生命周期结束时,才会⼀起结束生命周期。

    4)元数据的⽣命周期

            由于元数据的其对应的数据模型是紧密关联的,所以元数据的生命周期基本和对应的数据模型保持 ⼀致。但是也如前文所说,元数据通常为运维人员的主动操作的数据,会被 Nacos 进行⼀段时间内的记忆,因此元数据的生命周期的终止相比对应的数据要滞后;若这滞后期间内,对应的数据又重新开始生命周期,则该元数据的生命周期将被立刻重置,不再终止。

     

     

    展开全文
  • nacos注册中心

    2019-09-06 15:01:23
    nacos服务中心搭建与服务注册 一:下载地址 https://github.com/alibaba/nacos/releases 源码地址:https://github.com/alibaba/nacos 官网地址:https://nacos.io/zh-cn/docs/what-is-nacos.html 1.nacos专注于...

    nacos注册中心

    一:下载地址

    https://github.com/alibaba/nacos/releases 源码地址:https://github.com/alibaba/nacos 官网地址:https://nacos.io/zh-cn/docs/what-is-nacos.html

    1.nacos专注于服务发现和配置管理领域
    2.解决硬编码,配置文件
    3.真正将配置从应用中剥离出来,统一管理,优雅的解决了配置的动态变更、持久化、运维成本等问题

    在这里插入图片描述

    二、 解压后目录结构

    在这里插入图片描述

    三、 进入conf目录下

    在这里插入图片描述

    四、修改 application.properties 配置文件,添加如下内容,保存

    spring.datasource.platform=mysql
    db.num=1
    db.url.0=jdbc:mysql://localhost:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
    db.user=root
    db.password=root
    

    五:执行config目录下nocos-mysql的sql

    在这里插入图片描述

    六,进入bin目录,Windows部署点击bin目录下的startup.cmd,也可以通过命令进行单机版部署

    Windows:cmd startup.cmd -m standalone

    运行成功,访问 http://127.0.0.1:8848/nacos/index.html 首次登陆默认用户名和密码都是nacos(密码可以自己修改,使用的是import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder; new BCryptPasswordEncoder().encode(“nacos”))

    在这里插入图片描述

    搭建客户端

    一:导入依赖

    <!-- 1. nacos-配置管理功能依赖  实现配置的动态变更-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        <version>0.2.1.RELEASE</version>
    </dependency>
    
    <!-- 2. nacos-服务发现功能依赖 实现服务的注册与发现-->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        <version>0.2.1.RELEASE</version>
    </dependency>
    注意:版本 0.2.x.RELEASE 对应的是 Spring Boot 2.x 版本,版本 0.1.x.RELEASE 对应的是 Spring Boot 1.x 版本。
    

    二:修改配置文件(application.yml)

    spring:
      application:
        name: user
      #之所以需要配置 spring.application.name ,是因为它是构成 Nacos 配置管理 dataId字段的一部分,在 Nacos Spring Cloud 中,dataId 的完整格式:
          #${prefix}-${spring.profile.active}.${file-extension}
          #prefix 默认为 spring.application.name 的值,也可以通过配置项 spring.cloud.nacos.config.prefix来配置。
          #spring.profile.active 即为当前环境对应的 profile,当 spring.profile.active 为空时,对应的连接符 - 也将不存在,dataId 的拼接格式变成 ${prefix}.${file-extension}
          #file-exetension 为配置内容的数据格式,可以通过配置项 spring.cloud.nacos.config.file-extension 来配置。目前只支持 properties 和 yaml 类型
      cloud:
        nacos:
          discovery:
            server-addr: 127.0.0.1:8848
          config:
            server-addr: 127.0.0.1:8848
            file-extension: yaml #配置文件的格式,默认为properties
    server:
      port: 8080
    
    

    三:启动

    1.启动类添加@EnableDiscoveryClient 开启服务注册发现功能
    2.启动报如下图错误

    在这里插入图片描述

    解决:作为配置中心时,必须要使用bootstrap.yml,因为bootstrap.yml加载顺序优先于application.yml

    3.重新启动后:

    在这里插入图片描述

    四:实时刷新配置

    1.新建配置

    注意data id的命名
    在这里插入图片描述

    2.创建controller
    nacos注册中心粘贴示例

    在这里插入图片描述

    示例代码如下

    在这里插入图片描述

    3.访问:http://localhost:8080/config/get

    五:启动服务发现

    1.创建服务提供者(将上个客户端作为提供者)

    在这里插入图片描述

    2,创建服务消费者,配置同上,修改spring: application: name: product,修改端口

    在这里插入图片描述

    3.启动两个客户端,访问http://localhost:8081/echo/caikeke
    4.以上代码也可在nacos中粘贴示例代码

    在这里插入图片描述

    命名空间和群组

    1.新建配置群组为USER_GROUP,data id为user.yaml(同一群组下Data Id不能重复)

    在这里插入图片描述
    default_group下user.yaml内容

    useLocalCache: true
    userName: defalut_group
    

    user_group下user.yaml内容

    useLocalCache: true
    userName: user_group
    

    2.读取USER_GROUP群组下的配置—客户端bootstrap.yml配置添加

    spring:cloud:nacos:config:group:USER_GROUP    #读取USER_GROUP分组下user.yaml
    

    3.测试controller,访问http://localhost:8081/config/getUserName

    @RequestMapping("/config")
    @RestController
    @RefreshScope
    public class UserController {
    
        @Value("${useLocalCache:false}")
        private boolean useLocalCache;
    
        @Value("${userName:zhangsan}")
        private String userName;
    
        @RequestMapping("/get")
        public boolean get() {
            return useLocalCache;
        }
    
        @RequestMapping("/getUserName")
        public String getUserName() {
            return userName;
        }
    }
    

    4.新建命名空间 (常用场景之一是不同环境的配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等)

    在这里插入图片描述

    5. 在test空间下创建群组为USER_GROUP,data id 为user.yaml的配置

    在这里插入图片描述
    user.yaml内容为

    useLocalCache: true
    userName: test环境下user_group
    

    6.读取test空间下USER_GROUP群组下的配置—客户端bootstrap.yml配置添加

    spring:cloud:nacos:config:namespace:24a52d94-1b43-4568-b23b-1f2e6207a621  #读取命名空间
    

    7.测试controller,访问http://localhost:8081/config/getUserName

    注册中心的心跳

    临时实例和持久化实例

    1.心跳周期(查看下图user服务)

    在定义上区分临时实例和持久化实例的关键是健康检查的方式。临时实例使用客户端上报模式,而持久化实例使用服务端反向探测模式。临时实例需要能够自动摘除不健康实例,而且无需持久化存储实例。

    目前支持临时实例使用心跳上报方式维持活性,发送心跳的周期默认是 5 秒,Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康,在 30 秒没收到心跳时将这个临时实例摘除。

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    2.服务自定义心跳周期
    通过设置实例的metadata,来指定心跳周期、健康检查过期时间及删除实例时间
    String serviceName = randomDomainName();
    
    Instance instance = new Instance();
    instance.setIp("1.1.1.1");
    instance.setPort(9999);
    Map<String, String> metadata = new HashMap<String, String>();
    // 设置心跳的周期,单位为秒,这里将心跳间隔设置为3秒:
    metadata.put(PreservedMetadataKeys.HEART_BEAT_INTERVAL, "3");
    // 设置心跳超时时间,单位为秒,这里将心跳超时时间设为6秒,
    // 即服务端6秒收不到客户端心跳,会将该客户端注册的实例设为不健康:
    metadata.put(PreservedMetadataKeys.HEART_BEAT_TIMEOUT, "6");
    // 设置实例删除的超时时间,单位为秒,这里将实例删除超时时间设为9秒,
    // 即服务端9秒收不到客户端心跳,会将该客户端注册的实例删除:
    metadata.put(PreservedMetadataKeys.IP_DELETE_TIMEOUT, "9");
    instance.setMetadata(metadata);
    
    naming.registerInstance(serviceName, instance);
    

    nacos集群搭建

    一.将nocos压缩包解压三个,修改端口

    二:修改其中一个配置文件
    1.进入conf目录下,在application.properties添加数据库配置
    2.进入conf目录下,默认只有一个cluster.conf.example文件,复制一份,修改名称为cluster.conf
    输入
    127.0.0.1:8848
    127.0.0.1:8849
    127.0.0.1:8850
    3.其他两个配置文件同上
    
    三:客户端修改配置
    cloud:
        nacos:
          discovery:
            server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
          config:
            server-addr: 127.0.0.1:8848,127.0.0.1:8849,127.0.0.1:8850
            file-extension: yaml #配置文件的格式,默认为properties
            group: PRODUCT_GROUP
            namespace: 24a52d94-1b43-4568-b23b-1f2e6207a621
    
    四:启动客户端

    服务端信息1.1.0后特性

    一:配置导入导出及配置同步

    导入导出文件格式说明。均为zip压缩包,压缩包内有多个目录,目录名为配置的 group,目录下有具体的文件,文件名为配置的 dataId 
    

    二:服务订阅者列表

    查看一个服务的消费者
    
    三:其他以官方文档为主
    展开全文
  • Nacos注册中心的使用

    2021-01-20 02:10:41
    1.什么是nacos (1)Nacos 是阿里巴巴推出来的一个新开源项目,这是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理...常见的注册中心: (1) Eureka(原生,2.0遇到性能瓶颈,停止维护) (2) Zookeeper
  • nacos可以做为注册中心也可以作为配置中心,可以统一通过nacos管理并且nacos核心功能直接实现吧~ 这个上面可以非常清楚的看到,demo的服务已经可以正常注册到nacos了 可以看到完美跑通了哈.........
  • Nacos注册中心和配置中心

    千次阅读 2021-04-20 18:14:25
    一:Nacos注册中心原理 服务提供者、服务消费者、服务发现组件这三个角色之间的关系大致如下 1、微服务在启动时,将自己的网络地址等信息注册到服务发现组件(nacos server)中,服务发现组件会存储这些信息。 2...
  • 该工程用于测试Dubbo微服务使用Nacos作为注册中心进行RPC调用时发生500异常,异常如下: ...
  • Nacos注册中心和配置中心的作用 Nacos注册中心: 管理所有微服务、解决微服务之间调用关系错综复杂、难以维护的问题。 Nacos配置中心: Nacos也整合了配置中心的作用,我们可以用来管理繁杂的配置文件。 Nacos...
  • nacos注册中心集群

    多人点赞 热门讨论 2022-06-25 18:19:53
    本篇主要讲解nacos注册中心的集群,欢迎各位大佬前来围观
  • Nacos 注册中心的设计原理详解

    千次阅读 2021-03-23 17:06:55
    本文从各个角度深度介绍 Nacos 注册中心的设计原理,并试图从我们的经验和调研中总结和阐述服务注册中心产品设计上应该去遵循和考虑的要点。由于作者水平有限,文中的错误还希望大家多多指正。 数据模型 注册中心的...
  • 【SpringCloudAlibaba】微服务组件Nacos注册中心

    多人点赞 热门讨论 2022-03-06 21:30:21
    微服务架构是一种去中心化架构,比如我们的注册中心挂了,服务还是能调到其他服务的资源(有缓存),但现在的网关层也有着中心化的趋势。 微服务架构和集中式架构的区别? 我们常看到的SOA,就是一种集中式架构,...
  • 1.启动Nacos注册中心 Linux或是Mac系统下启动Nacos:sh startup.sh -m standalone Windows系统下启动Nacos:startup.cmd -m standalone 默认访问端口为:http://localhost:8848/nacos/ 当然自己也可以进行...
  • 1.新建Springboot项目,添加Nacos依赖 <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> <version...
  • Nacos注册中心 SpringCloudAlibaba 推出了一个名为 Nacos 的注册中心,在国外也有大量的使用。 首先进行nacos的安装,安装教程见: 配置好nacos可以配置环境变量,方便启动,将nacos的bin路径加入到系统变量的...
  • 在没有nacos的时候,我们可能选择的组件eureka作为服务注册中心,总体使用感觉一般般。其次就是如果要对服务进行配置的话,还得引入config,这只是对单机下服务进行配置与刷新,如果要对集群服务进行配置刷新的话,...
  • springCloud之Nacos注册中心

    千次阅读 2022-03-21 16:42:05
    nacos安装与使用
  • SpringBoot整合Nacos注册中心

    千次阅读 2020-11-24 22:11:10
    SpringBoot项目如何整合Nacos注册中心框架 Nacos作为阿里开源的注册中心和配置中心框架,以其活跃的社区和超高的性能吸引了很多开发者和公司的青睐,笔者目前了解到的注册中心框架有Eureka、Consul、Nacos和ZK,这几...
  • 关于nacos注册中心的简单配置

    千次阅读 2021-12-18 08:31:15
    配置服务分级存储模型环境隔离1、在Nacos控制台可以创建namespace,用来隔离不同环境2、填写命名空间信息3、保存过后会看见一个id4、修改order-service的applicationyml,添加namespace:概述Nacos统一配置管理引入...
  • nacos注册中心的注册原理深度解析

    千次阅读 2021-09-09 14:50:25
    整个注册中心的注册和发现流程主要有三个方面来完成:服务的提供方(以下简称server)、服务的消费者(以下简称client)、注册中心nacos)。首先我们来探讨server与nacos的交互过程。 server需要通过nacos官方的...
  • 02-Nacos注册中心工作流程

    千次阅读 2021-11-27 19:52:16
    Nacos注册中心工作流程
  • 动态配置中心可以实现配置更新时无需重新部署应用程序和服务即可使相应的配置信息生效,这极大了增加了系统的运维能力。下面我将来和大家一起来了解下Nacos的动态配置的能力,看看Nacos是如何以简单、优雅、高效的...
  • 1.Nacos 服务(Server) 从 Nacos 官网 下载 nacos-server-$version.zip 包,解压到指定目录。 Windows 中,打开解压目录下的 \bin\startup.cmd 启动服务。 Nacos 服务占用内存近 2G,对资源要求很高。 启动成功后,...
  • Dubbo使用Nacos注册中心

    2021-07-04 21:03:56
    目录前言一、基本使用服务端依赖配置文件实现类客户端...这里nacos的安装就不写了 服务端 依赖 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifact
  • 主要介绍了spring cloud alibaba Nacos 注册中心搭建过程详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
  • 一、ZooKeeper注册中心 Zookeeper 是 Apache Hadoop 的子项目,是一个树型的目录服务,支持变更推送,适合作为 Dubbo 服务的注册中心,工业强度较高,可用于生产环境,推荐使用。 流程说明: 服务提供者启动时: 向...
  • 配置中心和服务注册 第一步:增加依赖 com.croot croot_cloud_nacos_starter 第二步:新建文件 bootstrap.properties(与原配置文件同目录即可) ##项目名称 spring.application.name=rims_server spring.cloud....

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 43,762
精华内容 17,504
关键字:

NACOS注册中心