Вопрос по организации saas сервиса

Есть такая дилема.
Есть некая складская програма на PHP/Mysql

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

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

Второй вариант — при создании аккаунта клиента ему создается своя копия сайта со своей копией БД как это делается на шаред хостингах. Создается автоматом каким нибудь скриптом на shell или как там.

у кого какой опыт, как вообще обычно делают в этих саасах типа битрикса или моегосклада?

Экспериментировать с этим не очень охота — вопрос больше админский а не програмистский но заказчик пристал как банный лист и все норовит денег дать.

Теми: SaaS

Ctrl + Enter

Anton Martynenko Tech Lead 18.11.2018 14:05

Проблема очень известная — MultiTenancy vs SingleTenancy.

На самом деле простого ответа нет. Иногда лучше одно, иногда другое.

Если делаешь b2b SaaS то лучше начинать с MultiTenancy (то есть все клиенты в одной базе и на одном апп сервере). Так дешевле и проще администрировать вначале. Просто заранее сделай колонку в каждой табличке — TenantId. Если будешь хорошо расти — в будущем сможешь перейти на Single Tenant или Hybrid модель при необходимости.

SingleTenancy будет точно дороже по инфраструктуре (отдельная база + сервер на каждого клиента), но дешевле в разработке — можно будет запустить приложение «как есть» с минимальными изменениями в коде.

Зачем поддомены на каждого клиента? Вместо client-foo-bar.saas.com/app можно просто сделать saas.com/client-foo-bar/app или даже saas.com/app — клиенский айди можно из куки или хедера вытащить. Если нужен раутинг на разные сервера — можно использовать level 7 load balancer. В одной из компаний где я работал было 1500 поддоменов — не очень удобно я вам скажу, лучше уж без них

Відповісти

Підтримати

Леонид Мартынюк инженер-программист в 1World online R&D Сenter 18.11.2018 16:12

(отдельная база + сервер на каждого клиента),

сервер тот же один екземпляр апача- сайт отдельный

Зачем поддомены на каждого клиента?

заказчик говорит что liqpay требует отдельного адреса сайта для клиента

Anton Martynenko

Max Tikhomirov CEO в BOOKKEEPER 25.11.2018 21:50

Возьмите не Ликпэй, а другое решение. И по комису дешевле будет.

Леонид Мартынюк

Max Tikhomirov CEO в BOOKKEEPER 25.11.2018 21:49

+++ за MultiTenancy
В нашем SaaS уже в районе тысячи клиентов сидит, инфраструктура стоит копейки.

Yuriy Gerasimov Lead Developer в ImageX 17.11.2018 21:29

Леонид, тут наверное стоит принимать решение на основании бизнес прогноза. Если речь идет о «мы планируем добавить 20 клиентов в течении следующего года» — то конечно же отдельные хосты и шел скрипт (а можно и руками поднимать и с шел скриптом не заморачиваться). Если — у нас в очереди 100 компаний, то стоит думать об оптимизации процесса. Сначала в любом случае стоит делать то, что не масштабируется. Ну нужно со старта думать об идеальном решении.

Gennady Dogaev full-stack web developer (freelance) 17.11.2018 18:08

Ну чтобы попроще — второй вариант конечно

Bogdan Shyiak SE or Dev 17.11.2018 12:19

Правильный ответ зависит от многих факторов, например от ожидаемого количества клиентов. Гуглить надо по словам «Multi-tenancy strategies».

Все клиенты сервиса живут в одной БД

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

при создании аккаунта клиента ему создается своя копия сайта

Меньше гемора (особенно если использовать клауд решения), но будет очень дорого при росте количества клиентов (сколько будете тратить при наличии 100 клиентов?). Упрощает удаление аккаунтов при наличии такх требований.

Есть еще стд вариант № 3 одна БД, но у каждого клиента своя схема. Тут так же есть свои плюсы и минусы.

anonymous 17.11.2018 12:02

Тащить все на AWS (RedShift+Route53) .
Но ну его нафиг

Олексій Пєніє 16.11.2018 21:10

Вариант № 0: послать их всеъх к монахам, пусть купят себе Битрикс. Нормальных денег тебе за это не дадут в жизни. А требования будут как к системе, которую разрабатывает целая компания добрых десяток лет. И никогда по-другому не будет в заказах «как воон-там, но в 100 раз дешевле».

Если хочешь играться и дать заказчику лососнуть тунца — делай. Но только ПОЧАСОВО. И никаких бесплатных доработок, даже запятую поправить. Аргумент назови сразу: он хочет оригинальный продукт по цене дешевле простой копии. Хотеть не вредно.

