来自新手的 SaaS 架构问题

Question

我已经开发了许多部门客户端-服务器应用程序，现在准备开始着手将其中一个应用程序迁移到 SaaS 模型。我已经完成了一些基本的 Web 开发，但在 SaaS 架构方面我是新手。

当我尝试设计架构时，首先想到的一个问题是单租户与多租户的问题。每种方法的优缺点因应用程序类型和所需规模而有很大差异，因此我想在下面描述我的应用程序和规模需求，并希望其他人可以评论我应该如何开始使用该架构。

客户端-服务器应用程序目前由一个 Firebird 数据库和一个 Windows 应用程序组成。该数据库包含大约 20 个表，其中包含 4 个主表中的数千条记录，以及各种查找和相关表中的数百条记录。尽管记录的数量很少，但大小可能会变大，因为数据库可以包含大 BLOBS。每个客户建立自己的数据库，并在组织内有少数用户连接到它。当我更新 db 架构时，会发布一个新的 Windows 应用程序，它会检查 db 架构，然后根据需要应用更新。

对于 SaaS 应用程序，我每年为 100 个（不是 1000 个或数百万个）新客户进行设计。我的第一个想法是使用多租户模型来简化更新（关闭将更新应用到一个数据库，然后启动）。另一方面，单一租户模型将提供一种将更新一次向一组客户推出的方法，并分散数据损坏的风险——即，如果数据库出现问题，它将影响一个客户，而不是影响一个客户。所有客户。有了这个想法，我想有一个 Web 前端，它会在登录时连接到单个客户数据库。因此，当新客户创建帐户时，将创建一个新数据库（每个客户都将拥有自己的数据库，其中包含客户需要的多个用户）。

在此模型中，数据库更新将需要一个进程来遍历每个数据库以应用架构更改，或者在登录时触发以启动类似于当前使用的客户端-服务器模型的架构更新。

任何人都可以向我指出已从客户端服务器移植到 SaaS 的类似应用程序的信息吗？或者提供任何需要考虑的指针？基本上，我正在寻找采用部门应用程序并将其作为自助服务网站提供给多个客户的架构示例。感谢您提供任何建议、资源等。

Answer 1

好问题。

想到的一件事是，如果您有多个数据库，并且您以分阶段的方式推出以减少破坏所有客户的可能性，那么您将必须解决如果数据库结构不完整该怎么办的问题变化。您要么必须非常严格地保持向后兼容性，要么部署单独的代码库版本并以某种方式管理哪些租户与哪些数据库相关联。

我们也使用 SaaS 模型提供我们的应用程序。

它最初是一个 Windows 应用程序，其工作方式类似于您的多数据库提案。登录后，win 应用程序将针对单个“被许可人”数据库​​进行身份验证，然后该数据库将使用特定于该被许可人的数据库的连接信息进行响应。这样做的好处是它提供了 1) 被许可人数据的物理分离，这是我们的客户喜欢的；2) 使我们能够将数据库物理定位在地理位置更接近用户的服务器上，这既提高了性能，又避免了一些潜在的棘手的法律和与跨国界提供数据有关的监管问题。

当然，由于该应用程序是一个胖客户端应用程序，我们可以通过更改数据库并一次将其推送给一个被许可人来摆脱困境。当我们准备好升级时，我们可以推出一个更新的胖客户端连同新的数据库——从而确保代码库与数据库匹配。只要通用的“被许可人”身份验证数据库保持一致，就可以很好地工作。

但另一方面，该解决方案带来了维护和管理胖客户端方法的所有问题，最终导致我们采用基于浏览器的事物客户端方法。

在我们的新模型中，所有内容都在一个数据库中。当我们有更新时，我们同时推送代码和数据库。这解决了保持代码库与数据库结构一致的问题。但是，我们现在遇到了上面 #s 1 和 2 中提到的问题，我们尚未解决。

希望本文能给你一些启发。

我也对这个问题感兴趣。

感谢您的帖子。

-S