Запуск Magento для нескольких клиентов - одна установка против нескольких установок

Question

Я хочу установить установку Magento (Community Edition) для нескольких клиентов и уже несколько дней исследую этот вопрос.

Я вижу, что в Enterprise Edition есть то, что мне нужно, но, что удивительно, я не хочу выкладывать лишнюю годовую подписку в размере 12 000 долларов.

Кажется, есть несколько доступных вариантов, но я беспокоюсь о производительности, которую я получу из различных вариантов.

Вариант 1) Однократная установка с использованием модуля расширенных разрешений AITOC Так что это действительно то, что я после; одна установка, чтобы я мог обновлять все основные файлы одновременно, а также управлять всеми пользователями своего магазина из одного места. Проблема здесь в том, что я ничего не знаю о надежности этого дополнительного продукта и что мне нужно немного доплатить. Я также обеспокоен тем, что, если у меня будет 10 магазинов, работающих на этой одной установке, все это может сильно замедлиться и упасть, как я уже много слышал о медлительности Magento.

Ссылка на модуль: http://www.aitoc.com/en/magentomods_advanced_permissions.html

Вариант 2) Несколько установок Magento на одном сервере для каждого магазина Итак, у меня есть 10 установок Magento на одном сервере, и все они успешно работают без дополнительных затрат, но теперь у меня есть 10 отдельных хранилищ для обновления и обслуживания, что может раздражать. Кроме того, я не смог найти множество других людей, использующих этот метод, и когда они у меня есть, они обычно спрашивают, как остановить смерть на своих серверах. Таким образом, кажется, что этот маршрут может быть еще хуже на моем сервере, так как на моем сервере будет происходить больше, но если бы мой сервер мог его принять, каждая установка Magento была бы проще и с меньшей вероятностью замедлялась бы из-за того, что каждый должен был запускаться. магазины самостоятельно?

Вариант 3) Использование большого количества серверов и множества установок Magento Я просто так не хочу этого делать.

Вариант 4) Купить Magento Enterprise У меня нет денег, чтобы сделать это.

Так какой маршрут с меньшей вероятностью взорвет мой сервер? И есть ли у кого-нибудь опыт работы с этим святым Граалем модуля?

Спасибо за чтение и заранее спасибо за любую помощь - Крис Хопкинс

Answer 1

Давайте сразу же уберем без вариантов. Вы не хотите делать № 3 и № 4 не является решением. Magento Enterprise Edition не добавляет никаких функций, которые позволят вам запускать несколько клиентов из одного магазина.

Теперь рассмотрим возможные варианты. Как вы утверждаете, # 1 позволит вам обновить одну версию кода, но, конечно, это сопряжено с некоторыми рисками. Насколько я понимаю, вашим покупателям понадобится доступ в магазины? Если у вас есть несколько клиентов, работающих с одной базой данных и одной кодовой базой, у вас всегда будут проблемы с ними, влияющие друг на друга. Например, кто будет контролировать атрибуты продукта, которые по своей природе являются глобальными? Если один магазин удаляет атрибут продукта, другие магазины могут потерять данные в результате. Если вы решите эту проблему, как насчет продвижения по каталогу и категорий продуктов и т. Д. Magento был создан для работы с несколькими веб-сайтами, а не для того, чтобы изолировать их друг от друга, и из-за этого у вас будут проблемы. Что касается производительности, большой каталог продуктов или клиентская база будут иметь тенденцию замедлять работу сайта, но вы можете уменьшить это, используя плоский каталог продуктов и эффективно используя кэширование.

Для варианта № 2 вы можете запустить несколько магазинов Magento, что вызывает две основные проблемы. Во-первых, как вы заявляете, это обновление сайтов. Если вы используете ванильную установку Magento и не изменяете файлы ядра, это должно быть не выпуском. Средство обновления Magento довольно простое для этих установок, с трудностями увеличивается, так как вы делаете больше модов и вам приходится использовать больше ручных процессов для обновления.

Что касается производительности, запуск нескольких сайтов magento может быть медленнее, но это зависит от их структуры. Независимо от наличия одного или нескольких сайтов, вам придется загружать данные для каждого сайта, поэтому размер базы данных не будет сильно отличаться. Размер файла на сервере в значительной степени не является проблемой. В любом случае, когда клиент запрашивает страницу, Magento должен ускорить всю инфраструктуру, чтобы удовлетворить запрос, и именно здесь начинают проявляться проблемы с производительностью. Одним из основных способов смягчения этой проблемы является использование кэша кода операции, такого как Xcache, но на нескольких машинах вам нужно выделить Xcache гораздо больше памяти для хранения всего кода установки. Законная проблема.

