如何将手动部署的单实例应用程序重构为客户端部署的多实例或多租户应用程序

Question

我有一个流星.js 应用程序，可以很好地为单个实例手动配置和部署。

现在是重构应用程序架构并围绕应用程序构建基础架构以使其能够在客户端部署和更新的时候了。

我想让客户来到他们可以注册应用程序的页面，会自动为他们设置一个实例或租约，他们可以开始使用它。在后端会有基础设施来管理应用程序的更新。

有一些明显的决定需要做出：

• 我是否将其重构为多租户？ （更多应用代码修改）
• 我是否将其重构为多实例？ （更多基础设施建设和代码）
• 它是混合动力车吗？ （一个应用程序，多个数据库）

通过哪些测试来确定上述问题的正确答案？各有什么优缺点？

一旦做出决定，是否存在指导或激发适当重构的设计模式，和/或有哪些学习资源可供尚未构建多租户或多实例应用的人使用？

如果它的多实例化应该是应用程序本身的一部分，还是应该构建另一层代码和工具来管理该部分？

Answer 1

我在这里计算了 3 个问题，您可能会发现将它们分成单独的主题很有价值。无论如何：

1) 确定正确架构的测试是什么？好吧，仔细研究一下支持每种架构的成本与每种架构的实施速度以及您有多少等待的客户似乎是有序的。硬着头皮因为，坦率地说，你可能已经有一个偏好，除非你愿意把它放在一边，我在这里给出的答案是没有实际意义的。如果这是针对企业的，请记住收入规则——没有收入，即使是最漂亮、最优雅的架构也不重要。有了收入，您可以及时修复大多数架构错误。

2) 多租户、可嵌入应用程序的良好设计模式是什么？我不确定设计模式是正确的答案，而是数据管理和测试的严谨性。这里的目标是确保客户端 A 的客户永远不会得到客户端 B 的客户数据的提示，即使一个人同时是客户端 A 和客户端 B 的用户。仔细注意 API 密钥和会话密钥管理是顺序那天。

3) 应用中的实例管理，还是单独的工具？我将冒险出去，并建议如果不分析您当前的应用程序和基础架构，没有人能够令人满意地回答这个问题。也许你有一个主要是自我部署的应用程序，只需要几行代码来设置一个新的数据库，或者启动一个新的 AWS 实例，或者其他什么......或者你有一个高度手动的过程。这也可能受到您从问题 1 中选择的架构和/或您有多少时间的影响。请参阅关于问题 1 收入的说明。