微服务相关之Nacos
- 一、基础概念
-
- [1.什么是 Nacos](#1.什么是 Nacos)
- [2.Nacos 的关键特性包括](#2.Nacos 的关键特性包括)
- [3.Nacos 核心组件](#3.Nacos 核心组件)
- [4.Nacos 业务大图](#4.Nacos 业务大图)
- 二、架构设计
- 三、Nacos注册中心
一、基础概念
1.什么是 Nacos
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称,一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以"服务"为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
服务(Service)是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的"服务"的发现、配置和管理:Kubernetes Service、gRPC & Dubbo RPC Service
Spring Cloud RESTful Service
2.Nacos 的关键特性包括
(1)服务发现和服务健康监测
Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后,服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
Nacos 提供对服务的实时的健康检查,阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义)的健康检查。 对于复杂的云环境和网络拓扑环境中(如 VPC、边缘网络等)服务的健康检查,Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘,帮助您根据健康状态管理服务的可用性及流量。
(2)动态配置服务
① 动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
② 动态配置消除了配置变更时重新部署应用和服务的需要,让配置管理变得更加高效和敏捷。
③ 配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。
- Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性,帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
(3)动态 DNS 服务
动态 DNS 服务支持权重路由,让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现,以帮助您消除耦合到厂商私有服务发现 API 上的风险。
- Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.
(4)服务及其元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据,包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
3.Nacos 核心组件
(1)命名空间
用于进行租户粒度的配置隔离。不同的命名空间下,可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离,例如开发测试环境和生产环境的资源(如配置、服务)隔离等。
(2)配置分组
Nacos 中的一组配置集,是组织配置的维度之一。通过一个有意义的字符串(如 Buy 或 Trade )对配置集进行分组,从而区分 Data ID 相同的配置集。
当您在 Nacos 上创建一个配置时,如果未填写配置分组的名称,则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景:不同的应用或组件使用了相同的配置类型,如 database_url 配置和 MQ_topic 配置。
(3)配置快照
Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时,可以使用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit,也类似于缓存,会在适当的时机更新,但是并没有缓存过期(expiration)的概念。
(4)服务
通过预定义接口网络访问的提供给客户端的软件功能。
(5)服务名
服务提供的标识,通过该标识可以唯一确定其指代的服务。
(6)服务注册中心--磁盘文件
存储服务实例和服务负载均衡策略的数据库。
(7)服务发现
在计算机网络上,(通常使用服务名)对服务下的实例的地址和元数据进行探测,并以预先定义的接口提供给客户端进行查询。
(8)元信息
Nacos数据(如配置和服务)描述信息,如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label),从作用范围来看,分为服务级别的元信息、集群的元信息及实例的元信息。
4.Nacos 业务大图
特性大图:要从功能特性,非功能特性,全面介绍我们要解的问题域的特性诉求
架构大图:通过清晰架构,让您快速进入 Nacos 世界
业务大图:利用当前特性可以支持的业务场景,及其最佳实践
生态大图:系统梳理 Nacos 和主流技术生态的关系
优势大图:展示 Nacos 核心竞争力
战略大图:要从战略到战术层面讲 Nacos 的宏观优势
二、架构设计
1.基本架构及概念
(1)服务 (Service)
服务是指一个或一组软件功能(例如特定信息的检索或一组操作的执行),其目的是不同的客户端可以为不同的目的重用(例如通过跨进程的网络调用)。Nacos 支持主流的服务生态,如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service。
(2)服务注册中心 (Service Registry)
服务注册中心,它是服务,其实例及元数据的数据库。服务实例在启动时注册到服务注册表,并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。
(3)服务元数据 (Service Metadata)
服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。
(4)服务提供方 (Service Provider)
是指提供可复用和可调用服务的应用方。
(5)服务消费方 (Service Consumer)
是指会发起对某个服务调用的应用方。
(6)配置 (Configuration)
在系统开发过程中通常会将一些需要变更的参数、变量等从代码中分离出来独立管理,以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物(如 WAR,JAR 包等)更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中,由系统管理员或者运维人员完成这个步骤。配置变更是调整系统运行时的行为的有效手段之一。
(7)配置管理 (Configuration Management)
在数据中心中,系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。
(8)名字服务 (Naming Service)
提供分布式系统中所有对象(Object)、实体(Entity)的"名字"到关联的元数据之间的映射管理服务,例如 ServiceName -> Endpoints Info, Distributed Lock Name -> Lock Owner/Status Info, DNS Domain Name -> IP List, 服务发现和 DNS 就是名字服务的2大场景。
(9)配置服务 (Configuration Service)
在服务或者应用运行过程中,提供动态配置或者元数据以及配置管理的服务提供者。
三、Nacos注册中心
1.注册中心演变及其设计思想
2.Nacos注册中心架构
服务注册和发现机制
服务注册和发现包含心跳检测机制
服务注册:
Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务,提供自身的元数据,比如ip地址、端口等信息。
Nacos Server接收到注册请求后,就会把这些元数据信息存储在一个双层的内存Map中,即Map<namespace, Map<group::serviceName, Service>>
服务发现:
服务消费者(Nacos Client)在调用服务提供者的服务时,会发送一个REST请求给Nacos Server,获取上面注册的服务清单,并且缓存在Nacos Client本地,同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存
Nacos Client服务心跳:
在服务注册后,Nacos Client会维护一个定时心跳来持续通知Nacos Server,说明服务一直处于可用状态,防止被剔除。默认5s发送一次心跳。
Nacos Server服务健康检查:
Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况,对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现),如果某个实例超过30秒没有收到心跳,直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)
服务同步:
Nacos Server集群之间会互相同步服务实例,用来保证服务信息的一致性。 leader raft
3.服务注册表结构
nacos源码中的注册表结构
注册示例:POST /nacos/v1/ns/instance
注册代码:nacos-naming中InstanceController中register方法
调用ServiceManager.registerInstance(namespaceId,serviceName,instance)。
在ServiceManager中维护了Map<String,Map<String,Service>> serviceMap = new ConcurrentHashMap<>();
第一个key是namespaceId,第二个key是group拼接服务名(group::serviceName)
在Service中维护了Map<String,Cluster>,key就是集群名称
在Cluster中维护了Set,具体是实例
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/sinat_34814635/article/details/127951267
服务领域模型
注册中心对比
与eureka对比
1 eureka 2.0闭源码了。
2 从官网来看nacos 的注册的实例数是大于eureka的,
3 因为nacos使用的raft协议,nacos集群的一致性要远大于eureka集群.
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
原文链接:https://blog.csdn.net/sinat_34814635/article/details/127951267