用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。
Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。
配置集：一组相关或者不相关的配置项的集合称为配置集。在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。
三者关系
这三者的关系类似于Java里面的package名和类名，最外层的Namespace是可以用于区分部署环境的，Group和DataID逻辑上区分两个目标对象。
长轮询是Nacos动态配置更新的基石。与短轮询的频繁请求不同，长轮询通过建立持久的HTTP连接，减少了无效的网络交互。
建立长连接：当Nacos客户端需要监听配置变化时，它会向服务端发起一个长轮询请求，从而建立一个持久的连接。
服务端挂起请求：若无配置更新，服务端会将此请求挂起，不立即响应。
配置变更通知：一旦有配置变更，服务端会立刻唤醒挂起的请求，并将最新的配置发送给客户端。
在Nacos中，服务的注册与配置的监听是相辅相成的。
服务注册：服务启动时会向Nacos服务端注册，这样服务端就能追踪到哪些服务在监听哪些配置。
监听器注册：同时，服务会为其关心的配置注册一个监听器，确保当配置发生变化时能够得到通知。
配置变更：当配置发生变更，无论是通过Nacos的管理界面还是API，服务端都会记录下这个变化。
查找并通知监听器：服务端会查找所有注册了对应配置监听器的客户端，并通过之前建立的长连接发送更新通知。
客户端拉取并应用新配置：客户端在收到通知后，会从服务端拉取最新的配置，并应用到服务中。
为了提高响应速度和减少网络请求，Nacos客户端采用了本地缓存策略。
本地缓存：客户端会在本地维护一份配置的缓存，优先从缓存中读取配置。
缓存更新与一致性：当收到配置更新通知时，客户端不仅会更新其本地缓存，还会进行必要的同步和验证，以确保缓存的一致性。
Nacos配置中心作为一款强大的开源工具，支持以下核心功能：
集中管理配置：允许开发者在Nacos Server集中管理所有环境的应用配置，实现配置的统一托管与维护。
动态配置更新：支持配置的实时更新和推送，当配置发生变化时，Nacos能够自动推送给相关应用实例，实现配置的即时生效，无需重启应用。
版本控制与回滚：为配置变更提供版本记录，支持配置的历史版本查询和一键回滚，确保配置变更的安全可控。
配置监听与自动刷新：应用可以通过注解(@NacosValue)或API监听配置变化，实现配置自动刷新，如示例代码中展示的那样。
服务注册：服务实例可以自动向Nacos Server注册其元数据（如IP、端口等），便于其他服务发现和调用。
健康检查：自动监测注册服务的健康状态，确保服务列表的准确性和可用性。
服务路由与负载均衡：支持基于软负载均衡策略（如轮询、随机等）的服务调用，提升系统的稳定性和扩展性。
服务分组与命名空间：通过分组和服务命名空间来组织服务，实现多环境和服务隔离。
高可用部署：Nacos自身支持集群部署，保证配置与服务发现的高可用性。
数据一致性：利用Raft协议保障分布式环境下的数据一致性。
认证与授权：支持用户身份认证及细粒度的资源访问控制，保障配置数据的安全。
多节点都署:
在生产环境中，Nacos 应该部署为一个节点集群。在集群慎式下，Nacos 节点之间会相豆协调，确保服务和配置效据的一致性。
选举机制:
Nacos 使用内建的选革机制以决定哪一个节点作为领导者(leader)，领导者负责处理写请浓，其它节点(f0lower)则处理读请求。当领导者节点出现敬障时，则余的节点会进行新一轮的选举产生新的领导者。
数据同步:
在集群模式下，当一条数据被修改，这个变更会同步到所有节点，确保每个节点都拥有最新的状志。
持久化存储:
Nacos 支持将服务和配置数据相持久化到外部存储中，如MYSOL数据库。这保证了即使所有 Nacos 节点同时宕机，数据也不会丢失，可以在节点重启后恢复状态。
支持不同的数据库:
通过外部存储的支持，Nacos 可以和多种数据库集成，比如MYSOL，提供持久化能力，进一步增强了效据的安全性。
客户端负载均衡:
Nacos客户端实现了负载均衡，可以在多个Nacos 服务器实例之同分配请求，即使其中一些实例不可用，客户端也能自动切换到其他可用的实例。
服务端负载均衡:
通过使用负载均衡器(如NginX、HAPTOXy 等)，可以将请求均匀分配到Nacos 集群的各个节点上
备份与恢复:
定期备份 Nacos数据，确保在极情况下能够快速恢复服务。
跨区域部署:
在不同的数据中心或地区部署 Nacos 节点，可以提供地理级别的灾难恢复能力。
健康检查:
定期的节点健康检查可以确保及时发现并处理不可用的节点
监控系统集成:
Nacos 可以集成到现有的监控系统(如 Prometheus、Grafana等)，以便对集群的运行状志进行实时监控。
告警系统:
在检测到异常行为时，告警系统可以通知运维团队，从而迅速采取应对措施。
通过这些机制，Nacos 能够确保即使在出现硬件故障、网络问题或其他不可预见的情况下，也能提供连续的服务和配置管理能力，满足企业級应用的高可用性要求。
配置持久化主要有以下原国:
数据安全性:持久化配置可以保证在系统或者应用重启后，重要的配置数据不会丢央，可以确保数据的安全性和稳定性。数据可恢复性:持久化配置可以在数据委失或者损坏时进行恢复，保证系统的正常运行。
支持分布式系统:对于分布式系统来说，配置的持久化可以确保各个节点的一歌性，避免因为节点的估时变动导歌的问题。
可扩展性:持久化配置易于进行扩展和修政，可以通应不同的应用场景和业务舞求。
提高系统性能:通过实现配置的持久化，可以有效减少读取配置文件的次数，提高系统的运行效本。
降低模合性:持久化配置可以使得应用和配置之间松散横合，方便系统的维护和升，
Nacos支持两种不同的配置持久化方式:
内嵌的持久化:默认情况下，Nacos使用内家的Derby数据岸进行配置信息的持久化。这种方式道合于开发和测试环境，因为它简单且无腐额外的配置。但是，由于Derby数据率本身是一个经量众的嵌入式关系数据库，它并不适用于生产环境的高可用性要求。
外部存储抽久化:在生产环境中，推荐使用外部数播库(如MVSQL)来存储Nac0s的配置数播，这是因为外部数据库通常提供了更高饭的持久化钟性，包括效据复制、故障转移、读写分商、备份与恢复等，这对于保证效据的安全性和服务的可用性至关重要。
Nacos还支持将配置信息保存到Git仓库中，提供了更多的灵活性和可选项来满足不同的需求。
具体操作步骤：
创建数据库：首先，需要创建一个MySQL数据库，例如命名为nacos_config，并创建必要的表结构。这些表结构包括但不限于config_info_aggr和config_info_beta，用于存储配置信息。表结构应包括id、data_id、group_id、datum_id、content、gmt_modified和app_name等字段，以确保能够存储和检索配置数据
修改Nacos配置：接下来，需要修改Nacos的配置文件，特别是application.properties，以便指向新创建的MySQL数据库。这包括设置数据库连接信息，如数据库地址、端口、数据库名称、用户名和密码等
启动Nacos集群：确保Nacos集群正确配置后，可以启动Nacos服务。在集群模式下，通常需要3个或更多的Nacos节点以确保高可用性。此外，还可以通过Nginx进行反向代理，以提供负载均衡和高可用性访问
测试持久化配置：完成上述步骤后，可以通过向Nacos中添加、修改或删除配置来测试持久化是否成功。确保配置数据能够正确地存储在MySQL数据库中，并且能够在Nacos服务重启后依然可用。
分布式系统设计需要考虑的三个核心要素:
一致性(Consistency):同一时刻的同一请求的实例返回的结果相同，所有的数据要求具有强一致性(StrongConsistency)（在任何时刻去读取数据，获取到的数据都是一致的）
可用性(Availability):所有实例的读写请求在一定时间内可以得到正确的响应（在某一段时间内有可能数据时不一致的，但是最终会保证数据的一致）
分区容错性(Partition tolerance):在网络异常(光缆断裂、设备故障、宕机)的情况下，系统仍能提供正常的服务
以上三个特点就是CAP原则(又称CAP定理)，但是三个特性不可能同时满足，所以分布式系统设计要考虑的是在满足P(分区容错性)的前提下选择C(一致性)还是A(可用性)，即:CP或AP
CP原则:一致性+分区容错性原则
CP原则属于强一致性原则，要求所有节点可以查询的数据随时都要保持一致(同步中的数据不可查询)，即:若干个节点形成一个逻辑的共享区域，某一个节点更新的数据都会立即同步到其他数据节点之中，当数据同步完成后才能返回成功的结果，但是在实际的运行行过程中网络故障在所难免，如果此时若于个服务节点之间无法通讯时就会出现错误，从而牺牲了可用性原则(A)，例如关系型数据库中的事务。
AP原则:可用性原则+分区容错性原则
AP原则属于弱一致性原则，在集群中只要有存活的节点那么所发送来的所有请求都可以得到正确的响应，在进行数据同步处理操作中即便某些节点没有成功的实现数据同步也返回成功，这样批括牲一致性原则(C原则)。
使用场景:对于数据的同步一定会发出指令，但是最终的节点是否真的实现了同步，并不保证，可是却可以及时的得到数据更新成功的响应，可以应用在网络环境不是很好的场景中。
Nacos中服务注册中心默认是AP模式，如果设置为CP模式那么客户设置spring.cloud.nacos.discovery.ephemeral=false(默认为tue)，表示是启用AP模式
一般来说，如果不需要储存服务界别的信息且服务实例通过nac0s-client注册，并能够保持心跳上报，那么就可以选择AP模式。如SpringCloud和 Dubbo，都适用于AP模式，AP模式为了服务的可用性减弱了一致性，因此AP模式下只支持注册临时实例。在Nac0s服务注册，即naming服务中，对于AP模式，是采用gRPC通信的，协议则是自己实现了一个名为Distro协议，我们看下客户是怎么进行服务注册的，客户烟进行服务注册主要是通过Niacosxamingservice来实现的,这里最终会通过clienteroxy去进行服务注册,实现为iamingclientrroxypelegate
如果要在服务級别编播或者储存配置信息那么CP是必须的，K8S服务和DNS服务则是用于CP模式。CP模式下则支持注册持久化实例，此时则是以Ratt协议为集群运行煤式，该模式下注册实例之前必须先注册服务，如果限务不在，则会返回退，
对于CP模式来说，Nac0s2使用了Ra协议，在Nac0s2中则是使用阿里开源的SOFA-jat来实现Ra协议，想了解的可以看这篇 Rat算法实现Sofa-JRaft，选主，欢据写入，目志复制
客户端则是通过NamingHttpClientPr0xy模式发送相关清求，在服务增别是Instancecontroller进行处理,最终在PersistentServiceProcessor.put中进行持久化.
AT是最常用的模式，它利用效据库的本地事务来实现全局事务的一致性。
在这种模式下，Seata会自助提交和回滚分支事务，无开发人员编写额外的业务代码。适用于各种简单的业务场景;
TCC则通过 Try阶段尝试执行业务操作、Confirm 阶段确认执行操作以及 Cancel 阶段取消执行操作来实现分布式事务的一致性。这种模式需要开发人员编写业务代码来实现事务的Try、Confirm和Cancel操作，以处理分支事务的预提交、提交和回滚。适用于对数据一致性要求较高的场景;
优点:
TCC完全不依赖底层数据库，能够实现跨数据库、跨应用资源管理，可以提供给业务方更细粒度的控制。
缺点:
TCC是一种侵入式的分布式事务解决方案，需要业务系统自行实现Try，Confirm，Cancel 三个操作，对业务系统有着非常大的入侵性，设计相对复杂。
通过一系列的局部事务来实现全局事务，通用于长时间运行的业务流程
这种模式通用于长事务和业务流程中的分布式事务。开发人员可以定义事务的各个阶段，并在每个阶段执行特定的操作，以实现事务的最终一致性。
适用场景:
业务流程长、业务流程多
参与者包含共它公司或遭留系统服务，无法提供IOC模式要求的三个换口
优势:
阶段提交本地事务，无锁，高性能
事件驱动架构，参与者可异步执行，变吞吐
补偿服务易于实现
缺点:
*不保证隔离性
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-api/52915.html