新手的SaaS架构问题

Question

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

在我尝试设计架构时,首先想到的问题之一是单租户与多租户的问题.各自的优缺点根据应用程序的类型和所需的规模而有很大差异,因此我想在下面描述我的应用程序和扩展需求,并希望其他人可以评论我应该如何开始使用该体系结构.

客户端 - 服务器应用程序当前包含Firebird数据库和Windows应用程序.该数据库包含大约20个表,其中包含4个主表中的几千条记录,以及各种查找和相关表中的几百条记录.虽然记录数量很少,但是大小可以变大,因为数据库可以包含大型BLOBS.每个客户都建立自己的数据库,并且组织内的少数用户与之相连.当我更新db模式时,会释放一个新的Windows应用程序,它会检查db模式,然后根据需要应用更新.

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

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

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

Answer 1

好问题.

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

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

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

当然,由于应用程序是一个胖客户端应用程序,我们可以放弃进行数据库更改并一次将它们推送给一个被许可方.当我们准备升级时,我们可以与新数据库一起推出更新的胖客户端 - 从而确保代码库与数据库匹配.只要普通的"被许可人"认证数据库保持一致,这就相当不错.

另一方面,这个解决方案带来了维护和管理胖客户端方法的所有问题,最终导致我们失去了基于浏览器的客户端方法.

在我们的新模型中,一切都在一个数据库中.当我们有更新时,我们同时推出代码和数据库.这解决了保持代码库与数据库结构一致的问题.但是,我们现在面临上述#1和2中提到的问题,我们尚未解决这些问题.

我希望这能为你提供一些思考的食物.

我也对这个问题感兴趣.

谢谢你的帖子.

-S