为多个客户端运行Magento - 单个Installaton与多个安装

时间:2010-06-07 11:21:09

标签: magento

我希望为多个客户设置Magento(社区版)安装,并且已经研究了几天。

我可以看到企业版拥有我需要的东西,但令人惊讶的是我不愿意支付每年12,000美元的订阅费用。

似乎有几个选项可供使用,但我担心我会从各种选项中获得的表现。

选项1)使用AITOC高级权限模块单次安装 所以这就是我所追求的;一个安装,以便我可以同时更新我的​​核心文件,并从一个地方管理我的所有商店用户。这里的问题是我对这个额外产品的可靠性一无所知,而且我需要额外支付一些费用。我也担心,如果我有10个商店在这一个装置上运行,它可能会慢慢减速,因为我听说有关Magento缓慢的故事。

模块链接:http://www.aitoc.com/en/magentomods_advanced_permissions.html

选项2)在每个商店的一台服务器上多次安装Magento 所以在这里我在一台服务器上安装了10个Magento,所有这些都安装得很快,而不是使用任何额外的钱,但我现在有10个独立的商店来更新和维护,这可能很烦人。此外,我还没有找到很多其他人使用这种方法,当我有他们通常会问如何阻止他们的服务器死亡。所以这条路线似乎在我的服务器上可能会更糟,因为我会在我的服务器上运行更多但是如果我的服务器可以接受它,每个Magento安装会更简单,并且由于每个必须运行10而不太可能减速商店本身?

选项3)使用大量服务器和许多Magento安装 我只是不想这样做。

选项4)购买Magento Enterprise 我没有钱这么做。

那么哪条路线不太可能炸毁我的服务器?有没有人有过模块这个圣杯的经验?

感谢您提前阅读并感谢任何帮助 - Chris Hopkins

6 个答案:

答案 0 :(得分:7)

让我们立即取消非选项。你不想做#3而#4是非解决方案。 Magento Enterprise Edition不会添加任何可以让您从一个商店运行多个客户的功能。

现在,可能的选项。正如您所述,#1将允许您更新一个版本的代码,但当然这会带来一些风险。据我了解,您的客户需要访问商店吗?如果您有多个客户在一个数据库和一个代码库上运行,那么您将始终遇到相互影响的问题。例如,谁将控制产品属性,这些属性本质上是全球性的?如果一个商店删除了产品属性,则其他商店可能会丢失数据。如果您解决了这个问题,那么目录促销和产品类别等等.Magento是为处理多个网站而构建的,但不是为了使它们彼此隔离,而您将因此而遇到问题。至于性能,大型产品目录或客户群往往会减慢网站速度,但您可以使用扁平产品目录并充分利用缓存来缓解这种情况。

对于选项#2,您可以运行多个Magento存储,这会带来两个主要问题。首先,正如您所说,正在更新网站。如果您使用的是Magento的vanilla安装而不是修改核心文件,那么这应该是一个非问题。 Magento的更新程序对于那些安装来说非常简单,因为你需要更多的mod并且必须使用更多的手动过程进行升级,因此难度会增加。

就性能而言,运行多个magento站点可能较慢,但这取决于您如何构建它们。无论拥有一个或多个站点,您都必须为每个站点加载数据,因此数据库大小不会有太大差异。服务器上的文件大小几乎不是问题。在任何一种情况下,当客户请求页面时,Magento必须启动整个框架来提供请求,这是性能问题开始显现的地方。对此的一个重要缓解是使用像Xcache这样的操作码缓存,但是对于多台机器,您需要为Xcache提供更多内存来容纳所有安装的代码。合法的问题。

我的推荐?从一台机器开始,多次安装。按照安装次数进行操作,当服务器不再支持时,请继续。将代码更改保留在核心之外,并使用可轻松更新的扩展,以便轻松进行更新。这应该减轻尽可能多的关注。

希望有所帮助!

