如何仅将通知请求发送至Docker以降低自建站点的服务器负载？

完全可行，本质是轻量化的服务拆分，把通知相关的请求流量从主业务服务中剥离，避免通知请求占用主站的计算、数据库资源，具体落地可以参考如下逻辑：

• 单独开发只承载通知相关逻辑的轻量服务，不需要依赖主站的复杂业务组件，甚至可以不用Django，选用FastAPI、Gin这类更轻量的框架开发，资源占用率会低很多
• 把这个通知服务打包成Docker镜像单独部署，前端所有通知相关的请求直接指向该独立服务，和主站流量完全隔离
• 通知服务可以直接复用现有主站的通知相关数据库表、缓存实例，不需要额外做数据同步

需要注意两个核心点：

• 做好用户身份鉴权，可直接复用主站的Session、JWT校验逻辑，避免出现越权访问他人通知的问题
• 单独部署前优先给通知服务加缓存，降负载效果会比单纯做服务拆分更明显

你当前负载高的核心原因是每个页面都发起GET请求拉取通知的短轮询机制，比服务拆分优先级更高的优化方向如下：

• 把短轮询改成长轮询：前端发起请求后，如果服务端没有新通知就hold住请求不返回，直到有新通知或者到超时阈值（比如30秒）再返回，前端收到响应后再发起下一次请求，整体请求量可以降低90%以上
• 新增缓存层：把用户的未读通知数、最近通知列表存在Redis中，设置10~30秒的过期时间，所有通知请求优先查缓存，不需要每次都请求数据库，数据库压力会大幅降低
• 前端做请求频率限制：用户停留在站点内时，固定30秒/60秒才发起一次通知请求，不要每次切换页面都重复发起请求，间隔期内直接用本地缓存的通知数据展示即可
• 复用现有聊天能力做WebSocket推送：你已经自主实现了聊天功能，完全可以复用已有的长连接逻辑做通知推送，用户登录后只建立一次长连接，有新通知时服务端主动推送给前端，完全不需要前端主动发起拉取请求，是目前通知场景的最优实现方案
• 非核心场景降级：未登录用户直接不发起通知请求，只有登录状态的用户才拉取通知数据

内容的提问来源于stack exchange，提问作者Sakib ovi