基于Nacos集群部署
1
nacos集群方案
图示
2
相关集群配置
＋
集群服务文件夹管理
创建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
注意
如果不进行这样的设置，那么nacos集群就不会进行选举。节点状态一直：FOLLOWER。
＋
nginx相关配置
# 配置负载均衡策略upstream nacosServer{server 192.168.2.121:8848;server 192.168.2.121:8849;server 192.168.2.121:8850;}server {location /nacos/ {proxy_pass http://nacosServer/nacos/;}}
＋
客户端连接
修改bootstrap.yaml
spring:cloud:nacos:discovery:#注册中心地址server-addr: 127.0.0.1enabled: trueconfig:#配置文件地址server-addr: 127.0.0.1group: DEFAULT_GROUPfile-extension: yamlapplication:#服务名称name: app-memberprofiles:active: dev
注意
如果配置文件设置单机模式，那么启动集群模式就需要添加：startup.cmd -m cluster
如果配置文件设置集群模式，那么启动单机模式就需要添加：startup.cmd –m standalone
图示
至此，nacos集群就配置完毕！
3
CAP定律
概念
CAP定律指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。
＋
一致性(C)
在分布式系统中，如果服务器集群，每个节点在同时刻访问必须保持数据的一致性。
＋
可用性(A)
集群节点中，部分节点出现故障后任然可以使用（高可用）。
＋
分区容错性(P)
在分布式系统中网络会存在脑裂的问题，部门Server与整个集群失去节点联系，无法组成一个群体。
注意
只有在CP和AP中选择一个平衡点。
示例
CP情况下，虽然服务不可用，但是必须要保证数据的一致性。
AP情况下，可以短暂保证数据不一致性，但是最终可以一致性，不管怎样，都要保证服务可用。
大多注册中心都是AP。
4
注册中心区别
Eureka与Zookeeper区别
＋
相同点
都是可以实现分布式服务注册中心。
＋
不用点
Zookeeper采用CP保证数据的一致性问题，原理采用Zab原子广播协议，当由于zk领导因为某种原因宕机的情况下，会自动出发重新选一个新的领导角色，整个选举的过程为了保证数据的一致性问题，在选举的过程中整合zk环境是不可以使用，可能短暂无法使用到zk，在微服务采用该模式下，可能无法实现通讯（本地有缓存除外）。
注意：可运行节点必须满足过半机制，整个zk才能使用。
Eureka采用AP的设计理念架构注册中心，完全去中心化思想，也就是没有主从之分。
每个节点都是均等，采用相互注册原理，你中有我、我中有你，只要最后一个eureka节点存在就可以保证整个微服务可以实现通讯。
在使用注册中心，可用性在优先级最高，可以读取数据短暂暂时不一致，但是至少要能够保证注册中心可用。
Eureka与Nacos区别
Nacos从1.0版本支持CP和AP混合模式集群，默认是采用AP保证服务可用性，CP的形式底层集群raft协议保证数据的一致性的问题。
如果采用AP模式注册服务的实例仅支持临时注册模式，在网络分区产生抖动的情况下，还可以机继续注册我们的服务列表。
那么采用CP模式必须保证数据的强一致性问题，如果网络分区产生抖动的情况下，是无法注册服务列表。选择CP模式可以支持注册实例持久。
＋
如何选择ACP模式
其它情况下，AP即可。
＋
概念性
中心化
必须围绕一个领导角色作为核心，选举为领导和跟随者角色。
去中心化
每个角色都是均等。
＋
实现切换模式
PUT请求
$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP