Способ легко масштабировать следующий продукт SaaS? Да, это легко сделать.
Многопользовательское программное обеспечение — это программное обеспечение, в котором один экземпляр приложения обслуживает разных пользователей или группы пользователей (я буду называть их клиентами). Данные каждого клиента логически или физически отделены друг от друга, чтобы избежать утечки данных от одного клиента к другому.

Самое большое программное обеспечение SaaS на сегодняшний день создано с использованием многопользовательского подхода.
Подумайте о Jira или Slack, каждая рабочая область независима от других, и нет возможности просмотреть данные других рабочих областей в своей.

Основные характеристики мультитенантного программного обеспечения

Мы можем рассмотреть 3 основные характеристики:

  • Снижение затрат
  • Единая точка развертывания
  • Простое обслуживание

Снижение затрат
Если вы начинаете с нуля, вы можете легко снизить затраты, поскольку на все запросы клиентов всегда отвечает один и тот же экземпляр приложения. Таким образом, вам не нужно развертывать один и тот же код для каждого регистрирующегося клиента, а это означает отсутствие затрат на развертывание и потери ресурсов (в докеризованной среде подумайте о развертывании только одного контейнера вместо контейнера для каждого клиента).

Единая точка развертывания
Весь ваш код находится в одном пространстве. Вам не нужно дублировать его при регистрации нового клиента. Это упрощает процесс CI/CD: вам нужно заботиться об одном экземпляре кода.

Простота обслуживания
Как и в предыдущем пункте, поскольку ваш код находится в одном месте, вам нужно коснуться его только один раз, чтобы устранить ошибку или создать новые функции.

Как к этому подойти?

Существует два способа создания мультитенантного программного обеспечения:

  • Единая база данных:
    все данные вашего клиента находятся в одном экземпляре базы данных, разделенном столбцом, который идентифицирует клиента/арендатора (например, tenant_id );
  • Несколько баз данных:
    У каждого клиента есть свой экземпляр базы данных, который может быть другой схемой или совершенно новым сервером: решать вам;

Подход к единой базе данных

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

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

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

против этого подхода:

  • Добавьте оператор «где» во все запросы или область видимости в модели;
  • Если вы используете сторонний пакет внутри существующего проекта, вам нужно будет изменить БД и модели;
  • Вы не можете легко масштабироваться по горизонтали на нескольких серверах, не вводя «шард» с самого начала;
  • Может быть сложно экспортировать или удалить все данные конкретного клиента.

Подход с несколькими базами данных

Используя этот метод, вы создадите новый экземпляр или схему БД для каждого регистрирующегося клиента.

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

Таким образом вы устанавливаете пакет, настраиваете его, и все готово: никаких изменений в ваших запросах или ваших моделях.

Существует множество сторонних пакетов, которые помогут вам все настроить. Чтобы найти его, обычно достаточно поискать в Google «мультитенантность {ваш фреймворк}».

Основные плюсы этого подхода касаются безопасности данных:

  • Все клиентские данные находятся в отдельном экземпляре БД, поэтому меньше вероятность показать чужие данные;
  • Экспортировать все данные клиента проще, просто дамп и готово;

Улучшается даже масштабируемость:

  • Данные клиента стали слишком тяжелыми по сравнению с другими клиентами? Ставь на другой сервер!
  • Наличие разных клиентских БД на нескольких серверах повышает отказоустойчивость: сервер выходит из строя? Затрагивается только этот конкретный клиент.

Переносимость данных:

  • Как уже говорилось, экспортировать проще, просто запросите клиентскую БД;
  • Резервное копирование может выполняться для каждого клиента (арендатора), а восстановление может выполняться для каждого арендатора;
  • Корпоративные клиенты могут иметь свою локальную версию;
  • Данные клиента можно легко удалить: просто удалите экземпляр БД;
  • Вы можете выбрать, где разместить БД, чтобы быть «ближе» к вашим клиентам или в соответствии с требованиями законодательства (см. GDPR);

Дополнительные примечания

Как разработчик Laravel, я только что создал продукт SaaS для клиента.
Я создаю руководство о том, как настроить многопользовательскую среду с помощью Laravel и какие пакеты доступны.
Я опубликую ссылку здесь, когда она будет готова.
Если вы заинтересованы, подпишите форму внизу, и я предупрежу вас.
Спасибо!