多个应用实例 - 每个客户一个？ [英] Multiple Instances for Applications-- One for each customer?

问题描述

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

I am thinking about offering my product as a service-- delivered via online. Currently it's a shrink-wrapped software that users download to their servers and run on their servers-- like fogbugz.

在我的新商业模式中，我将提供两种业务模式，一种是用户在其服务器上安装的传统收缩包装软件，并进行所有维护，升级的东西另一个是软件即服务（SaaS）类型，其中托管在我的服务器上完成，用户被给予一个单一的URL来登录。当然，每个客户帐户都将有一个唯一的URL，如companya.mysoft.com，companyb.mysoft.com。

In my new business model, I will offer two business mode, one is the traditional shrink-wrapped software that users install on their servers -- and do all the maintenance, upgrade stuff. Another is the Software as a Service(SaaS) type, where the hosting is done on my servers, and users are given a single URL to logon. Of course, each customer account will have a unique URL, such as companya.mysoft.com, companyb.mysoft.com.

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

The question now is since I already have an existing codebase, I want to do minimum modification to my code so that it supports two modes of business. For the SaaS mode, I want create multiple instances for the application-- one for each customer. So each customer will have their own databases, their own applications. All of the customer databases and apps are located on my server. The good thing is that I don't have to change my code at all. The bad thing is that there are a lot of redundancy, and may not be scalable.

您对这种多重实例（one-for-each-customer）有什么看法？或者我必须修改我的代码，以便支持两种模式（易于维护和升级）？

What do you think about this multiple-instance-one-for-each-customer? Or I must modify my code so that both modes are supported ( easy to maintained and for upgrades)?

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

The download version is needed, there is no way to avoid this.

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

Edit 2: My App is a PHP app.

推荐答案

每个客户的完整实例将在您的客户群增长时创建维护噩梦。但是，您可能会开始使用SaaS业务。请注意，成功可能意味着应用程序的一些重新架构可以更好地扩展。

A complete instance per customer will create maintenance nightmares as your customer base grows. But it may work to get you started in the SaaS business. Be aware that success will likely mean some re-architecting of the application to scale better.

需要考虑的重要细节包括：

Important details to consider include:

数据隔离是非常重要的，维护和升级数千个单独的数据库涉及很多开销。一个共同的担忧是，客户会担心他们的数据与其他人混在一起，而且它的安全性不太好。我曾为提供SaaS模式的三家不同的公司工作，数据混合并不是客户关注的问题。在一天结束的时候，你将拥有所有的数据，它将会或不会是安全的，使用多少个dbs并不重要。除非您不能拥有超过几十个客户，否则我强烈建议将多个客户整合到一个数据库中，并支持多个dbs，这样可以更轻松地管理数据库。我已经在一个系统上运行了几个PetaBytes数据，为80多万个客户分布在数十个数据库中，这是非常易于管理的。我已经使用一个系统，几个TeraBytes数据的数据，几十个客户，每个都有自己的数据库，它的工作相当不错。那么有一天，我们得到了一个很大的帮助，同时添加了300个客户，管理数据库的速度非常快。

Data segregation, is very important, maintaining and upgrading thousands of individual databases involves a lot of overhead. A common concern is that customers will worry that their data is mixed with someone else's and it is somehow less secure. I have worked for three different companies that offered a SaaS model and data mixing wasn't ever a customer concern. At the end of the day you will have all the data and it will or won't be secure, it doesn't really matter how many dbs you use. Unless you could never have more than a few dozen customers I highly recommend consolidating multiple customers into a single DB, and supporting multiple dbs, it makes managing the databases much easier. I have worked with a system with several PetaBytes of data for >80k customers spread across a couple dozen databases, and it was quite manageable. I have worked with a system with a few TeraBytes of data for several dozen customers each with their own DB and it worked pretty well. Then one day we got a big deal that added 300 customers all at once and managing the databases got awkward very fast.

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

Branding, is every customer a seperate brand, or will many customers share a brand, or is everyone happy to use your companies brand. Ideally you can locate brand resources (css/images/etc.) by URL or login, or probably both. If you will only ever need a handful of brands it may be reasonable to setup servers for each brand.

版本控制是否合理，强制所有客户升级同一时间。我强烈建议您尽全力保持所有客户在同一版本，支持多个版本将大大提升您的支持成本。一般来说，很容易旋转你总是拥有最新最大的方面，但有些客户真的不利于改变。可能需要被遗忘的客户需要在单独的实例上。

Versioning, is it reasonable to "force" all customers to upgrade at the same time. I highly advise you do everything in your power to keep all customers on the same release, supporting multiple releases will drive your support costs up substantially. Generally it is easy to spin the "you always have the latest and greatest" facet, but some customers are really adverse to change. Customers that may need to be left behind will need to be on seperate instances.

自定义，这听起来不像你有这个问题，但如果您目前正在运送定制构建给一些客户，您将需要为每个构建单独的实例，直到您可以创建适用于所有人的通用构建。

Customization, it doesn't sound like you have this problem, but if you are currently shipping custom builds to some customers, you will need separate instances for each build until you can create a universal build that works for everyone.

这篇关于多个应用实例 - 每个客户一个？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！