开发笔记:基于Nacos集群部署

创建nacos-cluster文件夹

再创建以下子文件夹

---nacos-server-8848

---nacos-server-8849

---nacos-server-8850

修改/nacos/conf文件夹下的cluster.conf文件

###ip和端口号

192.168.X.XX:8848

192.168.X.XX:8849

192.168.X.XX:8850

修改bootstrap.yaml

至此，nacos集群就配置完毕！

CAP定律指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

在分布式系统中，如果服务器集群，每个节点在同时刻访问必须保持数据的一致性。

集群节点中，部分节点出现故障后任然可以使用（高可用）。

在分布式系统中网络会存在脑裂的问题，部门Server与整个集群失去节点联系，无法组成一个群体。

CP情况下，虽然服务不可用，但是必须要保证数据的一致性。

AP情况下，可以短暂保证数据不一致性，但是最终可以一致性，不管怎样，都要保证服务可用。

大多注册中心都是AP。

都是可以实现分布式服务注册中心。

Zookeeper采用CP保证数据的一致性问题，原理采用Zab原子广播协议，当由于zk领导因为某种原因宕机的情况下，会自动出发重新选一个新的领导角色，整个选举的过程为了保证数据的一致性问题，在选举的过程中整合zk环境是不可以使用，可能短暂无法使用到zk，在微服务采用该模式下，可能无法实现通讯（本地有缓存除外）。

注意：可运行节点必须满足过半机制，整个zk才能使用。

Eureka采用AP的设计理念架构注册中心，完全去中心化思想，也就是没有主从之分。

每个节点都是均等，采用相互注册原理，你中有我、我中有你，只要最后一个eureka节点存在就可以保证整个微服务可以实现通讯。

在使用注册中心，可用性在优先级最高，可以读取数据短暂暂时不一致，但是至少要能够保证注册中心可用。

Nacos从1.0版本支持CP和AP混合模式集群，默认是采用AP保证服务可用性，CP的形式底层集群raft协议保证数据的一致性的问题。

如果采用AP模式注册服务的实例仅支持临时注册模式，在网络分区产生抖动的情况下，还可以机继续注册我们的服务列表。

那么采用CP模式必须保证数据的强一致性问题，如果网络分区产生抖动的情况下，是无法注册服务列表。选择CP模式可以支持注册实例持久。

其它情况下，AP即可。

中心化

    必须围绕一个领导角色作为核心，选举为领导和跟随者角色。

去中心化

    每个角色都是均等。

PUT请求