Comments
А сейчас я хочу рассказать как надо разрабатывать микросервисную систему.

Пункт 0. С вероятностью примерно в 95% вам не нужны микросервисы. Потому что.
С вероятностью 95% вам не нужны ИТ вообще. Вопрос здесь стоит не в религиозной плоскости, а в требованиях рынка.
Spring был изобретен в годы становления монолитной архитектуры. Это огромный монстр, который даже в функции простого Hello World превратится в jar-файл размером в сотни мегабайт. Просто старт такого приложения растягивается на минуты.

Ну это не совсем правда. Пока не воткнули ORM, Спринг стартует быстро.
И в том, что джарник растет как на дрожжах, виноват не Спринг. А разрабы, которые тащат целые библиотеки ради одной функции.
Ну, разрабы вообще за все отвечают. Тут трудно спорить.
Вопрос лишь в качестве разрабов. Если 99% кода на спринге превращается в спрингопомойку, в которой без поллитра не разобраться, то я понимаю, что это происходит только из-за того. что сам фреймворк мотивирует разрабов писать некачественный код.
Фреймворки бывают разные. Я видел такие, которые стимулировали в модель засовывать всю логику. Ну а спринг вот просто приучает к бардаку.
При этом все подходы при реализации МСА настолько отличаются от монолитной

Да ладно? Модульная архитектура существовала еще 40 лет назад, и с тех пор подходы не изменились. Отличаются лишь средства: каждый раз более громоздкие, ресурсо и трудозатратные и менее надежные.


Команда не обязана выносить на корпоративный уровень вопросы о языке, на котором будет написан микросервис. Одни могут выбрать Java, а другие — Python.

Ну написали они на пайтоне свой сервис и что дальше? Будут сидеть баластом верхом на своем коде? Другой модуль, который написан на Java уже не в их компетенции? О ротации ресурсов не подумали?


В МСА каждый микросервис отделен ненадежными и компроментируемыми сетевыми коммуникациями.

Это вы про Rest/HTTP? :)) Или про отсутствие ACID в микросервисной архитектуре? Для надежной сетевой коммуникации еще 20 лет назад использовались Queue Managers, кроме того наличие распределенных транзакций гарантировало отказоустойчивость системы при сбое в любом месте. И не надо ломать голову как координировать откат операции или повторное выполнение — все ACID.


Oracle, Postgres, MySQL — это все жуткое старье, которое было построено из расчета, что база данных должна крутиться на одном сервере.

Это было построено из рассчета, чтобы был ACID. Ваши NoSQL — это по большей мере хаки, которые жертвуют конситстентностью в угоду распределенности, поэтому никто не собирается отказываться от классических реляционных баз. Практически во всех проектах именно реляционные БД являются маэстро данных, а NoSQL используются по большей части как кэши и производные. Но, внезапно, архитектура хайлоад к микросервисам не имеет практически никакого отношения.

Вы ещё забыли написать про нормальный DevOps в компании — если его нет(он плохой) то тоже не стоит идти в микросервисы

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


Вот это вообще хорошо…

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

И в этом случае — все же данные отрабатываются через интерфейсы и эти интерфейсы пишут люди, отвечающие именно за data presentation, transformation и тому подобное. Поэтому от интеграции и коммуникации между различными командами никуда не уйти. Просто API согласовывается на первом этапе, затем для бэтта-тестов выдается макап-сервер с заглушками и две команды одновременно ведут проект, сводя его вместе в финальной точке.
Про то как оркестровать разные команды — тут ничего нового нет. Тезис был совсем о другом.
О том, что команда должна отвечать за бизнес-фукнцию. Как только вы разбиваете бизнес-функцию по разным командам, все, сама бизнес-функция становится никому не интересной хренью. И уже никто за нее не отвечает. И что будет в момент сбоя справочника, всем тоже становится плевать. Просто потому что это «не наша зона ответственности». И кто в итоге становится ответственным? Да, тот самый архитектор, который за жизнь не написал ни строчки кода. Или аналитик, который не предусмотрел.

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

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

Кстати, когда беседуешь на позицию архитекта, как раз эти вопросы «как сделать все в целом» и поднимают. И за такой ответ «отдадим все на откуп отдельной группе» — вас тупо с улыбкой попросят за дверь. Потому что есть разница между крохотными стартап-проектами и большим продом, который жрет ресурсы и любая ошибка в итоге приносит финансовые потери.
№4 — резерв?
Мой опыт показывает что это не резерв, а часть команды и чем раньше это поймут, тем меньше повторных шишек набьет новая команда и больше шансов у проекта на успех.
Резерв, как правило, точно знает на чем лажанулись в старом решении и при переходе на микросервисы или просто миграции на новую архитектуру с этими ребятами нужно плотно работать и совмещать новую архитектуру с имеющимся функционалом, который как раз и знает «резерв».
Все было бы так, если бы не напыщенность старожилов и чувство знания истины. Помноженные на полное непонимание МСА, они приводят только к ошибкам, стоимость которых миллионы.
Only those users with full accounts are able to leave comments. Log in, please.