Когда стоит разделять приложения?

Question

[Dos]

Привет. Недавно задумался над таким вопросом. Большинство фреймворков это готовое приложение. Например, сейчас использую vue и symfony. У меня получилось 2 приложения : front и backend. Это достаточно частое разделение для большинства задач. Но мне непонятно одно. Когда таких приложений имеет создавать больше чем 2. Например, на симфони или vue? Для каких вещей достаточно разделения папками (модули), а какие вещи могут и должны выделяться в отдельные приложения? Спасибо

Answer 1

[Илья]

1 кейс.
У вас есть запросы на которые нужно отвечать быстро (текущее состояние) и какой-то сервис с отчетами. Когда пользователи запрашивают большой отчет скорость ответа текущего состояния начинает проседать. Тогда вы делаете отдельный сервис для отчетов, выносите его в отдельное приложение и на отдельную виртуалку. Таким образом вы изолируете потребляемые ресурсы и устраняете влияние сервисов друг на друга. Плюс получаете возможность отдельно масштабировать сервис отчетов во времена наибольшей нагрузки.

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

3 кейс.
Вы делаете несколько сложных сервисов и решаете распаралелить разработку на несколько команд. Одна команда делает "Кинопоиск", другая "Афишу". Все они обращаются к серверу авторизации из кейса 2 и бекендам из кейса 1.

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

Comments

[Дархан]

[DevMan]

Дархан Камалиев, по большому счету так и есть.
но есть и нюанс: разгребать маленькие кучки проще и быстрее.

[Илья]

Дархан Камалиев, что вы хотели этим сказать?

[Илья]

DevMan, некоторые и с монолитом неплохо живут, и не считают что это плохо

[DevMan]

Илья, не некоторые, а большинство.
нет волшебной пилюли. микросервисы ради микросервисов/хайпа - это бред (например, как и с докером). но на определенных задачах они вполне работают и помогают.

[Илья]

DevMan, согласен. Есть хорошая статья на эту тему. You Are Not Google

[DevMan]

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

[Евгений Ромашкан]

Асинхронный воркер делающий тяжёлую работу на фоне != микросервис. Монолит тоже масштабируется, и монолит не означает что все приложение обязано быть в одном процессе.

[Илья]

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

[Илья]

Евгений Ромашкан, если вы внимательно посмотрите мой ответ, то не найдете в нем слова "микросервис" ни разу. Это слово появляется только в комментах. Тут проблема в том что терминология сильно "плавает". Кто-то считает что выделение кода в отдельный процесс уже микросервис, потому что это модное слово. Я называю это "сервис". Кому ближе linux сказали бы что это демон.

Монолит тоже масштабируется, и монолит не означает что все приложение обязано быть в одном процессе.

С этим согласен, у нас на проекте как раз такой подход рабочий

[DevMan]

Евгений Ромашкан, тут кто-то писал про асинхронный воркер?

Илья, да и я не защищаю. я о том, что верный (и то, только для себя) способ можно выбрать исключительно путем проб и ошибок, а не по чужим статьям/ответам.

[Dos]

3 кейс.
Вы делаете несколько сложных сервисов и решаете распаралелить разработку на несколько команд. Одна команда делает "Кинопоиск", другая "Афишу". Все они обращаются к серверу авторизации из кейса 2 и бекендам из кейса 1.

Мне больше подходит этот кейс. Но вопрос по нему. Если я разрабатываю сложные сервисы, то:
Я сейчас разделил только на api и front. В api у меня весь api афиши, Кинопоиска и т д. Нужно ли под каждый сервис делать свой api и front. Или же это просто делить папками в api и front. Или вообще делать сервис в котором будет свой api и front? Как лучше в этом плане поступить?

У меня сейчас есть сервис авторизации. И большой Сервис Афиша.

У афишы есть: организаторы, участники (люди и компании), новости мероприятия, ПОДСЧЁТ результатов участников.

И я теперь сомневаюсь по регистрации и подсчёту баллов. Может быть это отдельные сервисы? Или как вообще лучше устроить?

Кроме того компании и люди в каждом сервисе могут повторяться. Не нужно ли людей и компаний выносить в отдельный сервис? Думаю нет. Но просто задаю кучу вопросов чтобы разобраться.

[Илья]

pro-dev, сколько у вас человек на проекте? Есть ли функционал который вы бы хотели масштабировать отдельно? Тут просто так не ответишь. Нужно понимать потоки данных, сколько запросов и как они распределены, какая нагрузка и еще много вещей. Общий принцип я описал.
Выделение кода в отдельное приложение (отдельный процесс) делаем
или по организационным причинам: разделение кода для упрощения понимания или разделение кода между разными людьми/командами или требования безопасности/юридические требования.
или это явно разные модели обработки (например АПИ для пользовательских запросов и фоновая агрегация, в этом случае у них разный хост-процесс: веб-сервер и фоновый сервис)
или по причинам нехватки ресурсов.
Надо понимать что практически любое разделение кода несет за собой организационные издержки (нужно приложить больше усилий для понимания) и если сервисы должны между собой общаться, то издержки на межсетевое взаимодействие. Разделяя код в разные процессы теряется возможность очень быстро общаться через общую память.

[Dos]

Илья, я дико извиняюсь, но только сейчас увидел ваш комментарий.. Уведомление куда-то пропало...

сколько у вас человек на проекте?

Пока 2-е

Есть ли функционал который вы бы хотели масштабировать отдельно?

Да, есть. Пока что в одном месте, но затем хотелось бы отделить на разные сервисы. Так как они логически отделены.

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

Нагрузка пока не большая. До 50 000 посещений в месяц.

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

Правильно ли я понял, что под каждый сервис нужен свой API? Или весь API делается как отдельный сервис API? У меня есть сервис Аккаунт и Мероприятия. Мне в каждом из них нужно делать свою API верно?

У меня есть сервис мероприятия. Он достаточно большой. В нем есть логические вещи, которые можно вынести в отдельный сервис. Это регистрация и счет баллов или отдельный сервис manager для управление мероприятием (регистрация, счет). Либо вообще все оставить в сервисе мероприятий. Вот с этим я не могу решиться. Сможете помочь? В принципе эти сервисы будут взаимодействовать с мероприятием, но они достаточно самостоятельные и нужны лишь только данные. Вот я и думаю стоит ли разделять их. Либо оставить в одном сервисе.

Разделяя код в разные процессы теряется возможность очень быстро общаться через общую память.

на первом этапе можно разделение сделать папками, а не отдельными приложениями. Как думаете на этот счёт? А уже если нужно разделить на приложения и так далее. Опять же разделение такое, что в принципе они друг с другом не особо и сильно взаимодействуют.

Ещё есть вопрос по городам. С точки зрения базы правильно хранить города в одном месте. А везде в таблицах ссылаться по id. Получается это тоже отдельный сервис городов? Или в каждом сервисе своя нормализация по городам.

Можем даже связаться по скайпу. Оплачу консультацию.