Микросервисы: Понятное объяснение, развенчание мифов и эволюция архитектур

# Давайте подытожим раз и навсегда:

. Монолит – общая кодовая база, много команд, общие ресурсы, одно приложение, внутренняя коммуникация

. Модульный монолит – общая кодовая база, много / одна команда, общие / раздельные ресурсы, много приложений, внутренняя и внешняя коммуникация

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

# Словарь

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

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

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

. Ресурсы – инфра (БД, кэши, fs, транспорт, etc.) переиспользуется между приложениями

. Внутренняя коммуникация – вызов бизнес-логики внутри одного приложения засчет вызова функции изнутри кода

. Внешняя коммуникация – вызов бизнес-логики из другого приложения с использованием какого-либо транспорта (TCP, HTTP, MQ, 2IP, stdin, etc.)

# Подставим значения из словаря

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

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

. Микросервис – пилит одна команда; для исполнения какой-то фичи нужно сделать запрос к другому микросервису; свои собственные БД, кэш, fs; запускается это все в рамках множества приложений

# Выводы

. Несомненно, бывают и другие вариации, но в 90% случаев части системы можно классифицировать именно так

. Ваша система может состоять одновременно из Микросервисов, Монолитов и Модульных Монолитов

. Модульный монолит – самый гибкий вариант, потому что позволяет реализовать множество приложений, которым не придется использовать межсервисную коммуникацию (потому что можно просто вызвать функцию изнутри кода), а при надобности можно воспользоваться и межсервисными запросами

(продолжение ниже)

# Эволюция системы здорового человека:

. Каждая команда создает свои модульные монолиты

. Отдельные приложения создается не «на глаз» а только если (1) оно должно существовать на отдельной машине (например, в определенной геолокации), (2) оно stateful (держит сокеты), (3) оно реализует отдельный набор фич (API для партнеров), (4) должно иметь выделенные ресурсы железа (CPU, GPU, RAM, network), (5) использует мешает исполнению другой кодовой базы (CPU-intensive)

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

. Если есть stateful приложения или микросервисы, тогда используем межсервисную коммуникацию, в остальных случаях, вызываем фичи изнутри приложения

. Все.

# Эволюция множества команд разработки

. \"Монолиты – это старье, го в микросервисы\" ИЛИ \"Мы не умеем организовывать кодовую базу, чтобы несколько команд могли над ней работать, го в микросервисы\"

. Делят вся системы на кучу микросервисов чисто \"ну я так вижу\"

. Ебутся с межсервисный коммуникаций, транзакциями, тестами и дебагингом

. Приходят новые требования, которые не укладываются в текущее разделение

. Ловят межсервисный дедлуп

. Ебутся с коммуникаций, транзакциями, тестами и дебагингом в 10 раз больше

. (если повезет) Начинают объеденять микросервисы в модульные монолиты

. (но скорее всего) Увольняются и оставаляют это легаси будущим разрабам, которые такие: \"О, да тут микросервисы! Значит так и надо. Заебись.\"

. Цикл микросервисов и ебли, делает новый оборот

P.S.

Покажу пример каждого в будущем посте с описание go boilerplate

А еще всем прочитавшим: мне так не нравится название \"распределенный монолит\", потому что, ну... он же не \"distributed'... это скорее про то, что мы одну и туже кодовую базу можем запускать в множестве разных приложений и не использовать межсервисную коммуникацию, то есть он скорее \"partitioned\", но тоже не звучит

Короче, нужны ваши идеи или может вы слышали другое название

Еще есть модульные монолиты. Мне нравится как Polylith устроен https://polylith.gitbook.io/polylith/introduction/polylith-in-a-nutshell

Хм, ну \"модульный\" звучит лучше, да

(самое смешное, что у меня есть вторая книга, которую я скоро анонсирую и я сейчас посмотрел я там это тоже \"модульные монолиты\" называю))

Какая 2 книга?

Про best practice в веб и в целом в программировании

Я уже начинал ее писать и постил, из нее вытек ФОП, а теперь я переписал с нуля и хочу сделать полновесную презентацию

Если что, про ФОП я не забыл, его тоже будем продвигать и обязательно сделаю публичным твой вклад) Я просто слишком быстро написал ту и пока придерживаю ее в рукаве

еще хорошо бы чтобы мой код кто-то посмотрел, а то может я там дичь написал полную🌚🌚🌚

Не переживай, я там тоже дичи написал, куча людей посмотрела, пока никто не заметил))

Я кста заметил там в конце про собаку или что-то такое и она там дичь делает🌚🌚🌚

Что-то я немного не согласен, но потом ещё раз перечитаю внимательно и дополню.

Если я правильно понял, то ты смешал SOA и понятие микросервисов в одну кучу, а потом решил отделить их по другому.

Кажется, что у тебя очень плохой опыт с микросервисами и тут явная предвзятость в сторону монолита.
Простой пример, если ты сделаешь 100500 монолитов, которые будут задеплоины в service mesh, то у тебя будет описанные тобой микросервисы.
Потому что микросервисы это про подход к организации инфраструктуры, а не кода.

\" и тут явная предвзятость в сторону монолита.\" – скорее это про то, что для большинства проектов модульные монолиты будут более грамотным первоначальным решением + про то, чтобы уменьшать кол-во междсервисной коммуникации (как одна из причин излишнего усложнения систем)

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

\"100500 монолитов\" – очень важно учитывать объем системы, если она настолько большая, что там могут быть условные \"100500\" критерии деления моей статьи по-прежнему работают, но там начинают работать и другие намного более сложные принципы. Не беру рассмотрение подобного, потому что там слишком много зависит от контекста конкретного бизнеса

\"микросервисы это про подход к организации инфраструктуры, а не кода\" – сне всеже кажется, что инфраструктура – это следствие, нежели причина

Но да, нам лучше детальнее это обсудить, чтобы понять друг друга

Как пример: я разрабатывал очень крупную систему (Гб данных в день, которые должны обрабатываться в real-time), при этом нам хватило всего 20 микросервисов для оперирования кучу подразделений и тонны бизнес-логики (система управления поведением искуственного интелекта)

И вот так было использовано деление по ответственности, но лишь потому что ответственности были очень крупными и непересекающимися (например, микросервис отвечающий за обработку действия операторов и микросервис, отвечающий за расчет финансовой модели сессии) + использовался чистейщий Event Sourcing, позволяющий в случае необходимости получения данных из стороннего сервиса, достаточно часто, просто получить поток Event и пересчитать их в соотстветствии с интересами сервиса

Ни на одном среднем проекте не видел больше 100 микросервисов. Обычно это цифра около 50 или меньше.
Этих сущностей более чем достаточно, чтобы построить множество бизнес-логики. Поэтому нет никаких кучи микросервисов, если ты не нетфликс какой-нибудь, где тоже инженеры не эталон для подражания, у них достаточно ошибок в блоге.

Ну и забавный момент, у меня несколько процессов кода на IoT, при этом они общаются по шине данных, чтобы делать бесшовные обновления без сброса критически важных сокетов к оборудованию. Это уже микросервисы или ещё нет? 😁

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

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

Ну вот, а в чем проблема то, почему это плохо для тебя было?

Было не плохо, было прекрасно)

Но работало это, потому что они слабо пересекались и часто попадали в пункты из моего списка

Да, можно сказать что \"слабо пересекались\" это \"грамотно делили ответственность\", я подумаю как бы это можно было отразить в статьей

Добавил пункт \"независимость\". Он не совсем полностью покрывает наше обсуждение, но в совокупностями с другими пунктами должен ответить на нужный вопрос