尧图网站建设 
DNS负载均衡详解DNS 负载均衡是最上游的一层负载均衡它工作在域名解析阶段让同一个域名在不同地区、不同运营商解析出不同的 IP从而把用户就近调度到合适的机房。它的优点是简单、天然抗流量、覆盖广缺点是生效慢缓存长和扩展性差控制权在域名商。本文围绕这两个缺点展开。一、DNS 负载均衡是怎么工作的1. 正常 DNS 解析流程回顾用户访问www.baidu.com浏览器先问本地 DNS通常由运营商提供LDNS/Recursive DNS浏览器 → 本地 DNS运营商递归解析器→ 根 DNS → 顶级域(.com) DNS → 权威 DNSbaidu 自己的权威 DNS 返回一个 A 记录IP 地址浏览器拿到 IP 后再发起 HTTP 请求。2. DNS 负载均衡的核心智能解析普通 DNS 对所有查询返回同一个 IP。DNS 负载均衡也叫智能 DNS、GSLB 的 DNS 调度方式则根据请求来源返回不同 IPwww.baidu.com │ ┌────────┴────────┐ │ 权威 DNS智能 │ ← 根据来源 EDNS-Client-Subnet / 来源 IP 段判断 └────────┬────────┘ ┌──────────┼──────────┐ ▼ ▼ 北方用户 南方用户 返回 61.135.165.224 返回 14.215.177.38 北京机房 IP 深圳机房 IP判断依据主要有两种请求来源 IP权威 DNS 能看到的是运营商递归解析器LDNS的出口 IP而不是用户真实 IP。所以北方用户更准确的说法是用北方 LDNS 的用户。EDNS-Client-SubnetECS协议扩展递归解析器会把用户真实网段塞进请求里传给权威 DNS调度更精准。但不是所有递归解析器都支持 ECS。返回的不同 IP可以是不同机房的真实 IP直连模式后端 IP 直接暴露不同机房的前置负载均衡器 IP更常见如 LVS/VIP后端再做多级负载均衡3. 它解决什么问题就近接入北方用户走北京机房延迟低南方用户走深圳机房。运营商分流联通用户走联通机房电信用户走电信机房避免跨网绕行跨网延迟高、丢包多。容灾切换某机房整体故障把该机房的 IP 从 DNS 摘掉新解析的流量自动到其他机房。无限扩展入口DNS 层扛的是解析量单机房扛不住就多挂几个机房 IP。关键认知DNS 负载均衡是调度层不是真正的流量转发层。它只决定这次解析把谁引向哪个机房后续的流量分发还要靠机房内部的 LVS/Nginx 等。可以把它理解为指路牌。二、用 DNS 负载均衡是不是一定要搭配异地多活不是必须但绝大多数生产场景会搭配使用。要分开看两个概念1. DNS 负载均衡 ≠ 异地多活DNS 负载均衡一种流量调度手段把用户分到不同 IP。异地多活一种架构形态多个异地机房同时对外提供服务、且数据层面能独立承载完整业务数据要同步/复制故障时能接管。只有 DNS、没有异地多活也是成立的——例如多机房只是冷备/热备主机房扛流量备机房空转DNS 只指向主。这时 DNS 不做分流只做故障切换。多机房是同地多机房都在同城DNS 分流只是分摊入口压力谈不上异地。CDN 场景DNS 把图片/静态资源解析到边缘节点这叫 CDN 调度也不算异地多活。2. 什么时候必须搭配异地多活当你的目标满足以下任意一条DNS 负载均衡就需要建立在异地多活之上才有意义目标为什么需要异地多活单机房宕机后业务不能停备机房必须能独立跑通完整业务否则 DNS 切过去也是 500要求地域级容灾整城市断网/断电必须异地同机房不行要求就近写入低延迟写多活意味着每个机房都能写数据双向同步流量超过单机房物理上限多机房分担且每个机房都要能扛全量或按比例3. 只做 DNS 不做多活会发生什么典型翻车场景DNS 把北方用户指向北京机房北京机房挂了DNS 摘掉北京 IP所有用户解析到深圳机房。但深圳机房数据没有北京的最新写入 → 业务数据不一致容量没规划到扛全量 → 雪崩没有对应的服务配置/缓存预热 → 降级所以异地多活是 DNS 负载均衡能真正容灾的前提。没有多活DNS 负载均衡只是分流不是容灾。一句话总结DNS 负载均衡负责指路异地多活负责路那头真的有完整的服务在跑。指路很准但目的地是空城等于没指。三、缺点一更新不及时 —— 缓存多久怎么解决1. 为什么会更新不及时DNS 是一个层层缓存的系统缓存粒度很粗浏览器 DNS 缓存 → 操作系统 DNS 缩存 → 本地路由器 → 运营商 LDNS递归解析器→ 权威 DNS你修改的是**最末端权威 DNS**的记录但中间每一层都缓存着旧值。只要缓存没过期用户解析出来的还是旧 IP。2. 缓存时间一般多久 —— TTL缓存时长由 DNS 记录的TTLTime To Live决定单位秒。常见取值场景典型 TTL说明静态/CDN 域名3600s1 小时甚至 86400s1 天IP 几乎不变长 TTL 减少权威压力普通业务域名600s ~ 1800s10~30 分钟兼顾稳定与切换速度需要快速容灾切换60s ~ 120s短 TTL牺牲权威压力换切换速度极端秒级切换30s 以下已接近 DNS 协议极限且非自己能完全控制关键陷阱TTL 只对你自己权威 DNS 返回的那条记录有效对以下两层无效运营商 LDNS 不一定遵守 TTL部分运营商为了省解析量会把短 TTL 强行拉长比如把 60s 改成 600s 甚至更长这你完全管不到。LDNS 之上还有各级缓存用户本机、家用路由器也可能缓存尤其一些奇葩路由器。应用层自己缓存JVM 的InetAddress默认缓存 30 秒networkaddress.cache.ttl但有的框架/连接池会永久缓存解析结果改了 DNS 也不重连。所以**修改 DNS 后多久全网生效的真实答案大多数用户在 1 个 TTL 周期内刷新但总有长尾用户可能持续几小时甚至几天还在用旧 IP**。这就是更新不及时的本质。3. 怎么解决 / 缓解按治标 → 治本排列(1) 缩短 TTL —— 最基础但有代价把容灾域名的 TTL 调到 60s 级别。代价权威 DNS 查询量飙升缓存短了LDNS 更频繁回源需要权威 DNS 抗得住。而且对不遵守 TTL 的运营商无效。(2) 预先降低 TTL切换前的标准动作切换前 1~2 个 TTL 周期就把 TTL 调小等旧长 TTL 过期后再做变更。这是 SRE 切流量的标准 SOPT0 : 把 TTL 从 1800s 调到 60s T1800 : 旧的长 TTL 已全部过期全网都是 60s 的记录 T1800 : 此时修改 IP最多 60s 内大部分用户生效(3) 双 IP / 多 IP 并存新旧共存过渡修改不是摘旧加新而是先加新后摘旧新旧机房 IP同时返回给用户轮询/随机。观察新机房流量逐步上涨、旧机房流量下降稳定后再把旧 IP 摘掉。这样即使有用户缓存了旧 IP旧机房还在服务不会直接失败。这是生产里最常用、最稳的切换姿势。(4) 应用层配合客户端重试 / 多 IP 连接HTTP 客户端配置多个 IP连接失败自动切换到下一个OkHttp、curl --resolve多 IP、gRPC 多地址。移动端 SDK 自带降级DNS 解析失败或连接超时走 HTTPDNS 或硬编码备用 IP 列表。(5) HTTPDNS —— 绕过系统 DNS 的治本方案这是大厂阿里、腾讯、HTTPDNS 厂商对DNS 缓存不可控的根本对策客户端不走系统 DNS而是通过 HTTP 请求一个自建的 DNS 调度服务。调度服务直接拿到用户真实 IP 业务上下文返回最优 IP。客户端自己控制缓存时长通常 30s~60s且可被服务端主动推送失效。优点精准用户真实 IP不是 LDNS 出口、可控TTL 完全自定、生效快、能防 DNS 劫持。代价要自建调度服务、客户端要改造、只覆盖自家 App网页/第三方调用方覆盖不到。典型组合公网用 DNS 负载均衡做广覆盖自家 App 用 HTTPDNS 做精准调度和秒级切换。(6) 流量层兜底Anycast / BGP 切换Anycast同一个 IP 在多个机房 BGP 播出网络层自动把流量路由到最近的机房。改的不是 DNS是路由切换在网络层完成几乎实时。DNS 层 IP 不变缓存不缓存都无所谓。BGP 路由切换某机房故障在 BGP 层把该机房 IP 撤回流量自动绕到其他机房。比 DNS 快得多秒级。代价要自网段、要和运营商谈 BGP成本高通常只有大厂/金融/CDN 厂商用。四、缺点二扩展性差 —— 对谁做什么定制化1. 为什么扩展性差DNS 负载均衡的调度逻辑在域名商/权威 DNS 服务商手里阿里云解析、DNSPod、AWS Route53 等。你只能配几条规则按地区/运营商分线路返回按权重返回不同 IP 的比例健康检查 故障切换部分厂商支持但你想在调度时结合业务语义做更细的判断——做不到因为 DNS 协议本身只是问域名→答 IP没有业务上下文。2. 对谁做什么定制化 —— 业务里真实需要的能力下面列的是生产里真实会想做、但纯 DNS 做不到、需要自研调度层HTTPDNS / GSLB 控制面 / 服务网格 / 网关来补的定制化能力。(1) 针对单个用户的调度按用户 ID 灰度某个用户是 A/B 实验组永远解析到灰度机房DNS 拿不到用户 ID做不到。VIP 用户专线高价值用户永远走高质量机房DNS 拿不到用户身份。按设备类型iOS / Android / 小程序分流到不同后端DNS 拿不到 User-Agent。DNS 在请求域名时拿到的只有来源 IP 网段没有用户身份、没有业务标签。这是它扩展性差的根本原因。(2) 针对后端机房实时状态的调度按机房实时负载调度某机房 CPU 飙到 90%少分点流量过去。DNS 健康检查只有通/不通拿不到负载指标。按机房剩余容量调度容量评估后按比例分流容量变了动态调整权重。DNS 厂商的权重是静态配置的不能随实时容量变。按机房依赖健康调度某机房依赖的下游MySQL/Redis/支付网关抖动主动降权。DNS 完全感知不到下游。(3) 针对业务语义的调度按接口粒度分流/order走订单机房/pay走支付机房/search走搜索机房。DNS 是域名级一个域名只能指向一组 IP分不了接口。按请求内容路由大文件下载走 CDN/对象存储小请求走计算机房读请求走读库机房写请求走主库机房。DNS 拿不到请求内容。会话保持Session Stickiness同一用户的请求始终落到同一机房本地缓存/会话命中。DNS 只在解析时调度连接复用后会话漂移不可控。预热/压测流量隔离压测流量打标记后路由到影子机房不影响真实业务。DNS 拿不到流量标记。(4) 针对容灾切换策略的定制分级容灾机房降级≠摘掉而是先降权 50%、再摘掉。DNS 只有摘/不摘部分厂商支持降权但策略固定。爆炸半径控制切流量要分批5% → 20% → 50% → 100%每批观察指标。DNS 厂商的切换是瞬时的分批要靠自研控制面。降级联动机房故障时不仅要切流量还要触发下游限流、熔断、读旧数据等业务降级。DNS 做不到业务联动。(5) 针对成本的调度按计费档位调度某机房流量超额计费贵了把流量挪到便宜机房。DNS 厂商不知道你的计费。闲时忙时调度白天高峰多机房分担深夜单机房收口省钱。DNS 没有定时动态调权的通用能力。3. 怎么补这个扩展性差演进路径一般是纯 DNS 负载均衡域名商 │ 能力不够 ▼ DNS 自研 GSLB 控制面 自研权威 DNS 健康检查 容量调度 切流 SOP │ 要更精准/秒级 ▼ HTTPDNSApp 端绕过系统 DNS │ 要细到接口/会话/内容 ▼ 业务网关 / 服务网格Spring Cloud Gateway、Envoy、API Gateway 按 URL、Header、用户、负载做细粒度路由每一层补的是上一层做不到的能力层调度粒度典型能力DNS 负载均衡地区/运营商 域名就近、运营商分流、粗容灾自研 GSLB机房 容量 健康动态权重、分级容灾、分批切流HTTPDNS单用户 真实 IP秒级生效、防劫持、用户级灰度业务网关/网格接口/Header/会话内容路由、会话保持、灰度发布一句话总结DNS 负载均衡是大喇叭喊方向扩展性差是因为它喊的时候只知道你是哪来的不知道你是谁、要干啥、后端忙不忙。要补这些业务定制化能力必须叠加 GSLB / HTTPDNS / 网关这一层自研控制面。五、一般公司会使用吗典型业务场景与收益1. 门槛其实很低所以用得很普遍先纠正一个常见误解DNS 负载均衡不是大厂专属。不需要自建权威 DNS。你在阿里云解析、DNSPod、Cloudflare、AWS Route53 上配几条分线路/分地区记录就是在用 DNS 负载均衡控制台点几下就行免费或很便宜。不需要自网段、不需要 BGP。那是 Anycast/网络层切流才需要的DNS 层只要域名解析服务支持智能解析/线路分流即可。所以严格说绝大多数有公网域名的公司都在用 DNS 这一层做调度区别只在于用得多深公司类型用 DNS 负载均衡到什么程度个人/小站点单机房DNS 只指向一个 IP不分流——严格说不算负载均衡只是解析中小公司单机房DNS 指向机房前置 LVS/Nginx 的 VIPDNS 层不分流靠机房内负载均衡多机房/多地域公司正经用 DNS 负载均衡按地区/运营商分线路返回不同机房 IP大厂/CDN/金融DNS 负载均衡 自研 GSLB HTTPDNS Anycast 全套叠加结论DNS 负载均衡是性价比最高的入口调度层门槛极低几乎人人用得起真正有门槛的是它上面叠加的 HTTPDNS / Anycast / 自研 GSLB。2. 典型业务场景场景一地域就近接入最经典业务电商、视频、资讯、搜索等面向全国用户的服务。做法北方用户解析到北京机房南方用户解析到深圳/广州机房。收益降低访问延迟跨地域 RTT 从几十毫秒降到几毫秒提升体验和转化率。场景二运营商分流解决跨网问题业务国内 To C 业务用户分布在电信/联通/移动各运营商。做法联通用户解析到联通机房 IP电信用户解析到电信机房 IP。收益避免跨网绕行跨网延迟高、丢包、成本贵这是国内特有的强需求。早期单机房用 BGP 多线也能解决但贵多机房 DNS 分流更经济。场景三异地容灾切换业务对可用性有要求的业务金融、支付、核心交易、SaaS。做法平时 DNS 分流到多机房某机房故障把该机房 IP 从 DNS 摘掉或降权新解析的流量自动到其他机房。收益机房级故障时业务不整体宕机。前提是异地多活否则切过去是空城见上文第二节。场景四灰度发布 / 蓝绿部署业务新版本上线要控制爆炸半径。做法DNS 配权重新版本机房先承接 10% 流量观察指标后逐步提到 50%、100%最后摘掉老机房。收益版本故障时影响面可控可快速回滚。注意 DNS 权重是解析比例由于缓存存在实际流量比例会有偏差需配合短 TTL。场景五CDN 调度最广泛的隐性使用业务图片、视频、静态资源、直播、大文件下载。做法资源域名解析到 CDN 厂商的调度系统由 CDN 再把用户引到最近的边缘节点。这本质就是 DNS 负载均衡。收益边缘节点扛静态流量源站压力骤降用户就近取内容。这是 DNS 负载均衡覆盖面最广的应用——几乎所有用 CDN 的公司都在用。场景六多机房容量分担业务流量超过单机房物理上限大促、秒杀、直播高峰。做法DNS 按权重把流量分到多个机房每个机房各扛一部分。收益横向扩容扛住峰值单机房不用无限堆机器。大促前临时调权重把流量多分给预备机房。场景七上下游/合作方对接业务开放平台、第三方接入、多租户 SaaS。做法不同租户/合作方解析到不同机房或不同环境做物理隔离。收益故障隔离 合规隔离如金融客户数据要求本地机房。3. 使用它能带来什么收益清单收益说明就近接入降延迟用户被引到最近机房RTT 显著降低体验直接提升跨网避免绕行国内多运营商场景下避免跨网高延迟和高成本横向扩容扛峰值多机房分担突破单机房容量天花板大促/秒杀刚需机房级容灾故障摘 IP 即可切流配合多活实现业务连续性灰度可控权重调度做版本/机房灰度爆炸半径小门槛低、成本极低不用自网段、不用 BGP云厂商控制台点点就能用覆盖广、抗量大DNS 层只扛解析量扛百万 QPS 解析毫无压力且天然支持任意客户端4. 反过来——它不适合做什么避免误用不能做会话保持DNS 调度只在解析时生效连接复用后会话会漂移。不能做精准/实时调度拿不到用户身份、机房实时负载、请求内容见第四节。不能做秒级切换受 TTL 和运营商缓存限制分钟级是常态。不适合做单接口粒度路由一个域名一组 IP分不了/api和/web。所以正确姿势是DNS 负载均衡做广覆盖的地域/运营商级大颗粒分流 粗容灾把它的低门槛、抗量、覆盖广用满精准、实时、业务相关的调度交给上层 GSLB/HTTPDNS/网关。六、如何搭配 Java 后端项目使用——流程与配置DNS 负载均衡是入口层Java 后端是业务层中间还要有机房前置负载均衡。完整链路是用户 │ 解析 www.example.com ▼ DNS 负载均衡云解析按地区/运营商分流 │ 返回北京机房 VIP 或 深圳机房 VIP ▼ 机房前置负载均衡LVS / HAProxy / NginxVIP │ 四层/七层转发 ▼ Nginx七层反向代理 健康检查 │ 转发到本机房内的 Java 实例 ▼ Java 应用集群Spring Boot 实例 × N 台 │ 服务间调用走注册中心Nacos/Eureka同机房优先 ▼ 数据层MySQL/Redis跨机房同步 异地多活认知DNS 只负责把用户引到哪个机房进了机房之后才是 Java 后端要关心的——应用自身的健康检查、优雅下线、连接池、JVM DNS 缓存、服务间调用的机房亲和。下面分三层讲配置。1. DNS 层配置云厂商控制台以阿里云解析 / DNSPod 为例核心是配分线路解析记录配置示意域名www.example.com主机记录记录类型线路记录值TTLwwwA默认兜底120.92.10.1北京机房 VIP60wwwA联通120.92.10.1北京机房联通 VIP60wwwA电信14.215.10.1深圳机房电信 VIP60wwwA移动14.215.10.2深圳机房移动 VIP60wwwA北方省份120.92.10.1北京 VIP60wwwA南方省份14.215.10.1深圳 VIP60关键配置项TTL容灾域名设60s普通域名600s。要做秒级切换前先按预降 TTL的 SOP 操作见第三节。健康检查 / 故障切换部分云解析支持对解析值做 HTTP/TCP 健康检查VIP 不可达时自动切到备用线路。这是 DNS 层能做的最主动的容灾建议开启。权重灰度时用例如北京 80 / 深圳 20 做新机房灰度。兜底线路默认必配。任何未匹配的线路都走默认否则部分用户解析不到。注意DNS 解析的记录值通常不是 Java 实例 IP而是机房前置负载均衡的VIPLVS/HAProxy 的虚 IP。VIP 背后才是 Nginx → Java。2. 机房内 Nginx 配置Java 前面的七层DNS 把流量引到机房 VIP 后Nginx 负责分发到本机房的 Java 实例并做健康检查和优雅摘除upstream java_order { # 本机房 Java 实例 server 10.0.1.11:8080 max_fails2 fail_timeout10s; server 10.0.1.12:8080 max_fails2 fail_timeout10s; server 10.0.1.13:8080 max_fails2 fail_timeout10s; } server { listen 80; server_name www.example.com; location /api/ { proxy_pass http://java_order; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 健康检查被动模式连续 2 次失败摘除 10s proxy_next_upstream error timeout http_502 http_503 http_504; proxy_connect_timeout 2s; proxy_read_timeout 10s; } }配合 Spring Boot Actuator 暴露健康检查端点让 Nginx/负载均衡探活# Spring Boot application.ymlmanagement:endpoint:health:probes:enabled:true# 暴露 liveness/readinessshow-details:alwaysendpoints:web:exposure:include:health,info,prometheushealth:livenessstate:enabled:true# /health/livenessreadinessstate:enabled:true# /health/readinessserver:port:8080shutdown:graceful# 优雅停机spring:lifecycle:timeout-per-shutdown-phase:30s优雅下线流程发版/摘机不丢请求1. readiness 探针置为 OUT_OF_SERVICE或 Nginx -s reload 摘掉 upstream 2. Nginx 不再往该实例转发新请求 3. 等待在途请求处理完最多等 timeout-per-shutdown-phase 4. kill 应用进程3. Java 应用层配置与 DNS 负载均衡直接相关这是 Java 开发最容易踩坑、也最该注意的部分。(1) JVM DNS 缓存 —— 必改JVM 默认对 DNS 解析结果缓存 30 秒networkaddress.cache.ttl老版本甚至永久缓存。如果你的 Java 应用作为客户端去调别的域名比如调外部 API、跨机房调用另一个域DNS 改了 IP 但 JVM 还用旧的。# $JAVA_HOME/conf/security/java.security # 缩短 JVM DNS 缓存配合短 TTL 生效 networkaddress.cache.ttl10 networkaddress.cache.negative.ttl0或在启动参数指定-Dnetworkaddress.cache.ttl10 -Dnetworkaddress.cache.negative.ttl0注意这个只影响Java 主动发起的对外域名解析不影响进入本应用的请求进来时已经被 Nginx 转发跟 DNS 无关。(2) HTTP 客户端配置 —— 多 IP、重试、连接池Java 调用下游服务尤其跨机房调用service-b.example.com时要配置连接池复用连接但不要把连接永久绑死在某个 IP否则 DNS 更新不生效。连接超时 读超时 重试某 IP 不可达自动切下一个。TTL/keep-alive定期重建连接让客户端重新解析 DNS 拿到新 IP。OkHttp 示例ConnectionPoolpoolnewConnectionPool(50,// 最大空闲连接5,// 空闲存活 5 分钟TimeUnit.MINUTES);OkHttpClientclientnewOkHttpClient.Builder().connectionPool(pool).connectTimeout(2,TimeUnit.SECONDS).readTimeout(5,TimeUnit.SECONDS).retryOnConnectionFailure(true)// 连接失败重试.dns(newDns(){// 自定义 DNS可接 HTTPDNSOverridepublicListInetAddresslookup(Stringhostname){// 可换成 HTTPDNS 解析返回多个 IPreturnDns.SYSTEM.lookup(hostname);}}).build();Apache HttpClient 5 礰示例关键连接复用但要定期刷新 DNSPoolingHttpClientConnectionManagercmnewPoolingHttpClientConnectionManager(// 关键定期让连接池里的路由失效强制重新解析 DNSRegistryBuilder.ConnectionSocketFactorycreate().register(http,PlainConnectionSocketFactory.getSocketFactory()).build(),null,null,30,TimeUnit.SECONDS// 连接存活 30s 后失效重新解析 DNS);cm.setMaxTotal(200);cm.setDefaultMaxPerRoute(50);CloseableHttpClientclientHttpClients.custom().setConnectionManager(cm).setRetryStrategy(newDefaultHttpRequestRetryStrategy(3,TimeValue.ofSeconds(1))).build();核心陷阱很多团队用 HttpClient 的连接池长连接 keep-aliveDNS 改了 IP 但连接还连着旧 IP切流根本不生效。必须让连接定期重建设置连接存活时间或 idle 时间让 JVM 重新解析。(3) 服务间调用 —— 注册中心 机房亲和Spring Cloud 项目里Java 服务之间调用通常走注册中心Nacos/Eureka而不是走域名 DNS。这时机房亲和是关键spring:cloud:nacos:discovery:server-addr:nacos.example.com:8848# 跨机房调用优先同机房避免跨机房 RTT# 注册时带上机房标签metadata:region:beijing# 本实例机房标识# 配置 prefer-same-zone同机房实例优先配合 LoadBalancer 的过滤策略同机房优先ConfigurationpublicclassSameZoneFirstConfig{BeanpublicReactorLoadBalancerExchangeFilterFunction?lbFilter(LoadBalancerClientFactoryfactory){returnnewReactorLoadBalancerExchangeFilterFunction(factory,newSameZonePreferredServiceInstanceListSupplier());}}原则入口流量靠 DNS 分机房机房内服务调用靠注册中心做同机房亲和。不要让北京机房的 A 服务去调深圳机房的 B 服务除非为了容灾否则延迟和跨机房带宽成本很高。(4) 无状态化 —— DNS 负载均衡的前提DNS 负载均衡以及它背后的多机房要求 Java 应用无状态Session 不要放本地内存用 Redis/分布式 Session否则用户第二次请求被 DNS 解析到另一个机房Session 丢失。文件/缓存不要放本地对象存储OSS/S3 Redis别写本地磁盘。定时任务加分布式锁多机房同时跑定时任务会重复执行用分布式锁Redis/ZK保证只跑一个。// 定时任务加分布式锁避免多机房重复执行Scheduled(cron0 0 2 * * ?)publicvoiddailyReport(){StringlockKeyjob:daily-report;booleanlockedredissonClient.getLock(lockKey).tryLock(0,30,TimeUnit.MINUTES);if(!locked)return;// 其他机房/实例已拿到跳过try{// 执行业务}finally{redissonClient.getLock(lockKey).unlock();}}4. 端到端切换流程示例机房故障假设北京机房整体故障完整流程1. 监控告警北京 VIP 健康检查失败 / Java 实例大量 503 2. DNS 层控制台把 www.example.com 的默认/联通/北方线路 从 120.92.10.1北京 VIP切到 14.215.10.1深圳 VIP 或开启自动故障切换云解析自动摘 IP 3. DNS 缓存逐渐过期TTL 60s新解析请求拿到深圳 VIP 4. 深圳机房 Nginx Java 承接原北京流量 前提深圳机房容量已按扛全量规划异地多活 5. JVM DNS 缓存10s刷新后Java 客户端调下游也走深圳 6. 数据层北京机房写不了的数据深圳接管写入多活数据同步方案 7. 北京恢复后反向切回灰度回切分批 5%→20%→100%5. 配置清单速查层配置项关键值DNSTTL容灾域 60s普通 600sDNS分线路默认兜底 联通/电信/移动 南北DNS健康检查开启故障自动摘 IPNginxupstream 健康检查max_fails2 fail_timeout10sNginxproxy_next_upstreamerror timeout 502 503 504Spring Bootreadiness/livenessactuator health probesSpring Bootgraceful shutdownserver.shutdowngracefulJVMDNS 缓存networkaddress.cache.ttl10OkHttp/HC连接定期重建连接存活 30s避免 DNS 不刷新注册中心机房亲和同机房实例优先应用无状态化Session/缓存/文件外置定时任务加锁七、总结问题答案DNS 负载均衡的本质同一域名按来源返回不同 IP把用户调度到不同机房一般公司会用吗门槛极低有域名、用云解析就在用深浅有别全套 HTTPDNS/Anycast 才是大厂典型场景就近接入、运营商分流、异地容灾、灰度发布、CDN 调度、多机房扛峰值、租户隔离带来什么降延迟、避跨网、横向扩容、机房容灾、灰度可控、成本低、抗量大是否必须搭配异地多活不是必须但要做真正容灾就必须否则只是分流不是容灾更新不及时怎么解决短 TTL 切换前预降 TTL 新旧 IP 共存 客户端多 IP 重试 HTTPDNS 治本 Anycast 兜底缓存一般多久静态 1h~1d普通业务 10~30min容灾切换 60~120s但运营商可能不遵守 TTL扩展性差对谁做定制对单用户、机房实时状态、业务语义、容灾策略、成本做调度DNS 拿不到这些上下文怎么补扩展性叠加自研 GSLB / HTTPDNS / 业务网关 / 服务网格逐层细化调度粒度搭配 Java 后端怎么用DNS 分机房→VIP→Nginx→Java必改 JVM DNS 缓存、连接池定期刷新、服务同机房亲和、应用无状态化核心认知DNS 负载均衡是入口最上游、覆盖最广、但最粗的一层调度。它适合做地域/运营商级的大颗粒分流所有精准、实时、业务相关的调度都不该指望它而要在它之上再叠控制面。 DNS负载均衡详解
DNS负载均衡详解DNS 负载均衡是最上游的一层负载均衡它工作在域名解析阶段让同一个域名在不同地区、不同运营商解析出不同的 IP从而把用户就近调度到合适的机房。它的优点是简单、天然抗流量、覆盖广缺点是生效慢缓存长和扩展性差控制权在域名商。本文围绕这两个缺点展开。一、DNS 负载均衡是怎么工作的1. 正常 DNS 解析流程回顾用户访问www.baidu.com浏览器先问本地 DNS通常由运营商提供LDNS/Recursive DNS浏览器 → 本地 DNS运营商递归解析器→ 根 DNS → 顶级域(.com) DNS → 权威 DNSbaidu 自己的权威 DNS 返回一个 A 记录IP 地址浏览器拿到 IP 后再发起 HTTP 请求。2. DNS 负载均衡的核心智能解析普通 DNS 对所有查询返回同一个 IP。DNS 负载均衡也叫智能 DNS、GSLB 的 DNS 调度方式则根据请求来源返回不同 IPwww.baidu.com │ ┌────────┴────────┐ │ 权威 DNS智能 │ ← 根据来源 EDNS-Client-Subnet / 来源 IP 段判断 └────────┬────────┘ ┌──────────┼──────────┐ ▼ ▼ 北方用户 南方用户 返回 61.135.165.224 返回 14.215.177.38 北京机房 IP 深圳机房 IP判断依据主要有两种请求来源 IP权威 DNS 能看到的是运营商递归解析器LDNS的出口 IP而不是用户真实 IP。所以北方用户更准确的说法是用北方 LDNS 的用户。EDNS-Client-SubnetECS协议扩展递归解析器会把用户真实网段塞进请求里传给权威 DNS调度更精准。但不是所有递归解析器都支持 ECS。返回的不同 IP可以是不同机房的真实 IP直连模式后端 IP 直接暴露不同机房的前置负载均衡器 IP更常见如 LVS/VIP后端再做多级负载均衡3. 它解决什么问题就近接入北方用户走北京机房延迟低南方用户走深圳机房。运营商分流联通用户走联通机房电信用户走电信机房避免跨网绕行跨网延迟高、丢包多。容灾切换某机房整体故障把该机房的 IP 从 DNS 摘掉新解析的流量自动到其他机房。无限扩展入口DNS 层扛的是解析量单机房扛不住就多挂几个机房 IP。关键认知DNS 负载均衡是调度层不是真正的流量转发层。它只决定这次解析把谁引向哪个机房后续的流量分发还要靠机房内部的 LVS/Nginx 等。可以把它理解为指路牌。二、用 DNS 负载均衡是不是一定要搭配异地多活不是必须但绝大多数生产场景会搭配使用。要分开看两个概念1. DNS 负载均衡 ≠ 异地多活DNS 负载均衡一种流量调度手段把用户分到不同 IP。异地多活一种架构形态多个异地机房同时对外提供服务、且数据层面能独立承载完整业务数据要同步/复制故障时能接管。只有 DNS、没有异地多活也是成立的——例如多机房只是冷备/热备主机房扛流量备机房空转DNS 只指向主。这时 DNS 不做分流只做故障切换。多机房是同地多机房都在同城DNS 分流只是分摊入口压力谈不上异地。CDN 场景DNS 把图片/静态资源解析到边缘节点这叫 CDN 调度也不算异地多活。2. 什么时候必须搭配异地多活当你的目标满足以下任意一条DNS 负载均衡就需要建立在异地多活之上才有意义目标为什么需要异地多活单机房宕机后业务不能停备机房必须能独立跑通完整业务否则 DNS 切过去也是 500要求地域级容灾整城市断网/断电必须异地同机房不行要求就近写入低延迟写多活意味着每个机房都能写数据双向同步流量超过单机房物理上限多机房分担且每个机房都要能扛全量或按比例3. 只做 DNS 不做多活会发生什么典型翻车场景DNS 把北方用户指向北京机房北京机房挂了DNS 摘掉北京 IP所有用户解析到深圳机房。但深圳机房数据没有北京的最新写入 → 业务数据不一致容量没规划到扛全量 → 雪崩没有对应的服务配置/缓存预热 → 降级所以异地多活是 DNS 负载均衡能真正容灾的前提。没有多活DNS 负载均衡只是分流不是容灾。一句话总结DNS 负载均衡负责指路异地多活负责路那头真的有完整的服务在跑。指路很准但目的地是空城等于没指。三、缺点一更新不及时 —— 缓存多久怎么解决1. 为什么会更新不及时DNS 是一个层层缓存的系统缓存粒度很粗浏览器 DNS 缓存 → 操作系统 DNS 缩存 → 本地路由器 → 运营商 LDNS递归解析器→ 权威 DNS你修改的是**最末端权威 DNS**的记录但中间每一层都缓存着旧值。只要缓存没过期用户解析出来的还是旧 IP。2. 缓存时间一般多久 —— TTL缓存时长由 DNS 记录的TTLTime To Live决定单位秒。常见取值场景典型 TTL说明静态/CDN 域名3600s1 小时甚至 86400s1 天IP 几乎不变长 TTL 减少权威压力普通业务域名600s ~ 1800s10~30 分钟兼顾稳定与切换速度需要快速容灾切换60s ~ 120s短 TTL牺牲权威压力换切换速度极端秒级切换30s 以下已接近 DNS 协议极限且非自己能完全控制关键陷阱TTL 只对你自己权威 DNS 返回的那条记录有效对以下两层无效运营商 LDNS 不一定遵守 TTL部分运营商为了省解析量会把短 TTL 强行拉长比如把 60s 改成 600s 甚至更长这你完全管不到。LDNS 之上还有各级缓存用户本机、家用路由器也可能缓存尤其一些奇葩路由器。应用层自己缓存JVM 的InetAddress默认缓存 30 秒networkaddress.cache.ttl但有的框架/连接池会永久缓存解析结果改了 DNS 也不重连。所以**修改 DNS 后多久全网生效的真实答案大多数用户在 1 个 TTL 周期内刷新但总有长尾用户可能持续几小时甚至几天还在用旧 IP**。这就是更新不及时的本质。3. 怎么解决 / 缓解按治标 → 治本排列(1) 缩短 TTL —— 最基础但有代价把容灾域名的 TTL 调到 60s 级别。代价权威 DNS 查询量飙升缓存短了LDNS 更频繁回源需要权威 DNS 抗得住。而且对不遵守 TTL 的运营商无效。(2) 预先降低 TTL切换前的标准动作切换前 1~2 个 TTL 周期就把 TTL 调小等旧长 TTL 过期后再做变更。这是 SRE 切流量的标准 SOPT0 : 把 TTL 从 1800s 调到 60s T1800 : 旧的长 TTL 已全部过期全网都是 60s 的记录 T1800 : 此时修改 IP最多 60s 内大部分用户生效(3) 双 IP / 多 IP 并存新旧共存过渡修改不是摘旧加新而是先加新后摘旧新旧机房 IP同时返回给用户轮询/随机。观察新机房流量逐步上涨、旧机房流量下降稳定后再把旧 IP 摘掉。这样即使有用户缓存了旧 IP旧机房还在服务不会直接失败。这是生产里最常用、最稳的切换姿势。(4) 应用层配合客户端重试 / 多 IP 连接HTTP 客户端配置多个 IP连接失败自动切换到下一个OkHttp、curl --resolve多 IP、gRPC 多地址。移动端 SDK 自带降级DNS 解析失败或连接超时走 HTTPDNS 或硬编码备用 IP 列表。(5) HTTPDNS —— 绕过系统 DNS 的治本方案这是大厂阿里、腾讯、HTTPDNS 厂商对DNS 缓存不可控的根本对策客户端不走系统 DNS而是通过 HTTP 请求一个自建的 DNS 调度服务。调度服务直接拿到用户真实 IP 业务上下文返回最优 IP。客户端自己控制缓存时长通常 30s~60s且可被服务端主动推送失效。优点精准用户真实 IP不是 LDNS 出口、可控TTL 完全自定、生效快、能防 DNS 劫持。代价要自建调度服务、客户端要改造、只覆盖自家 App网页/第三方调用方覆盖不到。典型组合公网用 DNS 负载均衡做广覆盖自家 App 用 HTTPDNS 做精准调度和秒级切换。(6) 流量层兜底Anycast / BGP 切换Anycast同一个 IP 在多个机房 BGP 播出网络层自动把流量路由到最近的机房。改的不是 DNS是路由切换在网络层完成几乎实时。DNS 层 IP 不变缓存不缓存都无所谓。BGP 路由切换某机房故障在 BGP 层把该机房 IP 撤回流量自动绕到其他机房。比 DNS 快得多秒级。代价要自网段、要和运营商谈 BGP成本高通常只有大厂/金融/CDN 厂商用。四、缺点二扩展性差 —— 对谁做什么定制化1. 为什么扩展性差DNS 负载均衡的调度逻辑在域名商/权威 DNS 服务商手里阿里云解析、DNSPod、AWS Route53 等。你只能配几条规则按地区/运营商分线路返回按权重返回不同 IP 的比例健康检查 故障切换部分厂商支持但你想在调度时结合业务语义做更细的判断——做不到因为 DNS 协议本身只是问域名→答 IP没有业务上下文。2. 对谁做什么定制化 —— 业务里真实需要的能力下面列的是生产里真实会想做、但纯 DNS 做不到、需要自研调度层HTTPDNS / GSLB 控制面 / 服务网格 / 网关来补的定制化能力。(1) 针对单个用户的调度按用户 ID 灰度某个用户是 A/B 实验组永远解析到灰度机房DNS 拿不到用户 ID做不到。VIP 用户专线高价值用户永远走高质量机房DNS 拿不到用户身份。按设备类型iOS / Android / 小程序分流到不同后端DNS 拿不到 User-Agent。DNS 在请求域名时拿到的只有来源 IP 网段没有用户身份、没有业务标签。这是它扩展性差的根本原因。(2) 针对后端机房实时状态的调度按机房实时负载调度某机房 CPU 飙到 90%少分点流量过去。DNS 健康检查只有通/不通拿不到负载指标。按机房剩余容量调度容量评估后按比例分流容量变了动态调整权重。DNS 厂商的权重是静态配置的不能随实时容量变。按机房依赖健康调度某机房依赖的下游MySQL/Redis/支付网关抖动主动降权。DNS 完全感知不到下游。(3) 针对业务语义的调度按接口粒度分流/order走订单机房/pay走支付机房/search走搜索机房。DNS 是域名级一个域名只能指向一组 IP分不了接口。按请求内容路由大文件下载走 CDN/对象存储小请求走计算机房读请求走读库机房写请求走主库机房。DNS 拿不到请求内容。会话保持Session Stickiness同一用户的请求始终落到同一机房本地缓存/会话命中。DNS 只在解析时调度连接复用后会话漂移不可控。预热/压测流量隔离压测流量打标记后路由到影子机房不影响真实业务。DNS 拿不到流量标记。(4) 针对容灾切换策略的定制分级容灾机房降级≠摘掉而是先降权 50%、再摘掉。DNS 只有摘/不摘部分厂商支持降权但策略固定。爆炸半径控制切流量要分批5% → 20% → 50% → 100%每批观察指标。DNS 厂商的切换是瞬时的分批要靠自研控制面。降级联动机房故障时不仅要切流量还要触发下游限流、熔断、读旧数据等业务降级。DNS 做不到业务联动。(5) 针对成本的调度按计费档位调度某机房流量超额计费贵了把流量挪到便宜机房。DNS 厂商不知道你的计费。闲时忙时调度白天高峰多机房分担深夜单机房收口省钱。DNS 没有定时动态调权的通用能力。3. 怎么补这个扩展性差演进路径一般是纯 DNS 负载均衡域名商 │ 能力不够 ▼ DNS 自研 GSLB 控制面 自研权威 DNS 健康检查 容量调度 切流 SOP │ 要更精准/秒级 ▼ HTTPDNSApp 端绕过系统 DNS │ 要细到接口/会话/内容 ▼ 业务网关 / 服务网格Spring Cloud Gateway、Envoy、API Gateway 按 URL、Header、用户、负载做细粒度路由每一层补的是上一层做不到的能力层调度粒度典型能力DNS 负载均衡地区/运营商 域名就近、运营商分流、粗容灾自研 GSLB机房 容量 健康动态权重、分级容灾、分批切流HTTPDNS单用户 真实 IP秒级生效、防劫持、用户级灰度业务网关/网格接口/Header/会话内容路由、会话保持、灰度发布一句话总结DNS 负载均衡是大喇叭喊方向扩展性差是因为它喊的时候只知道你是哪来的不知道你是谁、要干啥、后端忙不忙。要补这些业务定制化能力必须叠加 GSLB / HTTPDNS / 网关这一层自研控制面。五、一般公司会使用吗典型业务场景与收益1. 门槛其实很低所以用得很普遍先纠正一个常见误解DNS 负载均衡不是大厂专属。不需要自建权威 DNS。你在阿里云解析、DNSPod、Cloudflare、AWS Route53 上配几条分线路/分地区记录就是在用 DNS 负载均衡控制台点几下就行免费或很便宜。不需要自网段、不需要 BGP。那是 Anycast/网络层切流才需要的DNS 层只要域名解析服务支持智能解析/线路分流即可。所以严格说绝大多数有公网域名的公司都在用 DNS 这一层做调度区别只在于用得多深公司类型用 DNS 负载均衡到什么程度个人/小站点单机房DNS 只指向一个 IP不分流——严格说不算负载均衡只是解析中小公司单机房DNS 指向机房前置 LVS/Nginx 的 VIPDNS 层不分流靠机房内负载均衡多机房/多地域公司正经用 DNS 负载均衡按地区/运营商分线路返回不同机房 IP大厂/CDN/金融DNS 负载均衡 自研 GSLB HTTPDNS Anycast 全套叠加结论DNS 负载均衡是性价比最高的入口调度层门槛极低几乎人人用得起真正有门槛的是它上面叠加的 HTTPDNS / Anycast / 自研 GSLB。2. 典型业务场景场景一地域就近接入最经典业务电商、视频、资讯、搜索等面向全国用户的服务。做法北方用户解析到北京机房南方用户解析到深圳/广州机房。收益降低访问延迟跨地域 RTT 从几十毫秒降到几毫秒提升体验和转化率。场景二运营商分流解决跨网问题业务国内 To C 业务用户分布在电信/联通/移动各运营商。做法联通用户解析到联通机房 IP电信用户解析到电信机房 IP。收益避免跨网绕行跨网延迟高、丢包、成本贵这是国内特有的强需求。早期单机房用 BGP 多线也能解决但贵多机房 DNS 分流更经济。场景三异地容灾切换业务对可用性有要求的业务金融、支付、核心交易、SaaS。做法平时 DNS 分流到多机房某机房故障把该机房 IP 从 DNS 摘掉或降权新解析的流量自动到其他机房。收益机房级故障时业务不整体宕机。前提是异地多活否则切过去是空城见上文第二节。场景四灰度发布 / 蓝绿部署业务新版本上线要控制爆炸半径。做法DNS 配权重新版本机房先承接 10% 流量观察指标后逐步提到 50%、100%最后摘掉老机房。收益版本故障时影响面可控可快速回滚。注意 DNS 权重是解析比例由于缓存存在实际流量比例会有偏差需配合短 TTL。场景五CDN 调度最广泛的隐性使用业务图片、视频、静态资源、直播、大文件下载。做法资源域名解析到 CDN 厂商的调度系统由 CDN 再把用户引到最近的边缘节点。这本质就是 DNS 负载均衡。收益边缘节点扛静态流量源站压力骤降用户就近取内容。这是 DNS 负载均衡覆盖面最广的应用——几乎所有用 CDN 的公司都在用。场景六多机房容量分担业务流量超过单机房物理上限大促、秒杀、直播高峰。做法DNS 按权重把流量分到多个机房每个机房各扛一部分。收益横向扩容扛住峰值单机房不用无限堆机器。大促前临时调权重把流量多分给预备机房。场景七上下游/合作方对接业务开放平台、第三方接入、多租户 SaaS。做法不同租户/合作方解析到不同机房或不同环境做物理隔离。收益故障隔离 合规隔离如金融客户数据要求本地机房。3. 使用它能带来什么收益清单收益说明就近接入降延迟用户被引到最近机房RTT 显著降低体验直接提升跨网避免绕行国内多运营商场景下避免跨网高延迟和高成本横向扩容扛峰值多机房分担突破单机房容量天花板大促/秒杀刚需机房级容灾故障摘 IP 即可切流配合多活实现业务连续性灰度可控权重调度做版本/机房灰度爆炸半径小门槛低、成本极低不用自网段、不用 BGP云厂商控制台点点就能用覆盖广、抗量大DNS 层只扛解析量扛百万 QPS 解析毫无压力且天然支持任意客户端4. 反过来——它不适合做什么避免误用不能做会话保持DNS 调度只在解析时生效连接复用后会话会漂移。不能做精准/实时调度拿不到用户身份、机房实时负载、请求内容见第四节。不能做秒级切换受 TTL 和运营商缓存限制分钟级是常态。不适合做单接口粒度路由一个域名一组 IP分不了/api和/web。所以正确姿势是DNS 负载均衡做广覆盖的地域/运营商级大颗粒分流 粗容灾把它的低门槛、抗量、覆盖广用满精准、实时、业务相关的调度交给上层 GSLB/HTTPDNS/网关。六、如何搭配 Java 后端项目使用——流程与配置DNS 负载均衡是入口层Java 后端是业务层中间还要有机房前置负载均衡。完整链路是用户 │ 解析 www.example.com ▼ DNS 负载均衡云解析按地区/运营商分流 │ 返回北京机房 VIP 或 深圳机房 VIP ▼ 机房前置负载均衡LVS / HAProxy / NginxVIP │ 四层/七层转发 ▼ Nginx七层反向代理 健康检查 │ 转发到本机房内的 Java 实例 ▼ Java 应用集群Spring Boot 实例 × N 台 │ 服务间调用走注册中心Nacos/Eureka同机房优先 ▼ 数据层MySQL/Redis跨机房同步 异地多活认知DNS 只负责把用户引到哪个机房进了机房之后才是 Java 后端要关心的——应用自身的健康检查、优雅下线、连接池、JVM DNS 缓存、服务间调用的机房亲和。下面分三层讲配置。1. DNS 层配置云厂商控制台以阿里云解析 / DNSPod 为例核心是配分线路解析记录配置示意域名www.example.com主机记录记录类型线路记录值TTLwwwA默认兜底120.92.10.1北京机房 VIP60wwwA联通120.92.10.1北京机房联通 VIP60wwwA电信14.215.10.1深圳机房电信 VIP60wwwA移动14.215.10.2深圳机房移动 VIP60wwwA北方省份120.92.10.1北京 VIP60wwwA南方省份14.215.10.1深圳 VIP60关键配置项TTL容灾域名设60s普通域名600s。要做秒级切换前先按预降 TTL的 SOP 操作见第三节。健康检查 / 故障切换部分云解析支持对解析值做 HTTP/TCP 健康检查VIP 不可达时自动切到备用线路。这是 DNS 层能做的最主动的容灾建议开启。权重灰度时用例如北京 80 / 深圳 20 做新机房灰度。兜底线路默认必配。任何未匹配的线路都走默认否则部分用户解析不到。注意DNS 解析的记录值通常不是 Java 实例 IP而是机房前置负载均衡的VIPLVS/HAProxy 的虚 IP。VIP 背后才是 Nginx → Java。2. 机房内 Nginx 配置Java 前面的七层DNS 把流量引到机房 VIP 后Nginx 负责分发到本机房的 Java 实例并做健康检查和优雅摘除upstream java_order { # 本机房 Java 实例 server 10.0.1.11:8080 max_fails2 fail_timeout10s; server 10.0.1.12:8080 max_fails2 fail_timeout10s; server 10.0.1.13:8080 max_fails2 fail_timeout10s; } server { listen 80; server_name www.example.com; location /api/ { proxy_pass http://java_order; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 健康检查被动模式连续 2 次失败摘除 10s proxy_next_upstream error timeout http_502 http_503 http_504; proxy_connect_timeout 2s; proxy_read_timeout 10s; } }配合 Spring Boot Actuator 暴露健康检查端点让 Nginx/负载均衡探活# Spring Boot application.ymlmanagement:endpoint:health:probes:enabled:true# 暴露 liveness/readinessshow-details:alwaysendpoints:web:exposure:include:health,info,prometheushealth:livenessstate:enabled:true# /health/livenessreadinessstate:enabled:true# /health/readinessserver:port:8080shutdown:graceful# 优雅停机spring:lifecycle:timeout-per-shutdown-phase:30s优雅下线流程发版/摘机不丢请求1. readiness 探针置为 OUT_OF_SERVICE或 Nginx -s reload 摘掉 upstream 2. Nginx 不再往该实例转发新请求 3. 等待在途请求处理完最多等 timeout-per-shutdown-phase 4. kill 应用进程3. Java 应用层配置与 DNS 负载均衡直接相关这是 Java 开发最容易踩坑、也最该注意的部分。(1) JVM DNS 缓存 —— 必改JVM 默认对 DNS 解析结果缓存 30 秒networkaddress.cache.ttl老版本甚至永久缓存。如果你的 Java 应用作为客户端去调别的域名比如调外部 API、跨机房调用另一个域DNS 改了 IP 但 JVM 还用旧的。# $JAVA_HOME/conf/security/java.security # 缩短 JVM DNS 缓存配合短 TTL 生效 networkaddress.cache.ttl10 networkaddress.cache.negative.ttl0或在启动参数指定-Dnetworkaddress.cache.ttl10 -Dnetworkaddress.cache.negative.ttl0注意这个只影响Java 主动发起的对外域名解析不影响进入本应用的请求进来时已经被 Nginx 转发跟 DNS 无关。(2) HTTP 客户端配置 —— 多 IP、重试、连接池Java 调用下游服务尤其跨机房调用service-b.example.com时要配置连接池复用连接但不要把连接永久绑死在某个 IP否则 DNS 更新不生效。连接超时 读超时 重试某 IP 不可达自动切下一个。TTL/keep-alive定期重建连接让客户端重新解析 DNS 拿到新 IP。OkHttp 示例ConnectionPoolpoolnewConnectionPool(50,// 最大空闲连接5,// 空闲存活 5 分钟TimeUnit.MINUTES);OkHttpClientclientnewOkHttpClient.Builder().connectionPool(pool).connectTimeout(2,TimeUnit.SECONDS).readTimeout(5,TimeUnit.SECONDS).retryOnConnectionFailure(true)// 连接失败重试.dns(newDns(){// 自定义 DNS可接 HTTPDNSOverridepublicListInetAddresslookup(Stringhostname){// 可换成 HTTPDNS 解析返回多个 IPreturnDns.SYSTEM.lookup(hostname);}}).build();Apache HttpClient 5 礰示例关键连接复用但要定期刷新 DNSPoolingHttpClientConnectionManagercmnewPoolingHttpClientConnectionManager(// 关键定期让连接池里的路由失效强制重新解析 DNSRegistryBuilder.ConnectionSocketFactorycreate().register(http,PlainConnectionSocketFactory.getSocketFactory()).build(),null,null,30,TimeUnit.SECONDS// 连接存活 30s 后失效重新解析 DNS);cm.setMaxTotal(200);cm.setDefaultMaxPerRoute(50);CloseableHttpClientclientHttpClients.custom().setConnectionManager(cm).setRetryStrategy(newDefaultHttpRequestRetryStrategy(3,TimeValue.ofSeconds(1))).build();核心陷阱很多团队用 HttpClient 的连接池长连接 keep-aliveDNS 改了 IP 但连接还连着旧 IP切流根本不生效。必须让连接定期重建设置连接存活时间或 idle 时间让 JVM 重新解析。(3) 服务间调用 —— 注册中心 机房亲和Spring Cloud 项目里Java 服务之间调用通常走注册中心Nacos/Eureka而不是走域名 DNS。这时机房亲和是关键spring:cloud:nacos:discovery:server-addr:nacos.example.com:8848# 跨机房调用优先同机房避免跨机房 RTT# 注册时带上机房标签metadata:region:beijing# 本实例机房标识# 配置 prefer-same-zone同机房实例优先配合 LoadBalancer 的过滤策略同机房优先ConfigurationpublicclassSameZoneFirstConfig{BeanpublicReactorLoadBalancerExchangeFilterFunction?lbFilter(LoadBalancerClientFactoryfactory){returnnewReactorLoadBalancerExchangeFilterFunction(factory,newSameZonePreferredServiceInstanceListSupplier());}}原则入口流量靠 DNS 分机房机房内服务调用靠注册中心做同机房亲和。不要让北京机房的 A 服务去调深圳机房的 B 服务除非为了容灾否则延迟和跨机房带宽成本很高。(4) 无状态化 —— DNS 负载均衡的前提DNS 负载均衡以及它背后的多机房要求 Java 应用无状态Session 不要放本地内存用 Redis/分布式 Session否则用户第二次请求被 DNS 解析到另一个机房Session 丢失。文件/缓存不要放本地对象存储OSS/S3 Redis别写本地磁盘。定时任务加分布式锁多机房同时跑定时任务会重复执行用分布式锁Redis/ZK保证只跑一个。// 定时任务加分布式锁避免多机房重复执行Scheduled(cron0 0 2 * * ?)publicvoiddailyReport(){StringlockKeyjob:daily-report;booleanlockedredissonClient.getLock(lockKey).tryLock(0,30,TimeUnit.MINUTES);if(!locked)return;// 其他机房/实例已拿到跳过try{// 执行业务}finally{redissonClient.getLock(lockKey).unlock();}}4. 端到端切换流程示例机房故障假设北京机房整体故障完整流程1. 监控告警北京 VIP 健康检查失败 / Java 实例大量 503 2. DNS 层控制台把 www.example.com 的默认/联通/北方线路 从 120.92.10.1北京 VIP切到 14.215.10.1深圳 VIP 或开启自动故障切换云解析自动摘 IP 3. DNS 缓存逐渐过期TTL 60s新解析请求拿到深圳 VIP 4. 深圳机房 Nginx Java 承接原北京流量 前提深圳机房容量已按扛全量规划异地多活 5. JVM DNS 缓存10s刷新后Java 客户端调下游也走深圳 6. 数据层北京机房写不了的数据深圳接管写入多活数据同步方案 7. 北京恢复后反向切回灰度回切分批 5%→20%→100%5. 配置清单速查层配置项关键值DNSTTL容灾域 60s普通 600sDNS分线路默认兜底 联通/电信/移动 南北DNS健康检查开启故障自动摘 IPNginxupstream 健康检查max_fails2 fail_timeout10sNginxproxy_next_upstreamerror timeout 502 503 504Spring Bootreadiness/livenessactuator health probesSpring Bootgraceful shutdownserver.shutdowngracefulJVMDNS 缓存networkaddress.cache.ttl10OkHttp/HC连接定期重建连接存活 30s避免 DNS 不刷新注册中心机房亲和同机房实例优先应用无状态化Session/缓存/文件外置定时任务加锁七、总结问题答案DNS 负载均衡的本质同一域名按来源返回不同 IP把用户调度到不同机房一般公司会用吗门槛极低有域名、用云解析就在用深浅有别全套 HTTPDNS/Anycast 才是大厂典型场景就近接入、运营商分流、异地容灾、灰度发布、CDN 调度、多机房扛峰值、租户隔离带来什么降延迟、避跨网、横向扩容、机房容灾、灰度可控、成本低、抗量大是否必须搭配异地多活不是必须但要做真正容灾就必须否则只是分流不是容灾更新不及时怎么解决短 TTL 切换前预降 TTL 新旧 IP 共存 客户端多 IP 重试 HTTPDNS 治本 Anycast 兜底缓存一般多久静态 1h~1d普通业务 10~30min容灾切换 60~120s但运营商可能不遵守 TTL扩展性差对谁做定制对单用户、机房实时状态、业务语义、容灾策略、成本做调度DNS 拿不到这些上下文怎么补扩展性叠加自研 GSLB / HTTPDNS / 业务网关 / 服务网格逐层细化调度粒度搭配 Java 后端怎么用DNS 分机房→VIP→Nginx→Java必改 JVM DNS 缓存、连接池定期刷新、服务同机房亲和、应用无状态化核心认知DNS 负载均衡是入口最上游、覆盖最广、但最粗的一层调度。它适合做地域/运营商级的大颗粒分流所有精准、实时、业务相关的调度都不该指望它而要在它之上再叠控制面。