Комментарии 22
Есть прекрасный сайт где все это собрано https://microservices.io/index.html и книга от того же перца
Microservices Patterns: With Examples in Java есть вроде и на русском, от неё мне спать не хотелось, увлекательное чтиво
Очередной список паттернов) Ответьте: проверка данных должна быть до микросервиса или внутри?
Смотря какая проверка.
Есть проверка формата, например json по схеме.
Есть логический контроль, это бизнес требования.
Соответственно эти проверки живут в каждом сервисе по отдельности. Если сервис выполняет роль gateway - то валидация запроса на его стороне. Если сервис работает с заказами, то проверка на создание заказа живет у него. Можно создать отдельный сервис для проверки, если это большая бизнес логика и зависит от других сервисов.
Начиналось всё хорошо, а потом сага - паттерн (а не антипаттерн). Если мы вовлекаем 2-3-5-10 микросервисов в одну бизнес-операцию, это значит мы неверно их разделили. Это примерно как держать фамилию клиента в одном постгресе, его отчество в другом, а фамилию в третьем. Разумеется, если человек решит поменять ФИО (всё сразу) нам нужна будет сага. Но в действительности нам лучше бы держать изменяемые вместе данные - вместе, ваш кэп.
Если вы считаете, что нужно держать изменяемые данные вместе, то ваш путь - монолит. В MSA так не работает, держать все данные в одном месте нонсенс, например, я не смогу при проведении банковского платежа (одна бизнес операция) смешать все в кучу, уменьшение лимитов, расчет комиссии, хранение истории. И т.к. это разные сервисы, то сразу возникает распределенная транзакция и проблема согласованности данных. А как ее решать, сага или не сага, тут уж каждый решает сам, не нравится сага, придумываем свое решие, и возможно потом появится новый потерн.
Опыт автора и академический тон статьи должны как будто убедить нас, что всё написанное нужно всем. Пользуйтесь и всё у вас будет хорошо. Если прочитав эту статью вы уже идёте душить своего монолита и разделять базу данных, не торопитесь.
Для начала то о чём забыл написать автор (преклонный возраст или нежелание портить благостную картинку) - КАЖДЫЙ пункт этого набора имеет свои недостатки. Например. Вот, руководствуясь Decompose By Business Capability и Database Per Service вы вынесли покупки пользователей в одну базу, а профили пользователей в другую. Вдруг к вам прибегает окрыленное руководство и говорит - ребята срочно, у нас есть бизнес идея, для проверки нам нужно сгруппировать покупки по городам пользователей и посчитать их количество. Адрес пользователя в базе профилей, покупки в базе покупок, простой join не сделать. Как быть? В этот момент обычно приходят умные дяди с 30 летним опытом и говорят, что нам нужно data strategy, data warehouse, etl и т.д. Получается, что для того, чтобы сделать простой аналитический join в мире микросервисов вам теперь нужно иметь дополнительный тяжелый, дорогостоящий, требующий обслуживания слой. Иногда это неизбежно, но мне кажется в 90% случаев этого можно избежать.
Или же паттерн Сага. Вот вы делаете транзакцию и просходит ошибка, нужно откатиться. Ничего страшного, говорит Сергей Громов, достаточно запустить серию(sic!) компенсирующих транзакций и все вернется на свои места. Но вот в этой серии из 10 компенсирующих транзакций, восьмая упала с эксепшеном. Что теперь? Компенсируем компенсирующие транзакции? Или просто забиваем, оставляем неконсистентный стейт и называем это progressive eventual consistency?
Я уже не говорю про курьезы и перегибы, когда на 15 человек команды в компании написана сотня микросервисов. Time2market и delivery speed падают практически до 0.
Сергей как мне кажется начал не с того. Главный вопрос современности, не как удушить ваш монолит, а в каком случае вам вообще стоит использовать микросервисы и для чего они нужны. Из своего 18 летнего опыта могу сказать, что единственное, когда микросервисы действительно помогают, а не мешают - это когда у вас МНОГО разработчиков. Как в Гугле, Яндексе и прочих Майкрософтах.
Если же у вас весь отдел разработки до 50 человек, я бы порекомендовал использовать модульный монолит и сэкономить огромное количество времени и сил. Как справедливо замечает Сергей, в случае необходимости потом его всегда можно "удушить".
Я с вами практически полностью согласен (к сожаления не смог вас идентифицировать). И действительно "Главный вопрос современности, не как удушить ваш монолит, а в каком случае вам вообще стоит использовать микросервисы и для чего они нужны ", но данная статья ни в коем случае не была направлена на выбор архитектур, да и рассчитана немного на другую аудиторию, на тех молодых специалистов кому (бородатые дядьки) сказали "делаем MSA", и тут зачастую начинается изобретение велосипеда.
А по поводу выбора архитектуры, особенно MSA, на эту тему надо делать отдельную статью, но размещать ее надо будет в разделе "Философия" т.к. тут сколько люде, столько и мнений. Я сам считаю, что к выбору MSA надо подходить крайне осторожно и продуманно, т.к. недостатков и сложностей у этой архитектуры очень много. Скажу больше, лично я считаю, что часть того, что принято считать достоинствами MSA, является ее недостатками. :-) И зачастую переход на микросервисы продиктован "модой", а не реальной необходимостью.
Но повторюсь это отдельная тема. И нам все равно не никуда не деться от микросервисов (по крайней мере в ближайшем будущем) и значит нужно уметь их проектировать и понимать как они работают.
А нельзя для аналитики взять ещё один сервис и дать ему доступ к репликам нужных бд? И сервис отдельный и статистика тянется с бд которых не жалко.
Я бы не стал так критично относиться к микросервисам. В моём случае, например, так получилось, что я - единственный человек в команде по разработке системы скрейпинга, но при этом скрейперы очень разные, и их много, а контрольная панель одна. Логично, что каждый скрейпер я выделю в микросервис, который обрабатывает очередь постоянных задач и который я в любой момент могу остановить, чтобы улучшить, и запустить вновь. Так что случай с большой командой - не единственный возможный)
Вдруг к вам прибегает окрыленное руководство и говорит - ребята срочно, у нас есть бизнес идея, для проверки нам нужно сгруппировать покупки по городам пользователей и посчитать их количество. Адрес пользователя в базе профилей, покупки в базе покупок, простой join не сделать.
Аналитикам как правило и БД нужна другая, в т.ч. колоночная.
Можно сделать топик в кафке и пулять туда данные. На топик посадить отдельный сервис аналитики который будет агрегировать данные в своей базе.
Статья - краткая выжимка из книги Сэма "Создание микросервисов" ( и откровенно говоря бесполезная )
будем исходить из того, что микросервисная архитектура — это уже решенный вопрос
Дешёвка!
За такое денег много не заплатят, т.к. реализация микросервисов это не вопрос архитектора, а так... аналитика 5го ранга, который с высокой вероятностью угробит систему.
Вот за что денег заплатят это когда ты решишь вопрос где нужно выделить микросервис, а где нет и почему и сколько это будет стоить сейчас и в перспективе и при некоторых сценариях.
Добрый день! Что скажете на счет хранения данных для нескольких микросервисов в одной бд но разных схемах? В случае отказа БД не работоспособной будет вся система, не так ли? Стоит ли "оставлять допустимость" такого решения на постоянку?
И можно чуть подробнее про DDD декомпозицию? Что берется за субдомен? Например у меня avito и есть проекты - товары / квартиры аренда / еще совсем отличающийся домен. Должен ли у них быть разный субдомен клиенты или продажи или нет? Ведь бизнес правила совершенно разные
Я предпочитаю разбивать по бизнес правилам. На пример финтеха. Есть домен переводы, он огромен и собрать в один сервис (про микро тут даже нет смысла говорить) будет ошибкой конечно. Я разбиваю на мелкие под домены Card2Card, Account2Account, Платежи по начислениям, переводы по номеру телефона (СПБ). У каждого свой процесс, свои правила, своя БД. У вас клиенты (я бы наверное сформулировал как "управление клиентами") это отдельный сервис, управление товарами отдельно, услуги отдельно (и тут возможно даже более мелкое деление в зависимости от процессов надо смотреть)
То есть управление клиентами в рамках домена СБП, например, а не всей системы?
Нет, обычно клиентами управляет один сервис на уровне компании, исключение если только у вас клиенты различаются, что вряд ли, обычно есть одна MDM для клиентов. А вот управление операциями и товарами зависит уже от процессов, вернее от их различия.
Ну вот ИМХО при таком подходе есть большой риск, как я говорил, сделать Big Ball of Mud как с биллингом. Клиент - это интернет магазин, например. Для СБП ему например, нужна SBP id от НСПК, для карточных платежей нужны MCC, и идентификаторы VISA / Mastercard, для тех, кто обрабатывает номер карты на их стороне признак или хранилище под PCI DSS сертификат и тд... И получается что разные безнес процессы тянут этот сервис в разные стороны...
P.S. Тут речь не идет про универсальные инструменты типа CRM (дорабатывает отдельный вендор, но даже и в настройках можно такого понакрутить - что потом не разберешься)
P.P.S. Если самим делать такой универсальный сервис то я бы мб сделал бы несколько бекэндов для одного фронта (типа как в мульти аппах делают) или бек по типу Gateway Api
Разбираемся в проектировании микросервисов. Основные паттерны (Часть 1)