Rails 有哪些,是项目开始运行甚至成熟后,非常后悔没有提前配置或加上的?

Catherine · December 03, 2021 · Last by guyanbiao replied at December 22, 2021 · 1898 hits

想收集“如果当时”,“那就”的故事,也可以给大家初建项目时作为个参考。

欢迎大伙分享

代码健康度评分

没用,几乎没人能预测未来业务需求。

架构设计,log,监控,压测,灰度方案,回滚方案,限流,降级方案,扩容方案。

除了架构设计,基础服务好的话,做起来很方便,没有的话,就很麻烦。

Reply to xiaoronglv

说得太好了,一开始心血来潮写了一堆测试用例,每次需求一改,全部报废。T_T

后悔一开始觉得这个东西实际上应该不会出现所有没有处理,后来发现果然出了问题还是得处理

Reply to xiaoronglv

是不是可以用 HashID 来做一下补救?

Reply to xiaoronglv

如果不做反爬和资源权限控制 UUID 只能是增加爬虫的复杂度 并不实际解决问题呀

Reply to xiaoronglv

请问一下,如果,有资源权限控制的话,应该不容易爬才对??

Reply to zj0713001

权限是要加的,scope 也是要加的,比如 company.resources.find_by()

uuid 可以保证第二道防线。

需求文档没有及时更新,代码没有注释

我后悔“没有配置 rack-timeout 的 wait_timeout,当 db 短暂地出现问题,导致所有 API 响应慢,puma 的 request queue 开始疯狂堆积,每个 API response time 越来越慢”

db 恢复后,也只能通过重启所有 containers 来清理 request queue

我后悔“没有给 redis 配置 retry delay 时间,当 redis 响应时间抖动一下,所有 redis client 都立即重试,导致 redis cpu usage 涨至 +90% ”

Reply to hjiangwen

感谢分享,很宝贵

后悔没有好好做需求分析,虽然 Rails 是非常耐改的,但是用户,PM,UI 和在一起变需求,还是很够喝一壶的。

Reply to ericguo

就是喜欢 Rails 的耐改,开发的时候想怎么改就怎么改。

Reply to ericguo

光分析是没用的,主要得说服用户他们

Reply to hjiangwen

还不快出一本《高可用 Rails 踩坑指北》

You need to Sign in before reply, if you don't have an account, please Sign up first.