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