谢谢, 乔

答案 1 :(得分:2)

我们使用单个代码库处理了几十个magento“installs”,但是使用了多个数据库。基本上我们在创建一个多租户的Magento方面做了大量工作。

以下是我们如何做到这一点:

  1. 使用nginx作为反向代理来处理一些基本的路由规则,并根据请求设置一些服务器变量(fastcgi_params)。
  2. 我们根据请求的域名,浏览器语言和访问者位置将路由规则硬编码到Nginx配置中。
  3. 使用Nginx fastcgi_params将服务器变量设置为“client-id”
  4. 使用app / [client-id] / etc
  5. 的约定制作app / etc文件夹的副本
  6. 将Mage.php变量$ etcDir覆盖为$ etcDir = self :: getRoot()。 DS。 $ _SERVER ['CLIENT_ID']。'/'。 '等等'; (你必须在这里应用一些逻辑,以确保优雅地失败)
  7. 编辑应用程序/ etc / [client-id] /local.xml以指向已导入magento表和基本内容的新数据库。 (您还必须在core_config表中设置URL,或在local.xml文件中设置任何可用的URL)
  8. 在Mage.php中修改app / code / local /的包含路径为app / code / local / [client-id] /(是的,请注意我是否覆盖核心代码,但这是我们找到的唯一方法)
  9. 设置会话处理将在Redis数据库中完成,每个客户端使用db#unique
  10. 在Mage_Core_Model_Config_Options中覆盖getVarDir()以在路径中包含[client-id]。 (这是为了确保您不在客户端之间共享缓存)
  11. 到目前为止,你可能已经获得了要点。

    您需要考虑的其他事项:

    通过client-id隔离媒体, 合并所有“管理面板”网址,并要求管理员用户选择[client-id], 以合理的方式配置清漆, 以合理的方式设置CDN, 修改Magento安装程序以支持此方法,并自动处理基本配置。

答案 2 :(得分:1)

我认为获取vps帐户并在必要时进行扩展会为您提供最佳选择,以满足您的成本要求。

答案 3 :(得分:1)

对于我的两分钱,我认为你会遇到更多问题而不是职业选手,将每个人都投入Magento的单一安装中,每个人都互相碰撞。更不用说网站上的客户X Y似乎无法弄清楚为什么他不能在网站Z上创建他从未去过的帐户(这是配置问题,但可能会发生)

我建议你做的是设置一个git存储库,它安装了你的“基础”Magento,然后让所有客户端都安装在你可以从主安装中克隆的不同版本。

这将只为您提供一个真实的代码库来更新(数据库更改是一个不同的故事),每个人都是独立的。

答案 4 :(得分:0)

我们在单个Magento CE安装上运行多个客户端,并使用AITOC的高级权限模块来控制不同客户端的可见性。该模块运行良好,虽然它有几个小问题,并且在少数领域缺乏功能,我们必须使用我们自己的内部模块来处理。它似乎没有对性能产生任何明显影响,因为我们几个月来一直以这种方式运行它没有任何问题。 (也就是说,我们确实使用Amazon EC2并自动缩放。)

据我了解,EE确实提供了高级角色权限,这会使AITOC的模块无法使用。但是,我也听说EULA for EE每次安装只需要一个客户端。我没有找到关于此的确凿事实,但如果确实如此,它确实是一个交易破坏者,因为为每个客户额外安装EE将会非常昂贵,非常快。 (也许有人可以对此确认是/否?)

答案 5 :(得分:0)

我在研究同一主题时发现了这个主题。我有一个有多个经理的大商店。我想让他们每个人都能访问特定的类别和产品,这样他们就可以只改变它们而且不会改变任何其他东西(不幸的是,我对此有一些不好的经历)。 所以我找到了一些扩展:itoc,advanceworks和amasty。我安装了后者,我非常满意。配置所有用户角色需要一些时间,但肯定会付出代价。