近期关于扩展 dev.to Rails 应用的经验教训

dev.to拥有相当可扩展的架构，因为我们构建它的目的是让大多数流量通过我们的 CDN Fastly 在边缘静态缓存。从这个意义上讲，我们的扩展性与静态网站类似，但每当内容发生变化（例如新的评论、文章更新或任何其他新鲜度变化）时，我们都会重新开始并直接返回到源站。我们还会与大多数请求异步提供一些动态内容。因此，服务器上仍然会承受很大的负载。

与任何 Rails 应用程序一样，我们会遇到不同的资源限制，并在扩展时解决它们。

在应对资源瓶颈波动时，我们基本上需要了解哪些资源正在被消耗，以及当这些资源耗尽时应该采取哪些措施。鉴于过去一些科技公司在扩展这一技术栈方面取得了巨大成功，我们无需太过聪明，只需掌握相应的工具即可。

尽管如此，我们当然仍然存在问题。代码很难。我想分享一些我为了带领团队克服的思维障碍。接下来是经验教训：

出现问题时，回到旧材料

当我们遇到困难时，我常常没有重读那些好的材料，错误地认为问题是新问题。通常，它只是用新的角度看待同一个基本问题。下次我们遇到特别困难的时候，我会重读很多优秀的材料。要以开放的心态阅读大量资料，而不是纯粹为了解决问题而阅读。在思考这些问题时，你肯定不想只见树木不见森林。

在这方面， Nate Berkopec 的Speedshop 博客以及他提供的其他内容非常实用。我们遇到的具体问题无需在此赘述，但“不要觉得需要新材料”这个建议才是真正的教训。

过去几年中，一些 DEV 成员在平台上或个人博客上的内容也提供了帮助：

迈克·库特马什跟随

代码@github

[已删除用户]

两者都值得关注，还有更多在#rails上发帖的人

最近Mike 的这篇旧帖子对我思考 Heroku 资源问题特别有帮助。重读一遍至关重要，因为我把一些重要的结论记混了。

展望未来

未来充满挑战。例如，Postgres 已经有一段时间没有成为瓶颈了，但将来它可能会再次成为瓶颈。到那时，与其手忙脚乱地学习新知识，不如立即彻底重温那些曾经帮助我们克服过一些小问题的旧知识。从现在开始，我们可以继续学习新知识，但不能犯这样的错误：认为已经完全掌握并记住了旧知识，却又要面对未来无限期的新问题。

编码愉快！