全局负载均衡按账户归属区域定向访问的可行性与实现方案咨询

该需求完全可行，是多Region区域化部署架构的常用落地能力，没有技术障碍。

具体实现流程 #

首次访问处理 #

用户首次请求被GSLB调度到就近接入点后，接入层完成账户归属地查询后执行两个动作：

• 给用户端写入全局生效的区域标识凭证，凭证作用域覆盖主根域名，保证所有接入节点都能读取
• 返回302重定向响应，将用户直接引导到归属区域的服务节点，后续请求默认访问归属区资源

后续访问处理 #

用户后续从任意区域发起访问时：

• 请求会自动携带之前写入的区域标识，边缘接入层/GSLB直接读取标识即可，不需要再查询账户归属地，直接转发/重定向到对应区域的服务节点
• 如果标识丢失/被清理，自动回退到首次访问的查询流程，不会影响服务可用性
• 如果用户账户办理过跨区迁移，归属区服务节点校验到标识不匹配后，直接更新用户端的区域标识即可，单次校验成本极低

可选缓存载体 #

按优先级从高到低排序：

• 端侧HttpOnly Cookie：优先选择的方案，设置domain=.yourdomain.com全局生效，所有子域名都可读取，自动随所有HTTP请求携带，前端无法篡改，安全性和兼容性最好
• 端侧LocalStorage + 自定义请求头：适合前后端分离的SPA应用，前端发起请求时主动在Header中添加X-Account-Region字段，需要提前配置跨域请求的Header放行规则
• 服务侧分布式缓存（如Redis）：作为端侧缓存失效的兜底方案，用用户UID为Key存储归属区域，端侧缓存丢失时只需要查一次Redis，不需要访问底层账户库，性能损耗可忽略
• CDN边缘节点缓存：如果使用了全球CDN服务，可以把UID和区域的映射缓存在边缘节点，TTL设为24~72小时，进一步降低回源查询的频率

内容的提问来源于stack exchange，提问作者button pusher