Архитектура Tilda и других SaaS сервисов, с привязкой доменов. Как?

Question

[Максим Поспелов]

Хочу разработать онлайн сервис, если кратко - грубо, тильда (конструктор сайтов)на минималках.
Есть большой опыт разной разработки, разработки личных кабинетов, и прочего.

НО клиентские SaaS сервисы, с привязкой доменов для каждого пользователя, пока что не знаю как делать.

Как это организуется с точки зрения архитектуры самого исполняемого кода, БД, и серверной части с привязкой доменов?

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

Поправьте и предложите, если есть варианты другие, или я не прав.

Answer 1

[nekritik]

Я сталкивался с подобными задачами.
Что касается того, как направить/делегировать домены ваших пользователей на ваш будущий конструктор сайтов, тут есть 3 основных способа.
1. Пользователь прописывает для своего домена Ваши NS-сервера, а Вы в настройках своего NS-сервера уже определяете на какой IP будет "резолвиться" домен пользователя.
2. Пользователь прописывает в качестве NS сервера не ваши сервера, в любые другие, на которых он может редактировать cname-записи. В этом случае пользователь создаёт, на прописанных им NS-серверах, cname запись что типа

mysubdomain cname yoursaasserver.ru

в этом примере субдомен mysubdomain будет резолвиться с те же данными что и ваш сервер yoursaasserver.ru
3. Это способ похож на способ номер 2 -пользователь также прописывает сторонние NS-сервера но в настройках самих NS-серверов указывается не cname-запись, а A-запись. То есть, сразу указываться IP вашего сервера.

Если не знаете что такое cname и a-записи, советую разобраться с этим.

Comments

[Максим Поспелов]

Знаю конечно, в тильде пользователь сам прописывает ААА записи у регистратора.

Я уже прихожу к тому, что на уровне нашего сервера можно сделать как угодно. Всмысле есть техническая возможность хоть свой NS поднять, хоть свой DNS и разруливать только AAA записи, а наш сервак будет тыкать нужный домен ( на уровне нашего DNS) в нужную директорию.

[Андрей Андреев]

Почему так сложно?
Нельзя по крону дергать какой-нибудь определенный юрл с секрет параметрами. Типа если все ок и правильный ответ - значит домен делегирован на ваш сервис и все ок, если 404 - значит не делегирован.

Опять-же с каждый запросом будет приходить с какого домена пришел запрос(request.host в рельсах) На основе этого уже работает остальная часть.

Когда-то что подобное делал. Была херова туча доменов делегированных на один DNS/IP а бекенд приложения уже все разрузивал.

Или я не до конца понял вашу проблему?

Answer 2

[nrgian]

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

Первый способ - себестоимость обслуживания и хранения ниже.
Второй способ - себестоимость обслуживания и хранения выше.

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

В чем именно проблема-то?

Comments

[Максим Поспелов]

Это один способ. Разделить функции конструктора, и пользовательских данных.

Проблема с архитектурой в том, что я никогда не сталкивался с серверными настройками и DNS зоной (только как пользователь), а как это делается автоматически?

Я думаю, что у готовых серверов (LAMP, Nginx) есть API, туда подается команда, типа такой домен отнести к такой категории. И через api делается проверка AAA записей, но не уверен что именно так.
А исполняемый код проверяет ответы и выдает пользователю в личном кабинете результат (домен настроен, не настроен, прилинкован).
Нужно узнать у тех, кто занимается серверами. Вот и спрашиваю) Так это или не так.

[nrgian]

Максим Поспелов,

Проблема с архитектурой в том, что я никогда не сталкивался с серверными настройками и DNS зоной (только как пользователь), а как это делается автоматически?

Если домен не делегируют на ваши сервера - то никак.

Если делегирует домен на ваши сервера (или сервера, управляемые вами через API, например, сервера DNS в Google Cloud) или если это домен третьего уровня от вашего домена - то легко.

Что именно вызывает затруднение?

[Максим Поспелов]

Понятно что делегировать надо :D

Проблема в том, что я не знаю, как это автоматизировать, и чем именно, раз ни разу не делал)

[nrgian]

Максим Поспелов,

Проблема в том, что я не знаю, как это автоматизировать, и чем именно, раз ни разу не делал)

Воспользоваться сервером DNS, записями в котором можно управлять по API.

Answer 3

[Иван Шумов]

Вам стоит отложить эту затею лет на 5 - пока вы не станете обладателем соответствующих знаний. Судя по задаче у вас хорошо если есть 5% от необходимого багажа навыков

Comments

[Максим Поспелов]

я же не собираюсь сам это делать, но мне нужно въехать что бы уметь принимать решения

[Иван Шумов]

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

[Максим Поспелов]

Иван Шумов, понимаю о чем Вы говорите, я понимаю что сам не спроектирую, но в целом хочу иметь предмет для обсужедния, понимание как это работает хотя бы поблочно. Что делается на уровне сервера, как программно будет организован конструктор, как хранится данные (в разных или все в одной бд), как файловая система будет устроена. Я сам пишу сложные ТЗ, но связанные с технической архитектурой 1С Битркс, но тут более низкоуровневое программрование, точнее системы. Мне нужно представлять в общем.

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

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

[Иван Шумов]

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

[Максим Поспелов]

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

[Иван Шумов]

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