Программное обеспечение, которое запускается непосредственно в веб-браузере, и пользователи должны платить за него по-разному, например, за час, даже за пользователя и т. Д.… Называется приложением «Программное обеспечение как услуга» (SaaS). С тех пор эта модель очень широко используется стартапами для продажи своих услуг. В этой первой статье мы узнаем об основных принципах этого.
Хорошо, приступим, принцип.
На самом деле, исходя из моего небольшого опыта, когда я говорю о дизайне приложений и инфраструктуре SaaS, говоря об управлении данными, я имею в виду такие вопросы, как как хранить данные в базе данных? как получить к ним доступ? Какую базу данных следует использовать? Как отправить входящий запрос на нужную версию приложения? и так далее. В глобальном масштабе концепция состоит в том, чтобы разрешить существование множества версий одного и того же приложения, каждый экземпляр должен отображать только свои данные и управлять только его клиентами.
1. Итак, как данные фактически сохраняются в БД, как насчет доступа к ним?
В приложении SaaS каждый экземпляр приложения называется арендатором, поэтому дело здесь заключается в правильном выборе метода разделения данных:
Способ хранения данных клиента, гарантируя, что они сохраняются без смешивания.
Хорошо, на самом деле это можно сделать прямо в базе данных, обычно есть 3 основных способа разделения хранимых данных, их можно назвать уровнем изоляции данных в базе данных. Итак, мы имеем: Низкая изоляция, полуизоляция и высокая изоляция. Давайте погрузимся в них, прежде чем начинать кодирование.
- Низкая изоляция данных
Принцип здесь состоит в том, чтобы хранить данные клиента в одной базе данных и в одних и тех же таблицах. Итак, вы находитесь в случае, когда каждая таблица имеет имя столбца, например, поскольку tenant_uuid этот столбец содержит уникальный идентификатор для клиента, а в вашей базе данных есть таблица с именем, например, как: tenants, она должна хранить информацию о каждом арендаторе, например : name, uuid, registration_date, status, pricing_plan_id и т. д. В этом случае для всех запросов к базе данных вам нужно будет добавить оператор, чтобы гарантировать, что вы получаете данные правильного клиента, например:
SELECT * FROM 'table_name' WHERE tenant_uuid = 5
или с помощью ORM Django:
- Полуизоляция данных
Принцип здесь заключается в том, чтобы сохранять данные в той же базе данных, той же таблице, НО разных схемах. Схемы можно рассматривать как базу данных в базе данных, она содержит таблицы как обычную базу данных, и вы можете создавать множество схем, которые позволяет вам СУБД, для тех, кто использует PostgreSQL, они используют для работы в схеме по умолчанию с именем: общедоступные и SQL-запросы к таблице иногда выглядят так
SELECT * from public.table_name
При этом метод полуизоляции заключается в создании новой схемы для новых клиентов (ваших клиентов, людей, которые используют ваше приложение SaaS), и все созданные схемы содержат одни и те же таблицы. В этом случае данные пользователей не сохраняются в одном месте. Технически они находятся в отдельной таблице (или базах данных). Итак, получение данных с помощью ORM похоже на:
мы предполагаем, что существует маршрутизатор базы данных, который отвечает за выбор правильных схем для выполнения запроса. Мы настроим его в следующей части этой серии статей.
- Высокий уровень изоляции данных
Принцип здесь состоит в том, чтобы сохранить данные клиента в разных базах данных. В этом случае, когда у вас есть новый клиент, вы просто создадите новую пустую базу данных для хранения данных. Вот почему мы говорим о высокой изоляции, база данных может быть даже уничтожена, но это затронет только один клиент, но это может быть очень тяжелым с точки зрения потребления ресурсов. Доступ к данным с помощью Django ORM можно сделать следующим образом:
метод (или параметр) using () напрямую доступен в Django, по умолчанию его значение ‘default’; где его найти? В файле 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 базы данных, фактически зарегистрированные под их псевдонимами: по умолчанию, пользователи, клиенты, поэтому по умолчанию (если вы не укажете using ()) django выберет по умолчанию.
2. Как узнать, какой арендатор требуется для конкретного входящего запроса?
Входящий запрос представляет здесь пользователя вашего приложения, который подключен через браузер и собирается использовать приложение. Дело здесь в том, чтобы определить так называемую стратегию обнаружения арендатора;
Это правильный способ узнать, как взаимодействовать с данными, хранящимися в базе данных, на самом деле это не связано с уровнем изоляции, который вы реализовали в своем приложении, результатом этой операции является имя схемы (в случае среднего уровня изоляции) или uuid клиента (в случае низкого уровня изоляции) или база данных (в случае высокого уровня изоляции) для использования для данных поиск.
Обычно для этого разработчики используют URL-адрес, добавляя в него некоторые указания. Один из самых простых и элегантных способов сделать это IMO - определить субдомен для каждого клиента; Предположим, что ваше приложение представляет собой движок блога с именем www.bloghost.com, у каждого клиента будет поддомен и URL-адрес, указывающий непосредственно на его блог, например: client1.bloghost.com , другой способ - определить параметр url следующим образом: www.bloghost.com/85DE5148WFE848, и этот токен может быть хешем, используемым для идентификации схемы | uuid арендатора | база данных, относящаяся к фактическим данным клиента. Это будет полностью зависеть от вас.
Теперь, когда вы определили, какой клиент нацелен на запрос, вам просто нужно будет использовать соответствующий запрос к базе данных. Вы даже можете добиться этого с помощью файлов cookie. В этой статье я не буду заходить слишком далеко об этом, потому что пакет Django, который мы собираемся использовать, будет обрабатывать этот процесс за нас, поэтому я просто попытался объяснить концепцию.
Спасибо, что прочитали эту первую часть, это было просто о том, чтобы узнать, как это работает, и общие термины, используемые в этом мире. Следующая статья будет более практичной.
Я Адонис СИМО, разработчик мобильных приложений и backend (начинающий FullStack), обычно работаю на JavaScript / Python и React Native. У меня есть ориентация на решения для электронной коммерции, мобильные приложения или веб-платформу, я также хорошо разбираюсь в написании API-интерфейсов, модульных тестах и проектировании внутренней инфраструктуры. Также участник OpenSource;)
github: @ simo97 | twitter: @ flux_97 | simoadonis НА gmail.com | www.dev.to/simo97
Хорошо тебе провести время.
Некоторая полезная ссылка:
Эта история публикуется в Noteworthy, куда ежедневно приходят более 10 000 читателей, чтобы узнать о людях и идеях, формирующих наши любимые продукты.
Подпишитесь на нашу публикацию, чтобы увидеть больше историй о продуктах и дизайне, представленных командой Journal.
