多个实例的应用程序 - 每个客户一个？

Question

我正在考虑将我的产品作为服务提供 - 通过在线交付。目前它是一个缩小包装的软件，用户可以下载到他们的服务器并在其服务器上运行 - 例如fogbugz。

在我的新业务模式中，我将提供两种业务模式，一种是用户在其服务器上安装的传统缩小包装软件 - 并执行所有维护和升级工作。另一种是软件即服务（SaaS）类型，其托管是在我的服务器上完成的，并且用户可以使用一个URL来登录。当然，每个客户帐户都有唯一的URL，例如companya.mysoft.com，companyb.mysoft.com。

现在的问题是因为我已经有一个现有的代码库，我想对我的代码做最小的修改，以便它支持两种业务模式。对于SaaS模式，我想为应用程序创建多个实例 - 每个客户一个实例。所以每个客户都有自己的数据库，他们自己的应用程序。所有的客户数据库和应用程序都位于我的服务器上。好处是我根本不需要更改我的代码。坏事是有很多冗余，可能无法扩展。

您如何看待这种针对每个客户的多重实例？或者我必须修改我的代码，以便支持这两种模式（易于维护和升级）？

编辑：下载版本是需要的，没有办法避免这种情况。

编辑2：我的应用程序是一个PHP应用程序。

Answer 1

每个客户的完整实例将随着客户群的增长而产生维护噩梦。但它可能有助于您开始进行SaaS业务。请注意，成功可能意味着一些应用程序的重新架构可以更好地扩展。

重要细节要考虑包括：

数据隔离，是非常重要的，维护和升级数千个独立的数据库涉及大量的开销。一个共同的问题是，客户会担心他们的数据与其他人混在一起，并且不太安全。我曾为三家提供SaaS模型的公司工作，并且数据混合从未成为客户关心的问题。在一天结束时，您将获得所有数据，并且它将会或不会安全，使用多少个dbs并不重要。除非您不可能拥有超过几十个客户，否则我强烈建议将多个客户整合到一个数据库中，并支持多个数据库，这使得管理数据库变得更加容易。我曾与一系列数据的PetaBytes系统合作，为大于80k的客户分布在几十个数据库上，而且它非常易于管理。我曾经为一个拥有几十个TeraBytes数据的系统开发过几十个客户，每个客户都拥有自己的数据库，并且它工作得很好。然后有一天，我们得到了一笔大笔交易，一次增加300个客户，管理数据库的速度非常快。

品牌化，每个客户都是一个独立的品牌，或者许多客户会共享一个品牌，或者每个人都乐于使用您的公司品牌。理想情况下，您可以通过URL或登录或两者都可以找到品牌资源（css/images/etc）。如果您只需要少数几个品牌，那么为每个品牌设置服务器可能是合理的。

版本控制，是否合理“强制”所有客户同时升级。我强烈建议您尽一切努力使所有客户保持在同一版本，支持多个版本将大幅提升您的支持成本。一般来说，“你总是拥有最新最好的”方面很容易，但有些客户真的不利于改变。可能需要被留下的客户需要在单独的实例上。定制时，它听起来并不像你有这个问题，但是如果你正在向一些客户发送定制版本，那么你将需要每个版本的独立实例，直到你可以创建一个适用于所有人的通用版本为止。

Answer 2

取决于客户数量。起初，您可能会逃避每个虚拟机运行一个实例，但它不像每个实例处理多个客户那样具有可伸缩性。

如果它成为收入的主要来源，那么您一定会想转向该模型。尽管如此，在开始工作之前，如果有大量需求，绝对值得一试。

Answer 3

很难回答这个问题，没有更多的信息，但这些类型的品牌/多归属问题上，一个关键的问题是这样的：

难道这些网站（针对不同的客户）更相似比不同？

现在这是一个主观问题。两个网站有多相似？你能量化吗？不是真的。

但是，如果答案是“他们几乎完全相同”，或者甚至“他们是相同的”（品牌问题尽管），那么请自己帮忙，只举办一个版本的代码，并让这两个网站指向它。