Моя рекомендация? Запуск на одной машине, несколько установок. Увеличьте количество установок, а когда сервер больше не поддерживает, двигайтесь дальше. Не допускайте изменений кода в ядре и используйте расширения, которые можно легко обновить, чтобы обновления были простыми Это должно смягчить как можно больше проблем.

Надеюсь, это поможет!

Спасибо, Джо

Answer 2

Мы выполняем несколько десятков «установок» magento, используя одну базу кода, но несколько баз данных. По сути, мы проделали грубую работу по созданию мультитенантного Magento.

Вот как мы это делаем:

1. Используйте nginx в качестве обратного прокси-сервера для обработки некоторых основных правил маршрутизации и для установки некоторых серверных переменных (fastcgi_params) на основе запроса.
2. Мы жестко прописываем правила маршрутизации в Nginx Config на основе запрашиваемого домена, языка браузера и местоположения посетителя.
3. Установить переменную сервера, используя Nginx fastcgi_params в качестве "client-id"
4. Создайте копии папки app / etc с условным обозначением app / [client-id] / etc
5. переопределить переменную Mage.php $ etcDir в $ etcDir = self :: getRoot (). DS $ _SERVER ['CLIENT_ID']. '/'. 'так далее'; (Вы должны будете применить некоторую логику здесь, чтобы гарантировать, что это может элегантно провалиться)
6. Измените app / etc / [client-id] /local.xml, чтобы он указывал на новую базу данных с уже импортированными таблицами magento и базовым содержимым. (Вам также нужно установить URL в таблице core_config или в файле local.xml, чтобы все работало)
7. Измените путь включения app / code / local / в app / code / local / [client-id] / / в Mage.php (да, застрелите меня за переопределение основного кода, но это единственный способ найти )
8. Настройка обработки сеанса выполняется в базе данных Redis с уникальным значением db # для каждого клиента
9. Переопределите getVarDir () в Mage_Core_Model_Config_Options, чтобы включить [client-id] в путь. (Это сделано для того, чтобы вы не делили кеш между клиентами)

Возможно, вы до сих пор понимаете суть.

Другие вещи, которые вы хотите рассмотреть:

Изоляция медиа по идентификатору клиента, Консолидация всех URL-адресов «Панели администратора» и просьба администратора выбрать [идентификатор клиента], Конфигурирование Varnish разумным способом Настройка CDN разумным способом, Изменение установщика Magento для поддержки этого метода и автоматической обработки базовой конфигурации.

Answer 3

Для моих двух центов я думаю, что вы столкнетесь с большим количеством проблем, чем профессионалы, бросив всех в одну установку Magento, где все столкнутся друг с другом.Не говоря уже о клиенте X на веб-сайте Y, кажется, не может понять, почему он не может создать учетную запись на веб-сайте Z, к которой он никогда раньше не обращался (это проблема конфигурации, но это может произойти)

ЧтоЯ бы порекомендовал вам установить репозиторий git с вашей «базовой» установкой Magento, а затем настроить все ваши клиенты на разные версии, которые вы могли бы клонировать из этой основной установки.

Это даст вам только один реальныйкод базы для обновления (изменения в базе данных - это отдельная история), и каждый отдельный.

Answer 4

Я думаю, что получение учетной записи vps и ее масштабирование по мере необходимости даст вам лучшие варианты для ваших требований к стоимости.

Answer 5

Я нашел эту тему, исследуя ту же тему. У меня большой магазин с несколькими менеджерами. Я хотел дать доступ каждому из них к определенным категориям и продуктам, чтобы они могли изменять только их и не могли изменить что-либо еще (к сожалению, у меня есть некоторый плохой опыт по этому поводу). Таким образом, я нашел несколько расширений: те, что у itoc, работа впереди и изумление. Я установил последний, и я вполне доволен. настройка всех ролей пользователей занимает некоторое время, но это определенно оправдывает себя.

Answer 6

Мы запускаем несколько клиентов на одной установке Magento CE и используем модуль расширенных разрешений AITOC для контроля видимости для наших различных клиентов. Модуль работает хорошо, хотя он имеет несколько сбоев и не обладает функциональностью в нескольких областях, с которыми нам приходилось работать с нашими собственными внутренними модулями. Похоже, что это не оказывает какого-либо заметного влияния на производительность, так как мы работали так уже несколько месяцев без каких-либо проблем. (Тем не менее, мы используем Amazon EC2 и автоматическое масштабирование.)

Насколько я понимаю, EE предоставляет расширенные разрешения ролей, которые делают модуль AITOC бесполезным. Тем не менее, я также слышал, что для EULA для EE требуется только 1 клиент на установку. Я не смог найти убедительных фактов по этому поводу, но если это правда, то это действительно прерыватель сделки, поскольку дополнительная установка EE для каждого клиента будет чрезвычайно дорогой, чрезвычайно быстрой. (Может быть, кто-то может подтвердить да / нет на это, хотя?)