Создание приложения SaaS с помощью веб-фреймворка Django. Часть 1/2: Принцип

Перейти к профилю Adonis Simo

Адонис СимоЗаблокированоUnblockFollowFollowing

8 января

Программное обеспечение, которое запускается непосредственно в веб-браузере, и пользователи должны платить за него по-разному, например, за час или даже за пользователя и т. д., называется приложением «Программное обеспечение как услуга» (SaaS). С тех пор эта модель очень широко используется стартапами для продажи своих услуг. В этой первой статье мы собираемся узнать об основных принципах этого.


фото Взлом Капитал на Скрыть

Хорошо, начнем, принцип.

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

1. Итак, как на самом деле данные сохраняются в БД, как насчет доступа к ним?

В приложении SaaS каждый экземпляр приложения называется арендатором, поэтому здесь нужно выбрать метод разделения данных правильно:

Способ хранения данных арендатора, обеспечивающий их сохранение без смешивания.

Хорошо, на самом деле это можно сделать прямо в базе данных, обычно есть 3 основных способа разделения хранимых данных, их можно назвать уровнем изоляции данных внутри базы данных. Итак, у нас есть: Низкая изоляция , полуизоляция а также высокая изоляция. Позвольте погрузиться в них, прежде чем начать кодирование.

— Низкая изоляция данных

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

SELECT * FROM 'table_name' WHERE tenant_uuid = 5

или с ORM Джанго:

— Полуизоляция данных

Принцип здесь заключается в том, чтобы сохранить данные в та же база данных, та же таблица, НО разные схемы. Схемы можно рассматривать как базу данных в базе данных, она содержит таблицы из обычной базы данных, и вы можете создавать множество схем, как позволяет вам СУБД, для тех, кто использует PostgreSQL, они используют для работы в схеме по умолчанию с именем: публичный и SQL-запросы к таблице иногда выглядят как

SELECT * from public.table_name

При этом метод полуизоляции заключается в создании новой схемы для новых арендаторов (ваших клиентов, людей, которые используют ваше приложение SaaS), и все созданные схемы содержат одни и те же таблицы. В этом случае данные пользователей не сохраняются в одном и том же месте. Технически они находятся в отдельной таблице (или базах данных). Таким образом, получение данных с помощью ORM похоже на:

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

— Высокий уровень изоляции данных

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

в с использованием() метод (или параметр) напрямую доступен в Django, по умолчанию его значение равно ‘дефолт’; куда найти его? в settings.py файл, в учетных данных базы данных:

DATABASES = {
    'default': {},
    'users': {
        'NAME': 'user_data',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'superS3cret'
    },
    'customers': {
        'NAME': 'customer_data',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_cust',
        'PASSWORD': 'veryPriv@ate'
    }
}

В приведенном выше примере есть 3 базы данных, фактически зарегистрированные по своим псевдонимам: по умолчанию, пользователи, клиенты поэтому по умолчанию (если вы не укажете с использованием()) Джанго выберет дефолт.

2. Как узнать, какой арендатор требуется для конкретного входящего запроса?

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

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

Обычно для этого разработчики используют URL-адрес, добавляя в него некоторые указания. Один из самых простых и элегантных способов сделать это, IMO, — определить поддомен для каждого жилец ; Предположим, что ваше приложение представляет собой движок блога с именем www.bloghost.com у каждого клиента будет поддомен и URL-адрес, указывающий непосредственно на его блог, например: client1.bloghost.comдругой способ — определить параметр url следующим образом: www.bloghost.com/85DE5148WFE848 и этот токен может быть хешем, используемым для идентификации схема | UUID арендатора | база данных связанные с фактическими данными клиента. Это будет полностью зависеть от вас.

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


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

Я Adonis SIMO, мобильный и бэкэнд (начинающий FullStack) разработчик, обычно работаю с JavaScript/Python и React Native. У меня есть ориентация на решения для электронной коммерции, мобильные приложения или веб-платформу, я также умею писать API, модульные тесты и дизайн внутренней инфраструктуры. также участник OpenSource 😉

гитхаб: @simo97 | твиттер: @flux_97 | Симоадонис на gmail.com | www.dev.to/simo97

Хорошо тебе провести время.

Немного полезной ссылки:

Создание мультитенантных приложений с помощью Django — Создание мультитенантных приложений с помощью Django 2.0…
Создание мультитенантных приложений с помощью Djangobooks.agiliq.com

Шаблоны SaaS с несколькими клиентами — База данных SQL Azure
_Узнайте о требованиях и общих шаблонах архитектуры данных многопользовательского программного обеспечения как услуги (SaaS)…_docs.microsoft.com

Полнофункциональное многопользовательское приложение с Laravel, часть 1 — настройка
_Часть 0, Часть 1 👇, Часть 2, Часть 3, Часть 4, Часть 5, Часть 6, Часть 7_medium.com

Привет, приятель, я думаю, что могу тебе помочь. Ты хочешь т… — ДЕВ
_Я создаю SaaS и решил использовать облако, после некоторых исследований, которые я провел o…_dev.to

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *