如何实现服务端向移动应用推送downtime消息以触发指定页面加载

整体架构设计思路 #

核心逻辑是在流量入口层做统一拦截，避免每个业务服务单独改造，大幅降低维护成本，整体分为三层：

• 流量入口层：API网关（可选用Kong、APISIX、Spring Cloud Gateway或自研网关），作为所有移动端请求的第一入口
• 状态配置中心：独立的维护状态配置模块，存储各服务/接口的维护时间段、维护等级、对应提示文案、跳转页标识等配置
• 移动端适配层：APP端统一封装网络请求SDK，内置对维护状态响应码的统一处理逻辑

具体操作步骤 #

一、服务端改造步骤 #

1. 部署独立的维护状态配置模块
   配置字段包含：服务标识、接口路径规则、维护开始时间、维护结束时间、是否全局维护、响应状态码、提示文案、自定义跳转页ID、是否允许白名单用户访问。同时配套可视化配置后台，运维/开发可以随时更新维护状态，不需要重启网关或者业务服务。
2. 网关层新增维护状态拦截逻辑
   所有请求进入网关后，先拉取配置中心的当前生效的维护规则，匹配请求对应的服务/接口是否处于维护状态：
   • 未命中维护规则：直接转发请求到下游业务服务
   • 命中维护规则：直接返回约定好的标准响应结构，不需要转发到下游
     约定统一的维护响应格式示例：

   {
     "code": 10001, // 全局统一约定的维护状态码，所有端统一识别
     "msg": "当前服务正在升级维护，预计12:00恢复",
     "data": {
       "jump_type": 1, // 1=跳转到APP内置提示页，2=跳转到H5提示页
       "jump_content": "maintain_notice_v1", // 提示页标识或者H5链接
       "retryable": false // 是否允许用户手动重试请求
     }
   }
   

3. 新增极端场景兜底方案
   如果网关本身也需要维护，在负载均衡层配置fallback响应，返回同样结构的维护提示，保证最极端场景下也能返回标准格式。

二、移动端改造步骤 #

1. 统一封装全局网络请求SDK，所有业务请求都走这个SDK，避免业务层重复开发。
2. SDK内置对维护状态码的拦截逻辑，不需要业务页面单独处理：
   • 收到服务端返回的约定维护状态码时，拦截该响应，不返回给业务层
   • 根据返回的jump_type自动加载对应的提示页面：如果是内置页直接唤起，如果是H5页就打开webview加载对应链接
   • 如果配置了可重试属性，在提示页提供重试按钮，用户点击后自动重新发起原请求
3. 新增本地兜底逻辑：如果请求完全超时/连不上服务端，也可以弹出预置的默认维护提示页，避免出现无响应或者系统报错。

可选优化点 #

• 支持灰度维护：可配置只对部分用户、部分版本的APP展示维护提示，不影响其他用户正常使用
• 支持接口粒度维护：可以只针对某个高风险接口配置维护，其他接口正常提供服务
• 维护状态配置支持预发布：可以提前配置好维护规则，到时间自动生效，不需要运维在维护窗口手动操作

内容的提问来源于stack exchange，提问作者Arvind Chourasiya