Nacos

Nacos在分布式系统中承载着重要的角色，提供服务注册、服务发现、配置管理、命名空间和认证等功能。这些功能也是开发中常用到的。

使用命名空间和GROUP对配置文件、服务进行管理，可以实现多租户，复杂环境，小组件的隔离。

另外支持配置热更新，在页面上修改配置，程序可以自动更新（程序需要加@RefreshScope注解）。 Nacos实现流程为：在页面修改后，服务中心会给所有使用到该配置中心的客户端发送一个更新通知，客户端接收到后，重新加载配置，完成配置更新。

Nacos自身还包含集群管理（内部选举Raft算法），心跳机制（检查服务是否正常），注册，发现等。

部署方式：常采用docker部署。

CAP理论：

• 一致性（Consistency）： 所有节点在同一时间看到相同的数据。 每个请求无论路由到哪个节点，都会返回最新的数据版本。 更新操作之后的所有读取操作都会返回更新后的值。
• 可用性（Availability）： 每个请求在合理的时间内都能收到一个响应，尽管这个响应可能是旧值。 即使一部分节点失败，系统仍然能够继续处理请求。
• 分区容错性（Partition tolerance）： 系统能够在节点间网络分区的情况下继续正常运行。 即使网络分区发生，系统仍能正确地处理请求。

根据CAP理论，一个分布式系统只能同时满足这三个特性中的两个。例如：

CA系统：在没有网络分区的情况下，保证一致性和可用性。 CP系统：在网络分区情况下，保证一致性和分区容错性，可能牺牲部分可用性。 AP系统：在网络分区情况下，保证可用性和分区容错性，可能牺牲一致性。

CAP理论表明，在分布式系统中，由于网络分区和节点故障的存在，系统无法同时保证一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个特性。具体来说，这是因为： 分区容错性（Partition tolerance, P） 是一个现实世界中必须面对的问题，特别是在分布式系统中。当网络分区发生时，节点间的通信可能会中断，这意味着一部分节点可能无法与另一部分节点通信。在这种情况下，系统必须决定如何继续运行。 一致性（Consistency, C） 要求所有节点在同一时间看到相同的数据。如果系统追求强一致性，那么在网络分区发生时，为了确保所有节点的数据一致，可能需要拒绝一部分操作或请求，直到网络恢复正常。这样就可能会影响到系统的可用性。 可用性（Availability, A） 要求系统在任何情况下都能接受并处理客户端的请求。如果系统追求高可用性，那么在网络分区发生时，系统可能会允许某些节点继续处理请求，即使这些请求可能会导致数据的一致性问题。 因此，当网络分区发生时（这是不可避免的），系统必须在一致性和可用性之间做出选择。如果选择了一致性，那么为了等待所有节点达成一致，可能会拒绝某些请求，从而影响可用性；如果选择了可用性，那么为了继续处理请求，可能会暂时牺牲一致性。