我已经开发了许多部门客户端 - 服务器应用程序，现在我已准备好开始将这些应用程序中的一个移动到SaaS模型。我已经完成了一些基本的Web开发，但在SaaS架构方面我是一个新手。
当我尝试设计架构时，首先想到的问题之一是单租户与多租户的问题。各自的优缺点根据应用程序的类型和所需的规模而有很大差异，因此我想在下面描述我的应用程序和扩展需求，并希望其他人可以评论我应该如何开始使用该体系结构。
客户端 - 服务器应用程序当前包含Firebird数据库和Windows应用程序。该数据库包含大约20个表，其中包含4个主表中的几千条记录，以及各种查找和相关表中的几百条记录。虽然记录数量很少，但是大小可以变大，因为数据库可以包含大型BLOBS。每个客户都建立自己的数据库，并且组织内的少数用户与之相连。当我更新数据库模式时，会发布一个新的Windows应用程序，它会检查数据库模式，然后根据需要应用更新。
对于SaaS应用程序，我每年为100个（不是1000或数百万）新客户设计。我的第一个想法是使用多租户模型来简化更新（关闭将更新应用于一个数据库，然后启动）。另一方面，单一租赁模型将提供一种方法，一次将更新推送给一组客户，并分散数据损坏的风险 - 即如果数据库出现问题，它将影响一个客户而不是所有客户。有了这个想法，我想到有一个单独的Web前端，可以在登录时连接到单个客户数据库。因此，当新客户创建一个帐户时，将创建一个新数据库（每个客户将拥有自己的数据库，其中包含客户所需的多个用户）。
在此模型中，数据库更新需要一个进程来遍历每个数据库以应用模式更改，或者需要登录时触发器以启动类似于当前正在使用的客户端 - 服务器模型的模式更新。
有人能指出我已经从客户端服务器移植到SaaS的类似应用程序的信息吗？或提供任何指针考虑？基本上我正在寻找采用部门应用程序并将其作为多个客户的自助服务网站提供的体系结构示例。感谢您提供任何建议，资源等。
答案 0 :(得分：7)
好问题。
我想到的一件事是，如果你有多个数据库，你以分阶段的方式推出，以减少破坏所有客户的可能性，你将不得不解决如果数据库结构如何做的问题变化。您要么必须非常严格地维护向后兼容性，要么部署单独版本的代码库，并以某种方式管理哪些租户与哪些数据库相关联。
我们也使用SaaS模型提供我们的应用程序。
最初是Windows应用程序，其工作方式类似于您的多个数据库提案。登录后，win app将针对单个“被许可人”数据库进行身份验证，该数据库随后会响应特定于该被许可人的数据库的连接信息。关于这一点的好处在于它提供了1）被许可人数据的物理分离，我们的客户喜欢这些数据，并且2）使我们能够在数据库上物理地将数据库定位在地理上更接近用户的服务器上，这既提高了性能又避免了一些潜在的棘手的法律和关于跨国界提供数据的监管问题。
当然，由于该应用程序是一个胖客户端应用程序，我们可以放弃进行数据库更改并一次将其推送给一个被许可方。当我们准备好升级时，我们可以与新数据库一起推出更新的胖客户端 - 从而确保代码库与数据库匹配。只要普通的“被许可人”认证数据库保持一致，这种方法就相当不错。
另一方面，这个解决方案带来了维护和管理胖客户端方法的所有问题，最终导致我们失去了客户端，基于浏览器的方法。
在我们的新模型中，一切都在一个数据库中。当我们有更新时，我们同时推出代码和数据库。这解决了保持代码库与数据库结构一致的问题。但是，我们现在面临上述＃1和2中提到的问题，我们尚未解决这些问题。
我希望这能为你提供一些思考的食物。
我也对这个问题感兴趣。
感谢您的帖子。
-S