您可以轻松确定调用哪个服务器并相应地更改您的逻辑。

品牌是另一个问题，但如果你已经完成你的应用程序，这应该在很大程度上是一个改变你的CSS包括的问题，可能你的Javascript包括（例如jQuery样式）和（希望最坏的情况下）页脚（你的全球页眉和页脚是否正确？）。

基本上，如果网站非常相似，那么共享代码，只是有什么不同。如果他们完全不同，那么做相反的事情。迎合最常见的情况。

Answer 4

DRY说不，更好地为您的应用添加基于角色的风格，以便您可以更轻松地添加到客户2,3,4等中。

我会花一些时间考虑您的应用中客户的变化以及设计应用成为数据或配置驱动。

Answer 5

这总是一个困难的决定，并且您确定了在每个客户的服务器上安装新实例的主要原因。它不能很好地扩展，并且几乎不可能轻松升级。再加上它不是很SaaS，因为你基本上只需要安装N次软件。

但是还有一个选择。保持数据库不变，并为每个客户安装一个新的数据库实例。但改变你的前端，以便它可以处理多个URL。这样，根据URL，您只需要针对多个数据库运行一个应用程序实例。

这也很好，我认为这是FogBugz模型？然后，如果您的客户想要安装它，则确实没有任何变化，因为它们只有一个指向一个数据库的URL。在你的方面，你将有多个指向多个数据库的URL，只是一旦处理所有这些请求，软件将只运行一次。

同样作为一个很好的，你可能想考虑自定义域。而不是companya.mysoft.com允许companya.com。这不需要你的URL处理有任何真正的改变，公司只需要设置一个CNAME记录并将其指向你的服务器。

好运

Answer 6

“坏的事情是，有很多冗余的，并且可能不具有可扩展性。”

真的吗？冗余在哪里？

如果您使用了一套完善的工具，则您的SaaS安装可以有多个客户站点使用的代码库。

它的工作原理是这样的。

• 在一些基准目录（我们使用的目录如/opt/theApp）中有软件。

• 在某些工作目录中（我们使用目录示例/var/www/cust1,/var/www/cust2），您有一些引用代码的配置文件。

一个代码库，多个安装。在Django（和许多其他Web框架）中，这相对容易。

如果您选择的工具很差，那么一个网站==完整的代码副本，您可能会遇到问题。但是，这是链接的目的。您有客户特定的“副本”包含到基准副本的软链接。

经过努力从“网络安装”和“基准代码”中分离出“客户特定功能”后，您会发现您可以很好地完成QA并提供特定于客户的功能和扩展。

多个实例是更多可扩展。您可以毫不费力地将您的SaaS环境分散到多个并发处理器中。每个客户特定的实例都为客户的数据提供服务，使客户保持分离。他们可以（如果你正确地解决这个问题）都共享一个共同的代码库，安装在一个（并且只有一个）服务器上。

每位客户（使用公共代码库）的单独安装非常令人愉快，可以确保客户的数据不会与其竞争对手的数据混杂在一起。

Answer 7

从数据库角度来看，我肯定会用每个客户模型的一个数据库。能够以独立方式管理每个客户数据的好处是必须的。这种方法允许您随着业务增长将不同的客户数据放到不同的服务器上进行扩展。

此外，您的网站/应用程序服务器应该能够处理您的应用程序的多个实例，为不同的用户和客户提供直接的开箱即用功能。它应该整理一份代码和多个数据段（假设模型仍然保持20年？）。再次，这是可扩展的 - 移动到一个网络农场，并且这一切仍然有效 - 假设您可以对会话进行排序。所以你得到一个双赢，你的代码基地保持几乎相同，并且你得到了你使用的环境提供的可扩展性。您还可以设置不同的版本，供客户试用 - 我们通常会同时运行同一站点的多个版本，因此如果致命的错误使我们遇到新版本，我们可能会回滚。

让这个工作很好的关键是看HTTP头文件并链接配置，即哪个数据库，以及实际指向的软件版本。