新手的SaaS架构问题
我已经开发了许多部门客户端-服务器应用程序，现在准备开始将其中一个应用程序迁移到 SaaS 模型。我已经完成了一些基本的 Web 开发，但对于 SaaS 架构我还是个新手。
当我尝试设计架构时，首先想到的问题之一是单租户与多租户的问题。根据应用程序的类型和所需的规模，每种方案的优缺点都有很大差异，因此我想在下面描述我的应用程序和规模需求，并希望其他人能够评论我应该如何开始使用该架构。
客户端-服务器应用程序当前由 Firebird 数据库和 Windows 应用程序组成。该数据库包含大约 20 个表，其中 4 个主表中包含数千条记录，以及各种查找和相关表中的数百条记录。尽管记录数量很少，但大小可能会变大，因为数据库可能包含大型 BLOBS。每个客户都建立自己的数据库，并在组织内有少数用户连接到该数据库。当我更新数据库架构时，会发布一个新的 Windows 应用程序，它会检查数据库架构，然后根据需要应用更新。
对于 SaaS 应用程序，我每年为 100 名（不是 1000 名或数百万）新客户进行设计。我的第一个想法是采用多租户模型来简化更新（关闭将更新应用到一个数据库，然后启动）。另一方面，单一租赁模型将提供一种一次向一组客户推出更新的方法，并分散数据损坏的风险 - 即，如果数据库出现问题，它将影响一个客户而不是一个客户。所有客户。有了这个想法，我正在考虑拥有一个单一的 Web 前端，它可以在登录时连接到单个客户数据库。因此，当新客户创建帐户时，将创建一个新数据库（每个客户将拥有自己的数据库，根据客户的需要具有多个用户）。
在此模型中，数据库更新将需要一个过程来遍历每个数据库以应用架构更改，或者在登录时使用触发器来启动类似于当前使用的客户端-服务器模型的架构更新。
任何人都可以向我指出已从客户端服务器移植到 SaaS 的类似应用程序的信息吗？或者提供任何值得考虑的指导？基本上，我正在寻找采用部门应用程序并将其作为多个客户的自助服务网站提供的架构示例。感谢您的任何建议、资源等。
I have developed a number of departmental client-server applications, and am now ready to begin working on moving one of these applications to a SaaS model. I have done some basic web development, but I'm a newbie when it comes to SaaS architectures.
One of the first questions that comes to mind as I try to design the architecture is the question of single vs. multi tenancy. The pros and cons of each vary significantly depending on the type of application and scale required, so I'd like to describe my application and scale needs below, and hope others can comment on how I should get started with the architecture.
The client-server application currently consists of a Firebird database and a Windows application. The database contains about 20 tables containing a few thousand records in 4 primary tables, and a few hundred records in various lookup and related tables. Although the number of records is small, the size can get large, as the database can contain large BLOBS. Each customer sets up their own database and has a handful of users within the organization connected to it. When I update the db schema, a new windows application is released, and it checks the db schema and then applies the updates as needed.
For the SaaS application, I am designing for 100's (not 1000's or millions) of new customers per year. My first thought was to go with a multi tenancy model to make updates easy (shut down apply the updates to one database, and then start up). On the other hand, a single tenancy model would provide a means to roll updates out to a group of customers at a time, and spread the risk of data corruption - i.e. if something goes wrong with a database, it will impact one customer instead of all customers. With this idea, I was thinking of having a single web front-end which would connect to a single customer database upon login. Thus, when a new customer creates an account, a new database would be created (each customer would have their own db with multiple users as needed for the customer).
In this model, a db update would require either a process to go through each db to apply schema changes, or a trigger upon logging in to initiate a schema update similar to the client-server model currently in use.
Can anyone point me to information for similar applications which have been ported from client-server to SaaS? Or provide any pointers to consider? Basically I'm looking for architecture examples of taking a departmental application and making it available as a self service website for multiple customers. Thanks for any suggestions, resources, etc.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您有多个数据库，并以分阶段的方式推出，以减少破坏所有客户的可能性，那么您将必须解决数据库结构发生变化时该怎么办的问题。您要么必须严格维护向后兼容性，要么部署代码库的单独版本并管理哪些租户与哪些数据库关联。
我们也使用 SaaS 模型提供我们的应用程序。
它最初是一个 Windows 应用程序，其工作方式与您的多数据库提案类似。登录后，该应用程序将针对单个被许可人数据库进行身份验证，该数据库将响应特定于该被许可人的数据库的连接信息。这样做的好处是，它提供了 1) 被许可方数据的物理分离，这是我们的客户喜欢的；2) 使我们能够将数据库物理定位在地理位置更靠近用户的服务器上，这既提高了性能，又避免了一些潜在的棘手法律问题。以及跨国界提供数据的监管问题。
由于该应用程序是一款胖客户端应用程序，因此我们可以对数据库进行更改并将其一次推送给一个被许可人。当我们准备好升级时，我们可以推出更新后的胖客户端以及新数据库，从而确保代码库与数据库匹配。只要通用被许可人身份验证数据库保持一致，这种方法就相当有效。
另一方面，这个解决方案带来了维护和管理胖客户端方法的所有问题，最终导致我们采用基于浏览器的瘦客户端方法。
在我们的新模型中，所有内容都在一个数据库中。当我们有更新时，我们会同时推送代码和数据库。这解决了保持代码库与数据库结构一致的问题。但目前我们还面临上述问题，尚未解决。
If you have multiple databases which you roll out in a staged manner to reduce the likelihood of breaking all of your customers, you will have to address the issue of what to do if the DB structure changes. You will either have to be rigorous maintaining backward compatibility, or else deploy separate versions of your code base and manage which tenants are associated with which databases.
We are providing our application using a SaaS model as well.
It was initially a Windows app which worked similarly to your multiple-database proposal. Upon login, the app would authenticate against a single licensee database which would respond with connection information for a database specific to that licensee. The nice thing about this was that it provided 1) physical separation of licensee data, which our customers liked and 2) enabled us to physically locate the database on a server geographically closer to the users, which both improves performance and avoids some potentially tricky legal and regulatory issues with providing data across country boundaries.
Since the app was a thick client app, we could get away with making database changes and pushing them out to one licensee at a time. When we were ready to upgrade, we could push out an updated thick client in conjunction with the new database--thereby ensuring that the codebase was a match with the database. As long as the common licensee authentication database stayed consistent, this worked fairly well.
On the other hand, this solution brought with it all of the problems of maintaining and managing a thick client approach which finally lead us down the thin client, browser-based approach.
In our new model, everything is in a single database. When we have updates, we push the code and the DB out at the same time. This solves the problem of keeping the code base consistent with the database structure. However, we are now confronted with the issues mentioned above, which we have yet to resolve.