我有一个meteor.js应用程序，可以很好地为单个实例手动配置和部署。
现在是时候重构应用程序的体系结构并围绕应用程序构建基础架构，以使其能够进行客户端部署和更新。
我想让客户来到一个页面，他们可以在这个页面上注册应用程序，为他们自动设置实例或租赁，他们可以开始使用它。在后端，将有基础设施来管理应用程序的更新。
需要做出一些明显的决定：
用什么测试来确定上述问题的正确答案？什么是各自的利弊？
一旦做出决定，是否存在设计模式来指导或启发适当的重构，和/或那些没有构建多租户或多实例应用程序的人存在哪些学习资源？
如果它的多实例应该将实例化和更新作为应用程序本身的一部分，还是应该构建另一层代码和工具来管理该部分？
答案 0 :(得分：3)
我在这里计算了3个问题，您可能会发现将它们分成不同的线程很有价值。无论如何：
1）确定正确架构的测试是什么？好吧，我们很难看出支持每个体系结构的成本与每个体系结构的实现速度有多大关系。你有多少等待的客户似乎有序。很难，因为坦率地说，你可能已经有了偏好，除非你愿意把它放在一边，我在这里给出的答案是没有实际意义的。如果这是为了一个企业，请记住收入规则 - 没有收入，即使是最美丽的＆amp;优雅的建筑是不重要的。通过收入，您可以及时修复大多数架构错误。
2）多租户，嵌入式应用的优秀设计模式是什么？我不确定设计模式是否是正确的答案，而是数据管理＆amp;测试严谨。这里的目标是确保客户A的客户永远不会得到客户B的客户数据的提示，即使一个人是客户A和客户B的用户。仔细关注API密钥和会话密钥管理是顺序那一天。
3）app中的实例管理，还是单独的工具？我打算走出困境，并建议没有分析你当前的应用和基础设施，没有人能够满意地回答这个问题。也许你有一个主要是自我部署的应用程序，只需要几行来设置一个新的数据库，或者启动一个新的AWS实例，或者其他......或者你可能有一个高度手动的过程。这也可能受到您从问题1中选择的架构和/或您有多少时间的影响。请参阅问题1中有关收入的说明。