Scaling Meteor (来自非技术人员的Q)

Question

当预期有大量并发用户时，使用Meteor作为我们的全栈框架来构建web应用程序是不是不明智？

我们正在寻找建立一个网络应用程序，在它的第一阶段，是一个音乐的product hunt (提供用户提交的网址从Youtube的应用程序接口的播放请求)。

Meteor的好处似乎在于开发MVP/原型来学习用户行为的速度有多快，但风险似乎在于在产品生命周期的整个过程中使用在此阶段构建的内容。

我想知道是否有人可以帮助我无知的大脑理解外行的术语，如果我上面断言的任何东西是不正确的/正确的，如果是，为什么？真诚地感谢您对此的任何/所有的意见

Answer 1

没有账户或订阅的meteor应用的通信和CPU开销几乎为零。但是，正如我在回答this question时指出的那样，真正的资源约束来自于维护服务器和客户机之间的查询结果集。换句话说，随着订阅数量、大小和复杂性的增加，扩展变得困难。

在不了解你的产品和它的工作原理的情况下，我的一般建议是:去尝试吧，因为meteor会给你一个快速的MVP。如果你发现你因为大量的用户(恭喜！)而很难扩展，那么你总是可以通过使用各种技巧来减少你的订阅费用，包括非反应性数据(方法调用)。

推荐阅读：Scaling Meteor: The Challenges of Real-time Apps

Answer 2

一点也不是不明智。有一个叫ClassCraft的网站是用流星公司建立的，我想它每天有15,000个登录用户。

你最简单的解决方案可能是使用基于节点的托管服务，比如Modulus，它会自动为你处理伸缩。

迈向更DIY解决方案的下一步是在Compose或MongoLab等提供商上托管你的MongoDB，但在你自己的服务器上托管流星应用本身。在mup中可以找到一个简单的部署脚本，或者是他正在开发的更新的解决方案mupx，它使用Docker来部署流星应用。

这只触及了皮毛，但希望能给你更多的信心，让你相信它已经完成了，并且可以做到。