微服务主备故障转移通过去中心化动态选举、健康感知与自动重路由实现，依赖服务注册中心实时维护健康实例列表，网关或服务网格依据健康状态动态调整流量，并借助zookeeper/etcd等协调组件完成强主场景的leader选举与状态同步。
微服务实例的主备故障转移不是靠“固定主库+固定备库”这种数据库式角色划分来实现的，而是通过**去中心化、动态选举、健康感知与自动重路由**完成的。核心在于避免人为指定“谁永远是主、谁永远是备”，转而让系统在运行时根据实时状态自主决策。
服务注册与健康发现是前提
所有微服务实例启动后必须向注册中心（如Nacos、Eureka、Consul或etcd）注册自身信息，并持续上报心跳。注册中心不只记录IP和端口，更要能区分实例的健康状态。
- 健康检查需覆盖多层：进程存活、HTTP/GRPC端点可通、依赖组件（数据库、缓存）可用
- 注册中心应支持TTL机制，超时未续租则自动下线实例
- 客户端（如Feign、RestTemplate、gRPC stub）必须从注册中心拉取当前健康的服务列表，而非静态配置
流量路由需支持动态权重与熔断降级
网关或服务网格（如Spring Cloud Gateway、Istio）不能只做简单轮询，要能根据实例健康度实时调整转发策略。
- 当某实例连续失败（如5xx比例＞30%或超时率＞20%），自动将其权重降为0，暂停流量
- 支持主动探活：网关定期调用/
actuator/health或gRPC/healthz接口验证状态 - 在Istio中，可通过
DestinationRule配置outlierDetection实现自动驱逐异常Pod
状态协调需引入分布式共识组件
对于确有强主需求的场景（如定时任务调度器、ID生成器、配置中心写节点），不能靠应用层“抢锁”或文件标记，而应交由专业协调服务管理。
- 使用ZooKeeper临时节点或etcd Lease + Watch机制选举Leader
- Leader失效后，其余节点监听到事件，触发本地状态切换（如从“只读”切为“读写”）
- 所有客户端通过监听协调服务的Key变更，获取最新Leader地址并更新本地路由
数据一致性不能依赖“主备同步”，而要靠业务设计
微服务天然分布，不存在全局主库。所谓“主备”通常指某个有状态组件（如Redis集群、MySQL分片）的高可用，而非整个微服务实例。
- 无状态服务本身无需主备——实例挂了就下线，新实例起来自动加入，这是水平伸缩的本质
- 有状态服务（如会话存储、模型缓存）应使用自带故障转移能力的中间件（如Redis Sentinel、MySQL MHA、达梦Data Watch）
- 跨服务的数据最终一致性，靠消息队列（RocketMQ、Kafka）+ 本地事务表 + 补偿任务保障
