SAAS и Multi-аренда в Symfony2?

Я использую Symfony уже около 2 лет, до сих пор каждый проект, который я создаю, развертывается специально для каждого клиента (например, один клиент, одна база кода, один db).

Допустим, у меня есть приложение для управления проектами, которое я хочу развернуть для многих клиентов. Предполагая, что клиенты будут работать с любыми функциями, которые я встраиваю в систему, если я разворачиваю разную базу кода (следовательно, другую db) для каждого клиента, вот о каких проблемах я предвижу:

  • Нажатие исправлений ошибок и обновлений будет болезненным. Мне нужно нажать его в каждый репозиторий, который я развернул. Он не будет хорошо масштабироваться, если у меня будет 50 клиентов, использующих это приложение.

  • Менеджмент болезнен. Как я могу создать систему администратора для себя, где я могу вытащить ВСЕ проекты в одну таблицу HTML? В конце концов, у каждого клиента есть своя база данных, верно? Для меня что-то значимое со всеми записями всех моих клиентов, мне нужен способ просмотреть все свои базы данных за один раз, что... Я не думаю, что Symfony разрешает. (Я не уверен)

  • Проблемы с учетной записью пользователя. Если пользователь работает для нескольких компаний, все они используют мое приложение для управления проектами, этот пользователь должен зарегистрироваться несколько раз. (Я знаю, что это можно обойти, если я использую oauth, но я стараюсь не туда, если могу)

Вот решения, которые я придумал и попытался в определенной степени.

Решение 1

Одна база данных и одна кодовая база для ВСЕХ моих клиентов. Проекты будут проходить под одной таблицей, счета-фактуры идут под одной таблицей, все они отмечены их собственным client_id. Пользователи могут быть назначены для проектов, поэтому нет необходимости подписываться несколько раз.

Это не так сложно создать. Но что произойдет, если разные клиенты нуждаются в разных столбцах для своих счетов-фактур? Таблица My Invoice будет продолжать расширяться (с разными полями, которые нужны разным клиентам), и каждая строка может содержать много нулевых полей. Не говоря уже о том, что мой объект счета будет расти в размере файла, и мне придется обновлять схему базы данных каждый раз, когда появляется новая настройка.

Решение 2

Одна база данных, где каждый клиент имеет собственный префикс таблицы. Поэтому для клиента A я мог бы использовать clientA_projects, clientA_invoices, clientA_configuration и т.д.

Это идеально, если каждый клиент хочет настроить свои поля. Но означает ли это, что мне нужно создать новые классы сущностей и форм для каждого нового клиента, входящего в систему? Похоже, что с этим решением мне нужно обновить схему базы данных каждым новым клиентом, который я получаю.

В настоящее время я экспериментирую с базами данных без схем (монго и кушеткой), надеясь, что без необходимости заранее указывать схему таблицы, я могу без проблем реализовать решение 1. Но я все еще экспериментирую, и есть способы пойти, прежде чем осмелиться развернуть готовое к производству приложение, не знакомое с проблемами монго и кушетки с Symfony.

Итак, вот где я застрял. Будучи самообразованным программистом, я чувствую, что у меня много явных знаний, требующих заполнения (в отличие от кого-то из CS-фона). В Интернете не так много мест, рассказывающих о Symfony 2 и многопользовательской аренде (возможно, я искал неправильную вещь). Если кто-то может указать мне на более ясное направление, может быть, лучшие практики, примеры проектов, я буду очень благодарен!

Btw, я планирую выполнить это в последней версии Symfony (2.3.2 в данный момент).

Спасибо заранее, ребята.

Ответы

Ответ 1

Я также использую Symfony2 за аналогичное количество времени (с одной из BETAs), и я советую вам пойти с решением №1. Если вы собираетесь SaaS, вы не можете выдавать код клиентам по причинам, которые вы написали (проблемы с обновлениями/обновлениями в основном). Вся проблема будет в управлении пользователями - у какого пользователя есть доступ к каким данным, принадлежит к какой группе, компании и т.д. Все остальное, если все сделано правильно, будет закодировано таким же образом, как и агностик. Что вы должны делать с различными требованиями для разных компаний? Сделайте такие функции configurable. Вы можете реализовать это на разных уровнях:

  • простые атрибуты сущностей: иметь поле attributes в каждой таблице и сохранять все как JSON, YAML или другой динамически структурированный контент,
  • общая конфигурация: есть одно место, где хранится базовая конфигурация объекта (в средствах, которые я написал выше) и позволяет пользователям управлять новыми функциями оттуда, все изменения распространяются на простые объекты,
  • реализовать то, что я называю Entity Parameters Pattern - создавать таблицы базы данных, которые будут содержать типы параметров, значения параметров и отношение к другим объектам на разных уровнях, а затем создавать общие настраиваемые типы параметров, которые могут применяться в любом месте с предопределенным значением. Например, "preferred_season" является параметром типа "choice_string", содержащим конфигурацию "spring, лето, осень, зима" и при прикреплении к данному объекту всегда будет отображать поле <select> с вариантами выбора и сохранять выбранное значение по отношению к обоим сущность и тип параметра.

Кроме того, решение № 1 имеет одно непревзойденное преимущество - он может обрабатывать больше одной компании, даже если вы хотите выдать код в конце. Вам просто нужно замаскировать способность добавлять больше.:)

Этот вопрос помечен Symfony2, но это действительно не должно. Неважно, какие рамки вы используете, вы должны абстрагировать свой дизайн приложения от кода, а затем использовать фреймворки как простой инструмент для выполнения работы плавно. Я бы хотел сказать, что даже принимая во внимание предыдущее предложение, я абсолютно влюблен в Symfony2.:)

Ответ 2

Я знаю, что это более старый вопрос, но может быть полезен для других.

Я согласен с @Tomasz и решением №1 с one database - всеми арендаторами в одной базе данных. Самой большой проблемой здесь является правильная разработка базы данных для решения дальнейших проблем безопасности: доступ к ресурсам должен контролироваться приложением для предотвращения несанкционированного доступа между арендаторами. С другой стороны, у нас есть облегченная реализация, поскольку мы реализуем одно приложение только с одной базой данных.

Хорошая статья о Symfony2 и переход к модели SaaS: http://www.browserlondon.com/blog/2015/01/moving-to-a-saas-model-with-symfony2/

Также "должна прочитать" статью о разработке базы данных в платформе SaaS - шаблоны, независимые от платформы: http://labs.octivi.com/database-design-in-saas-platforms/