Акцентирую одну из самых важных мыслей из прошлого поста и приложу конкретный чеклист, который поможет объективно принять решение о выделение отдельного микросервиса / модуля

Человек очень плох в классификации и категоризации, и если ваша методолгия требует жесткой группировки (например, ООП или "деление по ответственности"), то вы никогда не сможете сделать это правильно

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

Ну, и конечно, вторая проблема: "ответственность" – очень субъективное понятие. Спроси в средней+ системе нескольких человек: "какие ответственности вы бы выделили?" – вариант каждого будет на 50% отличаться от другого. А повышение градума "субъективности" – путь бесконечных ошибок.

И любой человек, который делил микросервисы по ответственности в среднем+ проекте в итоге сталкивался, что они все вызывают друг друга миллионы раз и создают дедлупы

. А как правильно делить

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

Вот эту "примунную ответственность" разработчиком можно назвать "искуственной ответственностью", а нам нужно ориентироваться на "натуральную ответственность" и вот вам чеклист примеров этой "натруальной ответственности":

. Отдельная команда Если есть две команды людей, который должны решать независимые части системы и не коммуницируют на постоянной основе (weekly, daily, свой менеджмент и т.д.), лучше чтобы каждые делали свой набор микросервисов / модулей и договаривались про API.

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

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

Тогда вы выделяете отдельный микросервис, со своим репозиторием и выдаете наружу только безопасный API.

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

. Геозависимость

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

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

. Stateful

Например, вам нужно держать открытые Web Socket или TCP соединения, при этом вы хотите как можно реже редеплоить и вообще трогать это приложение для максимального uptime, тогда вы выделяете отдельный микросервис / модуль, который будет хранить состояние (сокет) и общаетесь с ним через транспорт

. Отдельный набор фич

Вашим партнерам нужна урезанная / другая вариация вашего основного API, тогда вы создаете отдельный модуль, в котором выдаете наружу только то, что нужно + подменяете способ аутентификации (например, на oAuth) и т.д.

. Выделенные ресурсы

Ваше приложение требует большой работы с файловой системы, или, например, это сжатие картинок, или обработка потокового видео, или CPU-intensive рассчет, короче, что-то что требует особого ресурса. Тогда вы выделяете микросервис / модуль и деплоете его на тачках с нужными ресурсами.

. Мешает окружающим

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

Тогда вы можете прям вот этот кусочек выделить в отдельный модуль / микросервис и задеплоить его на отдельной тачке.

. Независимость деплоя Когда мы хотим, чтобы разные сервисы деплоились независимо друг от друга (например, чтобы редеплой неафектил приложения, код которых не был изменен в PR)

Тогда можно выделить модуль (у модулей свои независимые Docker image, поэтому после сборки можно проверять изменился ли hash чтобы принимать решение о редеплое) или микросервис

. Независимость бизнес-логики Вот это САМЫЙ сложный аспект, потому что независимость одного микросервиса от другого – это часто временное понятие (помним, что требования всегда меняются), но если один модуль, по-настоящему способен оперировать независимо от другого (например, система рассчета вознаграждений и система аутентификации), тогда это претендент на выделение в микросервис

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

ЕЩЕ РАЗ, только время покажет реальную независимость кодовых баз

Итоги

Уверен, что упустил и другие здоровые причины деления приложений на модули и микросервисы, так что пишите в комменты

Понял принял

Делить микросервисы по "ответственности" – самая большая ошибка

Отдельная команда

Отдельная комманда разве не делит ответственность? 😁

Это "натуральная ответственность", то есть возникшая из внешнего мира, а не придуманная разработчиком ("искуственная ответственность")

Ориентироваться на на "натуральную ответственность" правильная идея

P.S.

Я даже попробую ввести это понятие в пост) Спасибо)

Может ответственность пусть будет одна — натуральная, а воображение разработчика назовём как то иначе? Ошибкой, фантазией? 🙃

Это просто очень частый термин: искуственная (созданная человеком) и натуральная (продиктованная внешним по отношению к объекту суждения миром)

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

Можно ещё добавить независимый деплой, в качестве причины деления на микросервисы.

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

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

Какая ценность у искуственной ответственности?

В целом, да, хорошая идея, добавлю

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

Оооо это большая тема) Тут скорее не про "ценность", а про то, что она появляется сама по себе просто по причине того, что мы пытаемся ЯП описать какую-либо область реального мира

Я как раз таки за то, чтобы умеьшать кол-во искусвенной ответственности / сложности (вот глава в ФОП про это)

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

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

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

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

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

В целом, есть интересные пункты.

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

Выглядит, как будто нету пользы.

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

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

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

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

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

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

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

Да да, я тоже очень полюбил "domain driven design made functional") И я бы сказал, что она стала причиной написания ФОП)

И у меня тоже есть такое понятие как "проекции", которые позволяют складывать структуры БД в более удобные для бизнес-логики

НО это скорее опциольная вещь и я как раз таки пришел именно к тому что когда мы начинаем реструктурировать схему БД под бизнес-логику мы опять же добавляем искуственную сложность

Поэтому, когда я и от этого отказался мой код стал намного проще и понятнее