1. 高可用注册中心的核心痛点与方案选型1.1 单点Nacos到底卡在哪里做过微服务架构的朋友都清楚注册中心是整个服务治理体系的“通讯录”。所有服务实例的上下线、健康状态、配置变更都要经过它来协调。一旦注册中心挂了服务间的调用链路会迅速雪崩——消费者拿不到最新的提供者列表配置推送全部失效整个集群就像失去了指挥的交响乐团。我最早接触Nacos的时候图省事就单机模式跑着开发环境倒也没出过什么大问题。但有一次线上做压测Nacos所在的那台机器磁盘IO突然飙高导致心跳检测大面积超时服务实例被误判为不健康而批量摘除。那次事故让我彻底明白注册中心的高可用不是“锦上添花”而是“生死攸关”。单点Nacos的问题主要集中在三个层面。第一是硬件层面服务器宕机、网络中断、磁盘故障任何一个环节出问题都会导致服务不可用。第二是软件层面JVM Full GC停顿、内存泄漏、连接池耗尽这些都会让Nacos进程假死。第三是运维层面版本升级、配置变更、日志清理这些日常操作在单点架构下都意味着服务中断。1.2 为什么选择Keepalived而不是其他方案提到高可用很多人第一反应是上集群。Nacos确实支持集群模式通常建议至少三个节点。但集群模式有个现实问题它解决的是“多个Nacos实例同时提供服务”的问题客户端需要配置所有节点地址或者前面挂一个负载均衡器。对于中小规模团队来说维护三台Nacos节点的成本并不低而且负载均衡器本身又成了新的单点。Keepalived的思路完全不同。它基于VRRP协议在两台或多台服务器之间虚拟出一个VIP虚拟IP。同一时刻只有一台服务器持有VIP并对外提供服务其他节点处于待命状态。一旦主节点出现故障备用节点会在秒级内接管VIP整个过程对客户端完全透明。这个方案的优势在于架构简单只需要两台服务器就能搭建切换迅速VRRP心跳检测间隔可以精确到毫秒级对客户端零侵入所有服务只需要配置VIP地址不需要关心背后是哪台机器在提供服务。当然它也有局限性——同一时刻只有一台Nacos在工作资源利用率不如集群模式。但对于大多数中小规模场景来说这个方案在可靠性和复杂度之间找到了很好的平衡点。1.3 整体架构设计思路整个方案的核心思路可以用一句话概括用Keepalived管理VIP的漂移用Nacos提供注册与配置服务两者结合实现接入层的高可用。具体来说准备两台配置相当的服务器分别部署Nacos和Keepalived。两台Nacos都使用相同的数据库通常是MySQL保证数据一致性。Keepalived配置为一主一备主节点持有VIPNacos绑定在VIP上对外提供服务。客户端只需要配置VIP地址完全感知不到后端的具体节点。这里有个关键点需要特别注意Nacos的数据持久化必须使用外部数据库。如果使用内置的Derby数据库两台Nacos的数据是独立的切换后会出现数据不一致的问题。使用同一个MySQL实例后无论哪台Nacos在工作读写的都是同一份数据切换后服务列表和配置信息完全一致。注意MySQL本身也需要考虑高可用但这超出了本文的讨论范围。在实际生产环境中建议MySQL也做主从或者使用云数据库服务。2. 环境准备与基础组件安装2.1 服务器规划与系统调优先说说服务器规划。我建议至少准备两台配置相同的机器操作系统用CentOS 7.9或者Ubuntu 20.04 LTS都可以。内存方面Nacos本身比较吃内存建议每台至少4GB起步8GB会更从容。CPU双核就够用但考虑到Keepalived和系统本身的消耗四核会更稳妥。系统调优这块有几个参数必须调整否则后面会踩坑。首先是文件句柄数Nacos在服务实例多的时候会打开大量连接默认的1024远远不够。修改/etc/security/limits.conf添加以下内容* soft nofile 65536 * hard nofile 65536 * soft nproc 65536 * hard nproc 65536然后是内核参数优化编辑/etc/sysctl.confnet.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_fin_timeout 30 net.ipv4.tcp_max_tw_buckets 5000 net.core.somaxconn 65535 net.ipv4.tcp_max_syn_backlog 65535 vm.swappiness 10执行sysctl -p让配置生效。这些参数的作用分别是加快TIME_WAIT状态的连接回收、减少FIN_WAIT2的超时时间、增大TCP连接队列、降低内存交换倾向。实测下来调整后Nacos在高并发场景下的稳定性有明显提升。2.2 JDK与MySQL的安装配置Nacos依赖JDK 8或JDK 11我推荐用JDK 8兼容性最好。安装过程不复杂下载tar包解压到/usr/local/目录然后配置环境变量export JAVA_HOME/usr/local/jdk1.8.0_291 export PATH$JAVA_HOME/bin:$PATH export CLASSPATH.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jarMySQL建议用5.7或8.0版本安装完成后需要创建Nacos专用的数据库和用户。这里有个细节容易被忽略数据库连接池的配置。Nacos默认使用Druid连接池如果MySQL的wait_timeout设置得太短连接会被服务端主动断开导致Nacos报错。建议在MySQL的my.cnf中设置wait_timeout 28800 interactive_timeout 28800然后创建数据库和用户CREATE DATABASE nacos_config DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; CREATE USER nacos% IDENTIFIED BY 你的密码; GRANT ALL PRIVILEGES ON nacos_config.* TO nacos%; FLUSH PRIVILEGES;最后导入Nacos的初始化SQL脚本这个脚本在Nacos安装包的conf目录下文件名是nacos-mysql.sql。2.3 Nacos的安装与关键配置修改Nacos的安装包从官方渠道获取解压到/usr/local/nacos目录。接下来是重点——修改配置文件。编辑conf/application.properties核心修改如下spring.datasource.platformmysql db.num1 db.url.0jdbc:mysql://你的MySQL地址:3306/nacos_config?characterEncodingutf8connectTimeout1000socketTimeout3000autoReconnecttrueuseUnicodetrueuseSSLfalseserverTimezoneUTC db.usernacos db.password你的密码这里有几个参数值得展开说。connectTimeout1000表示连接超时1秒socketTimeout3000表示读写超时3秒这两个值不要设得太大否则数据库故障时Nacos会长时间阻塞。autoReconnecttrue确保连接断开后自动重连。useSSLfalse是因为内网环境通常不需要SSL开启反而增加开销。还有一个关键配置在conf/cluster.conf中虽然我们用的是VIP方案但Nacos本身还是需要知道自己的节点信息。这个文件里填写两台Nacos的IP和端口192.168.1.101:8848 192.168.1.102:8848提示cluster.conf中的IP不要写VIP要写每台机器的真实IP。VIP是Keepalived管理的Nacos本身不需要感知VIP的存在。3. Keepalived的部署与VIP漂移机制3.1 Keepalived安装与主备节点配置Keepalived的安装很简单CentOS下直接yum install -y keepalivedUbuntu下apt install -y keepalived。安装完成后配置文件在/etc/keepalived/keepalived.conf。主节点的配置如下global_defs { router_id NACOS_MASTER script_user root enable_script_security } vrrp_script check_nacos { script /etc/keepalived/check_nacos.sh interval 2 weight -30 fall 3 rise 2 } vrrp_instance VI_NACOS { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass nacos123 } virtual_ipaddress { 192.168.1.100/24 } track_script { check_nacos } }备节点的配置只有三处不同router_id改为NACOS_BACKUPstate改为BACKUPpriority改为90。其他保持一致。这里解释几个关键参数。virtual_router_id是VRRP组的标识主备必须一致取值范围1-255。priority决定谁成为主节点数值大的优先。advert_int 1表示每秒发送一次VRRP通告。authentication是认证信息主备必须一致防止非法节点加入。3.2 健康检查脚本的编写要点Keepalived本身只能检测网络层面的连通性它不知道Nacos是否真的在工作。所以我们需要一个健康检查脚本来判断Nacos的服务状态。这个脚本是整套方案的核心写得好不好直接决定了故障切换的准确性。#!/bin/bash # /etc/keepalived/check_nacos.sh COUNT$(ps -ef | grep nacos | grep -v grep | wc -l) if [ $COUNT -eq 0 ]; then exit 1 fi HTTP_CODE$(curl -s -o /dev/null -w %{http_code} --connect-timeout 2 --max-time 3 http://127.0.0.1:8848/nacos/v1/console/health/readiness) if [ $HTTP_CODE ! 200 ]; then exit 1 fi exit 0这个脚本做了两层检查。第一层检查Nacos进程是否存在第二层通过HTTP接口检查Nacos是否真正就绪。/nacos/v1/console/health/readiness是Nacos提供的就绪检查接口返回200表示服务正常。脚本写完后要赋予执行权限chmod x /etc/keepalived/check_nacos.sh。然后在Keepalived配置中通过track_script引用它。当脚本返回非0值时weight -30会让当前节点的优先级降低30如果降低后的优先级低于备节点VIP就会漂移过去。注意fall 3表示连续失败3次才认为节点故障rise 2表示连续成功2次才认为节点恢复。这两个值不要设得太小否则网络抖动会导致频繁切换。3.3 VIP漂移的完整流程解析VIP漂移的过程可以拆解为几个阶段。正常情况下主节点持续发送VRRP通告备节点收不到通告就认为主节点还活着自己保持BACKUP状态。当主节点的健康检查脚本连续失败3次后优先级从100降到70低于备节点的90。备节点在收到主节点的VRRP通告时发现对方优先级比自己低就会抢占成为新的主节点接管VIP。整个切换过程通常在3-5秒内完成。客户端配置的是VIP地址切换后新主节点会通过ARP广播更新VIP对应的MAC地址交换机更新ARP表后后续流量就会转发到新主节点。这里有个细节需要留意Nacos客户端的心跳和重连机制。Nacos客户端默认每5秒发送一次心跳如果连接断开会自动重连。在VIP切换的几秒窗口内部分心跳可能会失败但客户端会自动重试不会导致服务实例被摘除。不过为了保险起见建议把客户端的namingPushEmptyProtection参数设为true防止在切换瞬间收到空的服务列表。4. 完整实操流程与验证方法4.1 部署顺序与启动步骤部署顺序很重要顺序错了会导致各种奇怪的问题。我推荐的顺序是先MySQL再Nacos最后Keepalived。第一步在两台服务器上分别安装JDK、MySQL客户端不需要本地MySQL但需要客户端工具、Nacos。Nacos的application.properties和cluster.conf配置完全一致。第二步启动两台Nacos。启动命令是sh /usr/local/nacos/bin/startup.sh -m cluster。注意这里用的是cluster模式不是standalone模式。启动后检查日志logs/start.out看到“Nacos started successfully in cluster mode”才算成功。第三步验证两台Nacos都能正常访问。分别通过http://192.168.1.101:8848/nacos和http://192.168.1.102:8848/nacos访问控制台默认用户名密码都是nacos。登录后确认服务列表和配置列表数据一致。第四步安装并配置Keepalived。先启动主节点的Keepalived再启动备节点。启动命令是systemctl start keepalived。启动后通过ip addr show eth0查看VIP是否在主节点上。4.2 故障切换的验证与观察验证是整套方案中最关键的环节不经过验证的高可用方案都是纸上谈兵。我通常从三个层面来验证。第一层手动停止Nacos进程。在主节点上执行sh /usr/local/nacos/bin/shutdown.sh然后观察VIP是否漂移到备节点。可以通过ip addr命令在备节点上查看也可以用ping 192.168.1.100持续观察网络连通性。正常情况下3-5秒内VIP就会漂移过去。第二层模拟网络故障。在主节点上执行systemctl stop network断开网络观察备节点是否接管VIP。这个测试更接近真实故障场景因为网络中断时Keepalived的VRRP通告也会中断。第三层模拟服务假死。在主节点上执行kill -STOP $(pgrep -f nacos)让Nacos进程暂停模拟JVM假死。这种情况下进程还在但服务已经不可用。健康检查脚本会检测到HTTP接口超时触发VIP漂移。每次验证后记得恢复环境把主节点重新启动起来观察VIP是否会自动漂移回去。Keepalived默认配置下原主节点恢复后如果优先级更高会抢占VIP。如果不想让它抢占可以在备节点配置中加入nopreempt选项。4.3 客户端接入与参数调优客户端接入很简单只需要把Nacos地址配置为VIP即可spring.cloud.nacos.discovery.server-addr192.168.1.100:8848 spring.cloud.nacos.config.server-addr192.168.1.100:8848但有几个参数建议调整以提升切换时的体验spring.cloud.nacos.discovery.naming-load-cache-at-starttrue spring.cloud.nacos.discovery.watch-delay3000 spring.cloud.nacos.discovery.heart-beat-interval5000 spring.cloud.nacos.discovery.heart-beat-timeout15000 spring.cloud.nacos.discovery.ip-delete-timeout30000naming-load-cache-at-starttrue让客户端启动时加载本地缓存即使Nacos暂时不可用也能正常启动。watch-delay3000是服务列表变更的推送延迟适当增大可以减少切换瞬间的推送风暴。heart-beat-timeout15000是心跳超时时间设为15秒可以避免VIP切换期间实例被误摘除。提示这些参数需要根据实际网络环境和业务特点调整。如果网络延迟较大可以适当增大超时时间如果对故障感知速度要求高可以适当减小。5. 常见问题排查与避坑经验5.1 脑裂问题的成因与预防脑裂是Keepalived方案中最需要警惕的问题。所谓脑裂就是主备节点同时认为自己是主节点同时持有VIP。这种情况通常发生在网络分区时——主备之间的VRRP通告中断但两台机器本身都在正常运行。脑裂的后果很严重两个Nacos同时对外提供服务客户端可能连接到不同的节点导致服务列表不一致。更糟糕的是如果两个节点都往同一个MySQL写数据可能造成数据覆盖。预防脑裂有几个措施。首先使用单播模式代替组播。在Keepalived配置中加入unicast_src_ip和unicast_peer明确指定对端地址避免组播被网络设备过滤。其次配置双路心跳除了网卡心跳外可以增加串口心跳或者通过外部脚本检测。最后在Nacos层面做防护确保同一时刻只有一个节点在写数据库。如果已经发生了脑裂处理方法是先停止其中一台的Keepalived确认VIP只在一台机器上然后检查MySQL中的数据是否有冲突必要时手动修复。5.2 VIP漂移后服务未恢复的排查有时候VIP漂移成功了但服务还是不可用。这种情况通常是以下几个原因导致的。原因一Nacos启动太慢。VIP漂移过去了但备节点的Nacos还没完全启动导致请求失败。解决办法是在健康检查脚本中增加启动等待逻辑或者调整Keepalived的rise参数确保Nacos完全就绪后才接管VIP。原因二防火墙拦截。VIP漂移后客户端的请求到达新节点但被防火墙拦截了。检查iptables或firewalld规则确保8848端口和VRRP协议协议号112是放行的。原因三ARP缓存未更新。有些交换机或客户端的ARP缓存更新不及时导致流量还是发往旧节点。可以在Keepalived配置中加入garp_master_delay和garp_master_repeat参数主动发送ARP广播更新缓存。原因四Nacos数据不一致。如果两台Nacos没有使用同一个数据库切换后服务列表会不一致。检查application.properties中的数据库配置确保两台指向同一个MySQL。5.3 性能调优与监控建议方案跑起来之后还需要持续监控和调优。我整理了一个常见问题的速查表问题现象可能原因排查方法解决方案VIP频繁漂移网络抖动或健康检查过于敏感查看Keepalived日志/var/log/messages增大fall和rise值调整intervalNacos响应慢JVM内存不足或数据库连接池耗尽查看Nacos日志和JVM监控增大堆内存调整连接池参数服务实例被误摘除心跳超时时间太短查看Nacos日志中的心跳记录增大heart-beat-timeout配置推送失败长连接断开或客户端版本不兼容查看客户端日志升级客户端版本检查网络稳定性切换后数据不一致数据库未共享或同步延迟对比两台Nacos的数据确保使用同一个MySQL实例监控方面建议重点关注几个指标Keepalived的VIP状态、Nacos的JVM内存和GC情况、MySQL的连接数和慢查询、以及客户端的心跳成功率。这些指标可以通过Prometheus加Grafana来采集和展示也可以写简单的脚本定时检查。注意Nacos本身提供了监控接口/nacos/actuator/metrics可以获取服务数、配置数、连接数等关键指标。建议把这个接口接入监控系统。6. 方案扩展与进阶思考6.1 从双节点到多节点的演进双节点方案虽然简单但有个天然缺陷备节点平时是闲置的资源利用率只有50%。如果业务规模增长可以考虑扩展到多节点。多节点方案有两种思路。一种是多主模式所有节点都持有VIP客户端通过DNS轮询或者负载均衡器分发请求。这种模式资源利用率高但需要解决数据同步和冲突问题。另一种是一主多备模式一个主节点加多个备节点备节点按优先级排队接管。这种模式切换逻辑更清晰但资源浪费更严重。从双节点演进到多节点时VRRP的virtual_router_id和priority需要重新规划。建议主节点优先级设为100备节点依次为90、80、70确保切换顺序可控。6.2 与容器化环境的结合现在很多团队都在往容器化方向走Keepalived方案在Kubernetes环境下需要做一些调整。Kubernetes本身有Service和Ingress来做负载均衡但Nacos作为有状态服务用StatefulSet部署更合适。在Kubernetes中可以用hostNetwork模式让Pod直接使用宿主机网络然后在Pod中运行Keepalived。但这种方式需要给Pod分配足够的权限配置起来比较麻烦。另一种思路是放弃Keepalived直接用Kubernetes的Service加NodePort或者LoadBalancer来暴露Nacos高可用由Kubernetes本身来保证。两种方案各有优劣。Keepalived方案更轻量适合传统虚拟机环境Kubernetes方案更云原生适合已经容器化的团队。选择哪种取决于现有的技术栈和运维能力。6.3 我踩过的几个坑最后分享几个我在实际部署中踩过的坑希望能帮大家少走弯路。坑一Nacos的cluster.conf中写了VIP。一开始我想当然地把VIP写进了cluster.conf结果Nacos启动时报错说无法解析地址。后来才明白cluster.conf需要的是每台机器的真实IPVIP是Keepalived管理的Nacos不需要知道。坑二健康检查脚本用了curl但没装。有些精简版的操作系统没有预装curl导致健康检查脚本一直失败VIP频繁漂移。部署前记得确认curl是否可用或者改用wget。坑三MySQL的wait_timeout太短。默认的wait_timeout是28800秒8小时但有些云数据库默认只有几分钟。连接被服务端断开后Nacos的连接池没有及时检测到导致请求失败。解决办法是在JDBC URL中加上autoReconnecttrue并适当增大wait_timeout。坑四防火墙没放行VRRP协议。VRRP使用的是IP协议号112不是TCP也不是UDP。有些防火墙默认只放行TCP和UDP导致VRRP通告被拦截主备无法通信。记得在防火墙规则中放行协议号112。坑五Nacos版本不一致。两台Nacos的版本必须完全一致否则可能出现数据格式不兼容的问题。升级时也要两台一起升级不能一台一台来。这些坑看起来都不大但每一个都可能导致方案失败。部署前对照检查一遍能省下不少排查时间。