负载均衡器多租户子域名路由的DNS通配符替代方案及经济实现方式咨询

碰到这种多租户子域名路由的配额限制问题确实头疼，尤其是当租户数量多、每个租户还有多个子域名前缀的时候，一个个建路由规则肯定不够用。结合GCP的服务特性，有几个经济且可行的方案可以解决你的问题：

方案一：利用URL Map的高级正则匹配（最直接的GCP原生方案） #

GCP的全局外部HTTP(S)负载均衡器其实支持通过高级匹配条件来用正则表达式匹配主机名，而不是只能用简单的后缀通配符。你之前尝试的login.*属于前缀通配，直接写在主机名字段里会报错，但用正则匹配就能实现：

• 在创建URL Map的路由规则时，不要直接填主机名，而是选择添加匹配条件，然后选择主机名作为匹配类型，再选择匹配正则表达式。
• 比如，要匹配所有以login.开头的子域名（包括login.mytenant1.com、login.topic.mytenant2.net这类多级子域名），可以写正则：^login\..*$
• 同理，针对login.topic.开头的子域名，正则写^login\.topic\..*$
  这样一来，每个子域名前缀只需要一条路由规则，不管你有多少租户，都只占用很少的配额（比如5个前缀就只需要5条规则），完全在50的配额范围内。

方案二：用NGINX作为反向代理层（灵活度更高） #

如果原生的LB匹配规则还是满足不了你的需求，或者你需要更复杂的路由逻辑，可以在LB后面加一层NGINX反向代理：

• 只需要创建一个全局外部LB，把所有流量都转发到一个NGINX实例组（可以用低成本的GCE虚拟机，或者用Cloud Run部署NGINX，按需付费更经济）。
• 在NGINX的配置文件里，用正则匹配主机名来分发流量，示例配置如下：

http {
    # 定义后端服务池
    upstream login_backend {
        server 10.0.0.1:80;
        server 10.0.0.2:80;
    }

    upstream login_topic_backend {
        server 10.0.0.3:80;
        server 10.0.0.4:80;
    }

    # 匹配所有以login.开头的子域名
    server {
        listen 80;
        server_name ~^login\.(.*)$;
        proxy_pass http://login_backend;
        proxy_set_header Host $host;
    }

    # 匹配所有以login.topic.开头的子域名
    server {
        listen 80;
        server_name ~^login\.topic\.(.*)$;
        proxy_pass http://login_topic_backend;
        proxy_set_header Host $host;
    }
}

这种方式的好处是路由逻辑完全由你掌控，而且只需要一个LB，不会占用额外的路由规则配额，成本也很低——GCE实例可以选预付费或者按需模式，Cloud Run更是按请求计费，适合流量波动大的场景。

方案三：结合Cloud DNS的通配符记录简化配置（辅助优化） #

虽然这不是路由的核心方案，但可以配合上面的方案简化DNS配置工作：

• 对于每个租户的域名，你可以添加通配符DNS记录，比如*.mytenant1.com指向你的LB公网IP，这样不管是login.mytenant1.com还是其他子域名，都能自动解析到LB，不用一个个手动添加DNS记录。
• 如果你需要更精细的DNS控制，也可以只添加特定前缀的记录，但通配符记录能节省大量的重复配置工作。

备注：内容来源于stack exchange，提问作者Alexander Trauzzi