app 初始化时需要通过接口获取上千个独立的配置项，如何优化？

[aboutboy]

正在开发一个 app ，用户在使用 app 访问服务时，需要根据对应的服务从后端获取对应的配置文件（ json 格式）。

一共有上千个独立的配置项。

目前是当 app 第一次启动时，会首先通过接口查询配置项清单，然后再依次对各配置项进行请求获取。

这样的问题是，一个 app 就会向后端发起上千个请求。而且可能需要十来分钟甚至更长时间才能把全部配置拉下来。

这样一方面对后端服务器造成压力，另一方面影响用户体验。

如果把配置全部打包在一起的话，大概40-50MB左右。

有些配置项还会更新，这就需要app 在后续的运行过程中对有更新的配置项进行更新。

请问大佬们有什么好的思路？

[tool2dx]

采用类似游戏客户端的差异化更新，第一次向打包一部分预配置到 app 内，每次启动，有新变动再申请下载。

[onichandame]

@horizon #19 静态的移到 oss 没问题，动态的配置项分类获取不就是我说的渐进式获取吗。。。要优化的是前端的调用逻辑，后端接口根据题主说的明显已经分成了不同的接口

[LieEar]

我觉得也可以采用 OSS 方案，打包后上传，让 APP 直接去 oss 拿

[janus77]

啥系统啊这么多配置，感觉大厂的 APP 都没你们多

[spicy777]

高并发就是这么玩出来的是吧

[zgsi]

不改变现状的话，就 oss+cdn 吧

[horizon]

@onichandame #22
「一个 app 就会向后端发起上千个请求」
看上去是后端把配置项细分了啊
不然哪需要这么多请求

[gorvey]

@cinlen 盲猜是以前的中后台系统，迭代了很久产生了大量的字典数据，后端没做优化，然后 APP 用以前的接口问题就暴露了

[horizon]

@onichandame #22
再渐进不还是要发上千个请求么
关键要是聚合吧
大概率是后端新手，创建了一个通用获取配置的接口而且不支持传多个 key 值

[adoal]

如果是 to B 的项目，别优化了，to B 哪有不纵容屎山的。如果是 to C 的项目，首先重构业务逻辑。

[mb4555]

不变的直接打包到 app 里面

[potatowish]

把配置按使用场景分类，加个聚合层

[mooyo]

app 层抽一个 proxy configuration manager ，服务端定期聚合部分 config ，如果是用户无关的，聚合成 CDN 文件，如果用户相关的，走接口一次性拉下来

[learnshare]

是一次把数据库全吐出来吗
还是所谓的原子化、微服务

进入 App 的时候，第一个页面要用到所有数据？

[mymail6811]

在服务器加一层, app 给服务器发一个请求, 服务器再去获取那上千个配置项并返回. 之后再慢慢改后端

[li746224]

好想见识一下这个 app

[aboutboy]

@onichandame 也想过这个方式，感觉可能最合适的方案。

[aboutboy]

@Puteulanus 现在是一次全部拉取，如果有更新的话，可以通过接口获取更新列表，再按照列表去拉取。

[aboutboy]

@learnshare 其实只有在访问某个页面的时候才会用到那个对应的配置。可能是为了让用户不等待，所以在 app 首次启动的时候去把几千个配置都拉下来。感觉产品上用户访问某个页面时是可以接受等待加载配置的。

[aduangduang]

配置项清单带上每个配置的 md5 结果
前端第一次请求全部内容后本地存储
后续只请求配置项清单，和本地配置项清单做对比后 增量同步有变动的内容