服务发现该不该继续绑死在 DNS 上？我的团队里至今吵不休

背景

我做了 10 年网络，从 Nginx upstream + keepalived VIP → 自建 ZooKeeper 注册中心 → Consul → K8s Service + CoreDNS → 云厂商 SLB，基本把这条路走了一遍。最近带一个 6 人团队做新业务线选型，服务发现这一项，组里 3 派立场基本打平，我索性把分歧摊开来，也想借广场听一听大家的取舍。

派 A：一切走 DNS。A/SRV 记录 + 一致性哈希（PowerDNS / 自建 Anycast + 客户端轮询），零依赖、跨语言、可观测路径短，团队里"能少一套组件就少一套"。

派 B：DNS 只承载"服务名 → 入口"，实例级发现走 push（gRPC Watch / xDS / Nacos）。理由是 DNS 的 TTL、客户端缓存、负缓存这些坑，做实例级发现就是定时炸弹。

派 C：K8s 原生 Service + Endpoints，跨集群再叠 service-mesh，DNS 只做"服务名"层，实例列表交给 xDS 推。

我踩过的坑（也大概是分歧的根源）

1. 客户端缓存是各家自己的：JDK 默认 30s、glibc 按 TTL 但受 nsswitch 影响、C++ HTTP 库各有实现，TTL=1 并不等于 1 秒刷新。
2. 负缓存更坑：服务下线，解析失败在部分客户端能缓存 5~30 分钟，故障窗口直接放大一个数量级。
3. DNS 天然不支持权重、长连接复用、健康摘除，真要做 LB 还得叠一层，等于"DNS 做了一半、应用补一半"。
4. 可观测性最弱：DNS 出错几乎没有 trace 上下文，排障靠 tcpdump + dig 人肉对齐。
5. 安全身份：mTLS / SPIFFE 需要实例级身份，DNS 只给得到"服务名"。

我的倾向

分层：入口层用 DNS + LB（稳定、可被任何客户端复用、故障域小）；服务间实例级发现走 push（Watch / xDS），不依赖客户端轮询 TTL；DNS 只承担"服务名 → 集群/入口"，不承担"实例列表"。核心依据是 TTL 语义的不可靠、客户端异构、可观测性弱、安全身份缺失这四条，全都指向 push 模型更稳。

想听大家聊的

1. 你们生产里的服务发现现在跑在哪一层？入口 / 实例 / 两者都是 DNS？
2. 有没有被 DNS 缓存 / 负缓存坑过？具体缓存了多久，最后怎么收口的（短 TTL？旁路？换 push？）
3. 跨集群 / 多云场景你们怎么选型？cilium / Linkerd / 自研？
4. K8s 集群外有在跑"非 DNS 实例级发现"的案例吗？效果如何，踩过什么坑？

欢迎贴可复现的配置片段、监控指标、故障时间线，比抽象的"我觉得 DNS 够用"更有帮助。