Правильная ли архитектура облачного сервиса?

Question

[nezzard]

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

Есть две мысли по этому поводу.
- Все данные сайтов клиентов, сохраняются в одной базе, и каждому из них выдаются только его данные по api key. Данный метод самый легкий в реализации, вижу несколько преимуществ и недостатков.

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

- Организовать все через докер контейнер, тогда сразу недостатки из прошлого пункта пропадают, но появляется другой недостаток, это значительное увеличение потребления ресурсов.

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

Answer 1

[Araik]

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

Ссылки:

• habr: Мультитенантная архитектура для SaaS приложений
  
• youtube: (Panda Meetup): Мультитенантная архитектура при проектировании Saa...
  
• youtube: (Александр Белоцерковский)Принципы облачной архитектуры -SaaS, Multi-Tenant
  

не по существу вопроса, но вдруг вам будет интересно

Вообще, разработка SaaS сервиса очень трудоемкая задача, если есть желание скооперироваться, мои контакты в профиле, там же ссылка на сайт проекта:) Мы ищем фронтендера на Vue или React, делаем платформу для электронной коммерции, если будет интересно, напишите любым удобным способом расскажу подробнее

Comments

[nezzard]

Спасибо за ссылки, наткнули на мысли. Хотел бы у вас спросить, смотрю что обычно предлагают 3 варианта реализации базы.
1. база на клиента
2. таблица на клиента
3. колонка в таблице на клиента (tenant_id)

Как я понял, первый вариант самый затратный по ресурсам, 3 вариант самый легкий в реализации.
Собственно минус в 3 варианте, если падает база, то падают все клиенты.
Если базу к примеру mongodb поставить на swarm, чтобы она была более отказоустойчива, по вашему мнению 3 вариант имеет право на существование?

[Araik]

nezzard, Это сильно от проекта зависит, к примеру мы платформу в первую очередь для интернет-магазинов делаем и в нашем случае оптимальным будет, если у каждого клиента будет своя БД. Я бы не сказал, что этот вариант сильно затратный по ресурсам, все же сервер СУБД и База данных это разные вещи.

По поводу Mongo, она вообщем-то достаточно отказоустойчивая, если соблюдать кворум и иметь минимум 3 сервера в кластере

Собственно минус в 3 варианте, если падает база, то падают все клиенты.

Тут важно еще понимать, что упасть может не только база, но и сервер приложения и даже балансер. Рекомендую ознакомиться с видео от Яндекс.Облака Базовые принципы построения отказоустойчивой архит...

Если базу к примеру mongodb поставить на swarm, чтобы она была более отказоустойчива, по вашему мнению 3 вариант имеет право на существование?

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

Answer 2

[Константин Нагибович]

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

Comments

[nezzard]

Поэтому я и думал о контейнере