网站域名基础㉔域名与API网关 服务调用的寻址

网站域名㉔域名基础 域名与API网关 服务调用的寻址

从单体应用拆到微服务之后，域名的工作也变了。过去一个域名指向一台机器，现在一个域名要指向一整套会随时扩缩容的服务集群。域名从“网站的地址”变成了“服务的地址”。

写死 IP 的时代结束了

早期系统之间互相调用，图省事就把对方 IP 写在配置里。这在小规模下没事，一旦对端扩容、迁移、换机器，配置全得跟着改，改漏一处就是一个线上故障。域名解决的正是这个问题：调用方只认名字，名字背后换成哪台机器，由解析层决定。服务与实例就此解耦。

API 网关：一个域名收回所有入口

微服务多了以后，如果每个服务都暴露一个公网域名，外界看到的就是一片散乱。更常见的做法是设一道 API 网关，对外只留一个域名，比如 api.example.com。所有外部请求先到网关，由它完成鉴权、限流、熔断、日志、协议转换，再转发给内部的各个服务。

好处很直接：外部只面对一个入口，安全策略集中在一处；内部服务可以随意拆分重组，外界无感。域名在这里变成了“服务契约”的一部分——接口地址一旦公布，就不能随便改。

子域怎么划，边界就怎么定

网关定下来之后，通常会用子域来划分访问层级。api 给业务接口用，open 给开放平台用，admin 给内部管理后台用，internal 只在内网可达。用名字把“谁能访问”画出来，比在一堆 IP 白名单里做区分清晰得多。

更重要的是，子域划分本身就是一道安全边界。对外开放的接口和内部管理入口放在不同子域上，防火墙和访问策略可以按域名落地，误暴露的风险小得多。

集群内部的域名：Service 就是名字

外部靠域名寻址，内部其实也一样。容器编排环境里，一个服务注册进来，平台就给它分配一个集群内部可解析的名字，形如 svc-name.namespace.svc.cluster.local。服务之间互相调用，写的是这个名字，不是 IP——实例起起落落、副本增减，调用方完全不用知道。

这套机制本质上是把 DNS 搬进了集群内部：CoreDNS 之类的组件扮演了解析器的角色，服务注册信息就是它的“区文件”。域名思维在教育与工程两头的通用性，在这里体现得最明显。

多环境与灰度：用名字隔离

开发、测试、预发、生产，四套环境怎么不打架？最省事的办法就是各给一个域名——dev.api.example.com、test.api.example.com，环境和环境之间物理隔绝，谁也不会误连到谁。灰度发布也常按域名切：把一小部分流量的入口域名指到新版本集群，稳定了再逐步放大。

顺带一个成本细节：证书管几种域名

服务一多，子域就多，HTTPS 证书的数量跟着涨。这里有两种思路：泛域名证书，一张管住 *.example.com 下所有子域；多域名证书，一张只列实际需要的若干名字。前者省事但影响面大——私钥泄露等于全线失守；后者更收敛，但证书数量多、续期管理麻烦。规模不大时用泛域名求省心，核心业务单独买一张，是比较务实的折中。

域名在这里彻底变成了基础设施的一部分。下一篇换个数量级更大的对象——那些没有键盘、没有屏幕，却也需要一个名字的物联网设备。

本文收录于徐果萍文集《论持久站 网站域名》，徐果萍博客原创首发。