服务端WebService合适框架选型：适配安卓APP仅GET请求拉取数据场景

方案可行性结论 #

你原本规划的Spring Boot开发只读GET接口的REST服务方案完全适配当前场景，不需要额外替换技术栈，不用纠结可行性。

核心原因 #

• 并发能力完全达标
  Spring Boot默认内嵌的Tomcat容器，单实例默认配置就能轻松扛下每秒数千次短连接GET请求。你的场景没有复杂业务逻辑、返回数据最大才1MB，且每个用户仅发起一次请求，后续只要按需做实例水平扩容、前端挂载负载均衡，完全可以支撑百万甚至千万级新增安装量的请求压力。
• 仅暴露GET接口的REST服务非常合理
  REST架构从来没有强制要求实现全量POST/PUT/DELETE接口，你这种只读数据获取的场景用GET请求刚好符合HTTP语义，不管是服务端缓存、CDN缓存还是客户端缓存的适配成本都极低。反而如果选用私有传输协议，会额外增加双端的开发维护成本，完全没有必要。

可选优化建议 #

如果要进一步降低服务端压力、提升访问效率，可以做几个低成本优化：

• 开启接口返回结果的gzip压缩，原本最大1MB的数据包压缩后通常只有原体积的30%以内，既降低用户的传输耗时，也能节省服务端的带宽成本
• 如果拉取的数据更新频率较低，可以直接将静态数据托管到CDN，用户请求优先命中就近的CDN节点，仅首次回源会访问你的源站服务，源站压力直接降低90%以上
• 如果数据存在定期更新的需求，可在服务端增加Redis缓存层，避免每次请求都查询数据库，进一步提升接口响应速度和并发上限

如果你团队对其他Java云原生框架熟悉，也可以考虑用Quarkus、Micronaut这类更轻量的框架，同等服务器配置下并发承载能力更高、内存占用更低。但如果团队已经有Spring Boot开发经验，完全不需要额外替换，现有方案已经足够好用。

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