Как сделать.
1) Однозначно поддомен (звёздочкой перенаправить на свой сервак не проблема, как и ответвить в другое место).
2) Однозначно своя база каждому, и свой пользователь, и свой случайно сгенеренный длинный пароль. И посолить не забудь.

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

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

PS. Помяни моё слово — ну его нахфиг

Леонид Мартынюк инженер-программист в 1World online R&D Сenter 16.11.2018 21:45

я бы послал но в описании было типа CRM а потом прислал ТЗ а там и интеграция с платежками и импорт экспорт заказов и прочая фигня. не то чтобы пролема но куча рутинного гемора. Как уже неудобно теаперь посылать надо хоть аргументировать как то. Может он типа крутого админа найдет для всего этого а мне только код писать и не парится.

А требования будут как к системе, которую разрабатывает целая компания добрых десяток лет.

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

С отдельными базами и сайтами два неудобства — нужен грамотный админ понаписать скрипты чтобы автоматом создавать подомены и сайты и нужна какая то центральная БД и панель управления всем этим. Ну то такое

Суть вопроса — принять сразу правильое архитектурное решение — код програмы если где лоханулся исправить недолго а вот как помахнешся в таком фундаментальном вопросе то потом будет хлопотнее

Но только ПОЧАСОВО. И никаких бесплатных доработок, даже запятую поправить. Аргумент назови сразу: он хочет оригинальный продукт по цене дешевле простой копии. Хотеть не вредно.

да я не пальцем деланый — просто такие продукты обычно не одиночки разрабатывают. У меня в конторе на такое есть админы, есть манагеры которые перетирают с заказчиком все вопросы есть прожект менеджер которые крайний если что. Соответсвенно подобные вопросы раньше как то не волновали.

Олексій Пєніє

anonymous 17.11.2018 12:07

типа у меня уже все это есть только в одноце.

Миграцию данных делает, как правило компания, тут одиночке очень тяжело. Напоминает мне «а шо там тебе делать, ты всьо одно компютором играешься»

Леонид Мартынюк инженер-программист в 1World online R&D Сenter 17.11.2018 14:47

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

anonymous

Олексій Пєніє 17.11.2018 12:45

Тебе рассказать, сколько лет эволюционировала одно-цэ, пока её латали-перелатали все баги? И недолатали разумеется.

НЕ СВЯЗЫВАЙСЯ.

А насчёт домена — скрипт пишется один раз, там суть — прописать в готовый файл-шаблон нужную папку, ну и создать под неё пользователя. Команда create database не сложна, уверяю. А дальше в базу льёшь готовый дамп и дело в шапочке.

Центральная база нужна максимум на кабинет юзера, если будешь таковой делать. Как по мне, нах не надо, можешь их список хоть на стене маркером записать.

Ты догадываешься, что подобные продукты делают конторы. Но что реально они стоят сотни человеко-лет вижу не сильно сечёшь порядок цифр. Всё это изобретание велосипеда. И ты не представляешь, СКОЛЬКО там нюансов и хотелочек, и особенностей, которые индивидуальны для каждого заказчика. И каждый считает что это само собой разумеющееся, что вообще не может быть по-другому, а дурак ты.

Леонид Мартынюк инженер-программист в 1World online R&D Сenter 17.11.2018 14:44

Но что реально они стоят сотни человеко-лет

ну значит возьму с него деньги за сотню человеко лет :)
на самом деле админ тамотдельный будет и еще каких нибудь челов с фриланса припряжет для специальных задач
Ну будет проект делатся долго пусть платит — я его предупредил

да нет они там должны регатся и все такое а их песочницы создаватся автоматом, типа как на хостинге

Олексій Пєніє 17.11.2018 18:07

Как раз эта задача — самая простая. Ровно один скрипт. Хоть и придётся немного поработать над его безопасностью, чтобы тебе лишнего не понаписали при создании. Вернее скрипта два — второй чтобы удалять лишнее.

На DNS вообще будет перенаправление звёздочкой, то есть ВСЕ кто не прописан явно — идут на IPшник к тебе, и уже ты у себя определяешь на какой они домен стремились. Ну как на хостинге. То есть как таковые тебе домены и делать не придётся, просто строчка в конфиг прокси, докидываемая скриптом, плюс создание базы из дампа (то есть очень большого запроса, лежащего в файле), плюс создание юзера скриптом на Линуксе.

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

Тех кто будет пользоваться ОЧЕНЬ много (теоретически такие будут, даже если один про это надо думать) — ты спокойно можешь выселить его на отдельный хостинг, выставив за это свой счёт. Чтобы не гадил производительность остальной толпе.
Или если кто захочет безопасности — там плоть до его личного хостинга и без доступа к данным даже тебя. Битрикс именно так пашет.

Вопрос по организации saas сервиса

15 коментарів

Підписатись на коментарі

Новини