我有一个 meteor.js 应用程序，可以很好地为单个实例手动配置和部署。
现在是时候重构应用程序的架构并构建应用程序周围的基础架构，以使其能够在客户端部署和更新。
我想让客户来到一个他们可以注册应用程序的页面，一个实例或租期会自动为他们设置，他们可以开始使用它。在后端将有基础设施来管理应用程序的更新。
有一些明显的决定需要做出:
- 我是否将其重构为 Multi-Tenancy ？ (更多应用代码修改)
- 我是否将其重构为多实例？ (更多基础设施 build 和代码)
- 它是混合体吗？ (一个应用程序但多个数据库)
应用哪些测试来确定上述问题的正确答案？各自的优缺点是什么？
一旦做出决定，是否存在设计模式来指导或激发适当的重构，和/或对于没有构建 Multi-Tenancy 或多实例应用程序的人来说，那里有哪些学习资源？
如果它的多实例化应该将实例化和更新作为应用程序本身的一部分，还是应该构建另一层代码和工具来管理该部分？
最佳答案
我在这里数了 3 个问题，您可能会发现将它们分成单独的线程很有值(value)。无论如何:
1) 确定正确架构的测试是什么？好吧，仔细看看支持每种架构需要多少成本，以及每种架构的实现速度以及您似乎有多少等待的客户。顽固是因为，坦率地说，您可能已经有了偏好，除非您愿意将其搁置一旁，否则我在这里给出的答案是没有实际意义的。如果这是针对企业，请记住收入规则——没有收入，即使是最美丽优雅的建筑也不重要。有了收入，您可以及时修复大多数架构错误。
2) Multi-Tenancy 、可嵌入应用程序的良好设计模式是什么？我不确定设计模式是正确的答案，而是数据管理和严格测试。这里的目标是确保客户端 A 的客户永远不会得到客户端 B 的客户数据的提示，即使一个人同时是客户端 A 和客户端 B 的用户。仔细注意 API key 和 session key 管理是顺序那天。
3) 应用程序中的实例管理，还是单独的工具？我要冒险，并建议如果不分析您当前的应用程序和基础架构，没有人能够满意地回答这个问题。也许你有一个大部分是 self 部署的应用程序，只需要多几行来设置一个新的数据库，或者启动一个新的 AWS 实例，或者其他什么......或者你有一个高度手动的过程。这也可能受到您在问题 1 中选择的架构和/或您有多少时间的影响。请参阅有关问题 1 收入的注释。
关于javascript - 如何将手动部署的单实例应用程序重构为客户端部署的多实例或 Multi-Tenancy 应用程序，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18050000/