rekulas

rekulas

V2EX 第 173283 号会员,加入于 2016-05-16 14:09:48 +08:00
今日活跃度排名 4281
根据 rekulas 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
rekulas 最近回复了
1 天前
回复了 mmdsun 创建的主题 分享发现 微软宣布以 687 亿美元收购动视暴雪
微软=微砍砍
我之前看了一点点易经,发现这其实是一个基于人脑神经网络的多元回归预测模型 🤣
这个就是类似我们以前遇到的问题,最开始也是采用独立版本,但是这样同步修改比较麻烦
所以后面就直接整合在一个版本里了,相当于你每个不同项目就是一个子站,数据库上能直接数据独立就独立实在不能独立就分别存储,程序上根据不同子站实现定制化功能需求,这样做的缺点是前期整合起来很痛苦,耦合性也过高,但优点就是维护方便
我感觉大型公司处理这个问题也是整合到一起的,不然随着版本号的不断累加,拆分后即使是大公司也难以承担越来越高的维护成本
没有优雅的解决方案
@dingdangnao 我试试看 多谢提醒
@vokins win 处理的话程序倒是简单,我自己都可以 2 小时撸一个出来,但是有点麻烦,要先传电脑上,处理完再备份云端
@mokong 我愿意成为第一个付费用户
我也建议全部 post 来,rest 本身就不是一种足够完备的风格,如果全部机械式按 rest 设计只会带来更多麻烦不便
api?{"req1param":{},"re2param":{}}
或考虑伪静态之类 api/{"req1param":{},"re2param":{}}

参数也可以编码一下
现在还有个 GraphQL 的新概念,需要后端配合修改据说可以多个 api 整合但是会增加不少工作量没用过
直接拼接倒 url 或者 (如果有冲突)装入 json 整个作为一个参数?
反正作为 get 来说参数应该不多,如果参数太多还用 get ,感觉是有问题的
@NeezerGu 单机的话 redis 主要瓶颈在内存,多开不能提高什么性能(我怀疑还会降低)
如果是多机,那不如直接 redis 集群了,还不用考虑分配系统逻辑更简单
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4045 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 15ms · UTC 01:43 · PVG 09:43 · LAX 17:43 · JFK 20:43
♥ Do have faith in what you're doing.