1
takeoffyoung 2017-07-23 20:51:38 +08:00
一般来说,要么 push 要么 pull。
根据业务需要权衡是轮训还是长链接。 至于具体能支持多少 QPS,跟如何实现、业务复杂性都有关系,建议自行压测。 一般而言,除非实时性要求极高( IM )和特定必须推送的业务。端上都会采用 pull 的方式进行沟通,这种配置信息变动,其实可以封装一个加载配置的工具库,各个业务逻辑中调用这个工具库,就做到配置信息 lazy load,加上一定时间的缓存。这样对端上而言,配置的加载也是 lazy load。 |
2
chipmuck 2017-07-23 23:06:20 +08:00
消息通知
|
3
just1 2017-07-23 23:13:28 +08:00
比对版本号放在客户端进行
服务器上放静态 json 就行 |
4
codelover2016 2017-07-23 23:15:51 +08:00
去哪儿有一个 QConf 的配置框架,可以看下...
|
5
cloudzhou 2017-07-23 23:27:20 +08:00
websocket 长链接
|
6
nfroot 2017-07-23 23:28:37 +08:00
push 到第三方服务器去,或者任何可以公开展示的 URL。
以前有人作死放 github 上,结果导致全国的 IP 都冲向 github,后果你明白的。 |
7
xiaket 2017-07-24 07:10:00 +08:00
版本信息放 DNS, 解一个域名来判定是否要更新
|
8
rffan 2017-07-24 10:35:04 +08:00
要实时效果佳,你找个 MQ 啊,把版本更新放到 mq 上,你的客户端 subscribe 关于版本的 topic 就 OK 了。预计版本更新的 topic 一发布,你的客户端就能更新了
|
9
8355 2017-07-24 13:56:18 +08:00
跟之前楼中说的一样 也是用静态 json
优势是 nginx 处理静态资源会快很多并且不会对你的服务器产生比较大的压力 普通配置就能支撑起很高的并发量 而且现在用对象储存 cdn 优势非常明显 扩容方便 劣势是需要一定工时才能开发一套系统去管理这些 json 文件的更替 比如备份 cdn 同步 流量管理等等 |