APNIC 将 RDAP 服务从单一悉尼节点扩展为新加坡、北弗吉尼亚三地多区域部署，利用 Cloudflare 动态流量调度实现全球就近接入，显著降低查询延迟并增强区域故障下的可用性。
多区域架构与流量调度：
APNIC 复用既有 rdap-ingressd 代理层，在 Cloudflare 负载均衡器上启用动态流量调度。每个 GKE 集群对应一个源池，HTTP 监控以合法 RDAP 查询探测健康度并采集各 PoP 到区域集群的 RTT 画像。请求自动路由至 RTT 最小的源池，悉尼集群作为兜底回退。Terraform 统一编排 Cloudflare 源池、监控与负载均衡器配置，实现基础设施即代码。
选址实测与成本权衡：
候选区域为东京、新加坡、北弗吉尼亚、伦敦加上既有悉尼。团队在四个新区域各部署临时 GKE 集群跑真实 RDAP 服务，借助 Terraform 与 FluxCD 托管的 HelmRelease 仓库快速拉起再拆除。Cloudflare RTT 画像机制从全球 PoP 采集往返时延，结合 GCP 计算资源单价差异，最终落子新加坡与北弗吉尼亚。原文未给出具体 RTT 数值与成本对比细节。
后续扩展计划：
APNIC 表示 2021 年将根据成本收益与设计权衡决定是否继续增加节点。当前三地部署已覆盖亚太与美东核心流量，架构具备水平扩展能力，新增区域仅需在 Terraform 中追加 GKE 集群与对应 Cloudflare 源池配置。
对运维工程师而言，该案例展示了如何把有状态查询服务通过 Kubernetes、GitOps 与全球负载均衡器组合成低延迟、高可用的多区域服务，且选址依赖实测而非经验猜测，可直接迁移至同类 WHOIS/RDAP 或 DNS 权威服务的云原生改造。
原文: APNIC Blog（2020-12-10）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog