Портить малину инженерам и запиливать сервисв обратно в монолит, конечно-же :sarcasm:

Чё такое SoA нахой?

@@sasichkamega Service-oriented architecture

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

Полная чушь. 1) "Десять подзапросов на каждый запрос" - самый обычный случай - у тебя конвейер. Там хоть 100 будет - и что дальше?. 2) Если у тебя запрос ложится в 2-3 подзапроса - у тебя настолько ничтожно-малая система, что не понятно нафига вообще тебе микросервисы?

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

К счастью участь распределенного монолита мы избежали. репликация данных из сервиса в сервис - есть такой подход, да. Но это - не самый дешевый подход (особенно на масштабах Авито с десятками террабайт данных в сервисе), требует вместе с данными тащить и логику их получения\заполнения (ведь сервисы это таки не CRUD, а если CRUD - у тебя проблемки) Идея в том, что если у тебя глубина цепочки >1 ты уже не можешь поставить бряку в произвольной точке, как раньше. А этого ох как хочется.

"Неправильно распилили монолит" - это как "real communism was never tried". Есть якобы какой-то идеальный распил, но никто его не видел

Все знают, что распил монолитов придумали для распила фота.

EDA не панацея и не серебрянная пуля. Посмотрите полезный доклад на тему Event Sourcing You are doing it wrong by David Schmitz

@@i.p.1832 event sourcing не равно EDA. Эта технология может использоваться вне EDA, а EDA может не использовать event sourcing.

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

​@@alexb6036 по существу ничего не сказал. Кроме наезда уловил только мысль о том, что иногда нужен мгновенный ответ. Само собой, но как раз-таки глупо использовать этот паттерн в сложной системе, где нужна модульность для простоты поддержки и разработки. Одной команде сложно работать с монолитом, даже разбитым на микросервисы. Там, где нужен быстрый ответ, там его и нужно использовать, а если он не нужен (что чаще всего и бывает), то лучше использовать события, потому что они делают части системы независимыми и самодостаточными, о чём мечтают все нормальные программисты, потому что такой код проще контролировать.

​@@-dubok- Насчет быстрого ответа, он нужен почти везде, а где не нужен быстый ответ синхронизация происходит через записить в базу в одном месте и чтения в другом. Что обеспечивает целостность информации по средствам базы и простой понятный подход с возможностью посмотреть состояние через SQL и очень простым аудитом. Этого достаточно почти всегда. А вот очереди это самое последнее что нужно использовать, потому что они требуют много дополнительных сил для настройки и управления. Асинхронно работающий код очень сложно понимать в сравнени с последовательным опросом внешних сервисов. Но ситуация даже проще, микросервисы почти ни где не нужны, потому что имеют смысл только там где большие нагрузки вроде авито или гугла. В остальных проектах это монолит, в лучшем случае пару дополнительных отдельных крупных сервисов и может быть где то микро для особо нагруженных задач. То что вы написала про очереди как о более простом способе общения это не так. В случае с запросами код выполняется последовательно и он либо выболнился получив ответ или не выполнился, все просто и понятно. С очередями вам нужно заводить какие то примитивы синхронизации в которых будет копиться информация приходящая из очередей и как раз в этом случае вам потребуется писать код котрых будет периодически проверять состояние а пришли ли все данные из нескольких сервисов что бы их объеденить и сделать следующее действие, что и есть "куча условностей в общении между ними". Про "добавляются сетевые издержки" это надуманное, с очередями все даже хуже. Потому что вы сначала пошлете данные в условых RebbitMQ а потом он перешлет данные в другой сервис это два HTTP запроса, если у вас сервис запрашивает данные у другого сервса напрямую это один запрос.

версионированность чего именно? у нас внутренние методы, и события версионируются. есть постоянное контрактное тестирование как часть жизненного цикла ЛЮБОГО сервиса. И теперь это не требует 50 человек на поддержку (часы поддержки тратим на иное =))

мы и написали, да -) И не стоит мое "нытье" воспринимать как сожаление о своем решении. Путь в микросервисы был долгим, дорогим. И мы многое потеряли в процессе - тот же дебагинг. Но оно того стоило в итоге. Хоть и жаль тот же дебагинг...

в Авито 5 больших, не похожих друг на друга, вертикалей бизнеса: Авто, Работа, Недвижимость, Услуги, Товары Каждая вертикаль - живет по своим законам. Считай - что каждая вертикаль - отдельный бизнес, отдельный(нет) набор микросервисов. Добавим сюда - пачку внутренних сервисов, и пачку тестирующихся в моменте АБ-тестов (иногда с отдельными мини сервисами под эксперимент)

@@TheMMgo А сколько в среднем выходит численность команды, поддерживающей один микросервис? Или на таких числах уже выходит несколько микросервисов на команду?

@@redneck_prm5429 сложно ответить, владение сервисами идет не персональное а командное. и это сильно зависит от самой команды, ее размера, ее бизнес-домена

На каждого бекендера по сервису)) Мне кажется что большинство проблем у них из-за того что слишком мелко все распилили

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

Микросервисы - это способ раздувания хэдкаунта и ЧСВ менеджеров.

полностью согласен, микросервис это больше про изоляцию, включая команды разработки

Так радуйтесь, можно денег больше снять

IT болен слепым следованием моде.

Так сделайте им микросервис. Один.

@@andreiosipov2766 Так это уже будет не микро.))

Вы им предложите ещё сделать микро фронт енд, тогда можно к прайсу накрутить ещё какое то кол-во десятков процентов.))

У парней с монолитом 49.5 см

Они думают что если сделали в своих рагах и копытах, архитектуру якобы как в гугле, то из размер пениса сразу же становится как у парней из гугла. Это всегда так. Стоит челу из крупной компании написать про какой то подход или технологию, сразу же crud'щики из шараг пытаются копироват, потому что хотят быть такими же. Это называется - мода.

@@TheMMgo в диаметре!

@@TheMMgoвнутрь

ну пока был монолит "все работало"

@@TheMMgo Пардон, но то, что работало и влезало в ноутбук семь лет назад не заработает и не влезет сейчас, когда кода стало в ХХ раз больше.

забавно, что этот комментарий, был сделан скорее всего из под ОС, которая представляет из себя монолитное ядро, в котором поболее чем 2.5к сервисов

@@Rusebor В ядре Linux это 82 396 файлов с голыми процедурами и функциями на C, которые проверяются быстрыми юнит-тестами. Это не 2.5к модулей, обслуживающих HTTP-запросы и ходящих в свои таблицы БД и свои очереди, что нужно тестировать более медленными интеграционными. Но даже так каждый релиз ядра занимает 2 месяца, а свои проекты мы скорее всего релизим почти каждый день.

@@Rusebor Я про простую математику. Что если микросервис из ~30 файлов и 3 таблиц в БД с 3 миграциями и 6 фикстурами можно на ноуте запустить и всеми линтерами и тестами разных типов проверить за 10 секунд, то после склейки 2.5к таких сервисов итоговый монолит из 75к файлов с 7.5к таблицами по 7.5к миграциям с 15к фикстурами эти же проверки займут пару часов.

не курю, спасибо-) но можешь угостить меня виски -)

Ростовчане лапочки-)

Ответ в том, что нужно не монолиты или микросервисы делать, а сервисы здравого размера, которые достаточно гранулярны чтобы их релиз не стопорил всю компанию, но достаточно большие чтобы не страдать от типичных проблем распределенных систем. А еще нужно осознавать дележку по бизнесу и дележку по техническим требованиям и не надо эти границы всегда делать одинаковыми. > это быстрая адаптация к изменению бизнес требований Мутно сформулированный тезис, который сложно конструктивно обсуждать. Монолиты в целом проще рефакторить, проще модифицировать при затрагивании нескольких доменов одновременно, следовательно он адаптируется быстрее. > Каким образом тогда как минимум гонять QA пайплайны? по всему монолиту сразу? Нет, гоняйте только по изменившимся модулям. Нет тулинга? Так там платформенная команда на 50 человек, может и тулинг сварганить.

@@nikitavilunov1913 > Мутно сформулированный тезис, который сложно конструктивно обсуждать. Монолиты в целом проще рефакторить, проще модифицировать при затрагивании нескольких доменов одновременно, следовательно он адаптируется быстрее. Быстрая адаптация - это опять же вопрос размера этого монолита.Мой тезис имеет место быть только если работаем со сравнительно внушительных размером модульным монолитом. Автор доклада, как я понял, рассказывает о том что процесс распила был инициирован как рас тогда когда монолит стал жирным(в контексте их реалий). Опять же простота рефакторинга напрямую зависит от его модульности и от уровня изоляции доменов на уровне кода. Если мы говорим о четко выдерженных джентельменских соглашених, когда команды из соседних доменов свои ручки к чужим не суют(что тоже является соблазном и легко пропускается на ревью), если есть тулы которые позволяют делать различного рода рестрикшены на уровне контрибьютинга и т д . Я к тому, что в SOA границы четко расставлены по сервисам, есть возможность внедрения API first на уровне общепринятых инструментов(генераторы и свагеры...), есть железные контракты, которые поломать не так просто(элементарно на уровне приватности тех же репозиториев). В монолите, как вы выразились, для этого всего нужен кастомный тулинг(я конечно с монолитами таких масштабов не работал, может такого рода тулы и существуют. Как-то раньше до распила дело доходило). Если поделитесь ссылочкой на доклад где тема такого рода раскрывается - буду Вам благодарен > Ответ в том, что нужно не монолиты или микросервисы делать, а сервисы здравого размера, которые достаточно гранулярны чтобы их релиз не стопорил всю компанию, но достаточно большие чтобы не страдать от типичных проблем распределенных систем Да, да. Это тру. Микро или не микро - это всегда философский вопрос, ответ на который варьируется от мнения к мнению. Распиливая монолит на любого размера сервисы так или иначе придется делать саги разного уровня сложности(ну в большинстве случаев) и тут мы и сталкиваемся со всеми этими проблемами. Даже если мы начнем "Душить" монолит и по итогу будет монолит + пару сервисов, то уже распределенная система со всеми ее проблемами -> Нет, гоняйте только по изменившимся модулям. Нет тулинга? Так там платформенная команда на 50 человек, может и тулинг сварганить. Можно конечно, опять же вопрос выставления границ. Я с этим не сталкивался, потому как опять же не доводили до такого. Но пилить такого рода тулы - это уже сигнал к тому что какой-то булшит происходит и стоит уже задуматься о долгосрочной перспективе

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

@@proger150 > Я к тому, что в SOA границы четко расставлены по сервисам На практике это не так, вот даже у автора доклада походу получился распределенный монолит, и вообще, я лично никогда не видел хорошо поделенных микросервисов. Границы это не что-то что можно идеально понять с первого раза, а зачастую и со второго-третьего. И даже если ты их поймешь и реализуешь, может прийти что-то новое и затребовать пересмотреть границы. Перенести код между двумя модулями одного сервиса намного проще, чем между двумя разными сервисами, это и делает монолиты гибче. > легко пропускается на ревью Это очень хороший поинт, я часто сталкиваюсь с тем что что-то нежелательное пропускается на ревью. Что с этим можно сделать? 1. Задокументировать неявные свойства кода, сделать их явными, чтобы можно было на них сослаться и в принципе прочитать их если сомневаешься. 2. Покрыть тестами и линтами точки каплинга, валить CI если нарушены договоренности о проведении границ. > если есть тулы которые позволяют делать различного рода рестрикшены на уровне контрибьютинга Делайте тулинг, я ж уже сказал, можно юзать освободившийся ресурс из-под платформы микросервисов. Вопрос того что тулинг нужен уже как бы и не стоит, просто можно его в другую сторону делать. > это уже сигнал к тому что какой-то булшит происходит и стоит уже задуматься о долгосрочной перспективе Почему тулинг для поддержания бизнесовой дележки без влияния на техническую дележку - это булшит, а форсировать одинаковую дележку микросервисами - это не булшит? Второе звучит намного булшитнее. > Да и к тому же сам факт того что весь биг тех переезжает на SOA - неоспоримое подтверждение преимуществ гибкости Нет тут ничего неоспоримого, мало того что очевидно требования бигтеха не ложатся даже на тот же авито, так еще и бигтех сам по себе допускает ошибки. Это не какой-то непоколебимый мудрец, это такие же работяги, которые уязвимы к модным нововведениям и хотят пополнить ими свои сивишечки.

> Нет тут ничего неоспоримого, мало того что очевидно требования бигтеха не ложатся даже на тот же авито, так еще и бигтех сам по себе допускает ошибки. Это не какой-то непоколебимый мудрец, это такие же работяги, которые уязвимы к модным нововведениям и хотят пополнить ими свои сивишечки. Мода перетекла в здравый смысл. Если есть компании, которые имея несколько тысяч инженеров которые довольны монолитом, то я был бы рад услышать рассказ об их опыте и увидеть их довольные лица а не гарольдфейс) я апеллирую тем, что вижу на этих докладах. Обратной тенденции не наблюдается. Инженеры готовы проходить весь этот путь и идти на коспромиссы распределенных систем. Опять же, если не прав, поделитесь опытом) > Делайте тулинг, я ж уже сказал, можно юзать освободившийся ресурс из-под платформы микросервисов. Вопрос того что тулинг нужен уже как бы и не стоит, просто можно его в другую сторону делать Думаете экономически целесообразно когда распил грозит в будущем?) > 1. Задокументировать неявные свойства кода, сделать их явными, чтобы можно было на них сослаться и в принципе прочитать их если сомневаешься. 2. Покрыть тестами и линтами точки каплинга, валить CI если нарушены договоренности о проведении границ. Ну вы же понимаете что документация кода - это то что надо всегда поддерживать) это так не работает в условиях agile. Документировать будут продукт, а не код. Да и то документация по продукту устаревает, я уж не говорю про документирование кода

Там где микросервисы всегда так. Бюджет большой а выход ноль.

@@alexb6036 ну не всегда. Долго работал в компании или где 10 сервисов на банке и в целом все не плохо.

@@alexb6036 нет. Там где не умеют в микросервисы а-ка EDA , а делают распределённые монолиты - там так, да. В общем-то во многих крупных русских компаниях почему-то не умеют в микросервисы и пилят распр. монолиты.

В чем заключается инфантильность?

Так а что в Украине лучше что ли?) Такое же рукожопие у вас дохрена народа сейчас воюет в армии РФ, прошло уже 2 года войны но в раше даже смогли наладить свой ВПК а в Украине волонтеры собирют дроны дома, что бы хоть как то удерживать фронт. Я конечно же осущдаю нападение на Украину но не нужно всех в РФ обсирать по любому поводу и делать вид как будто в РФ дно а в Украине рай. Я бывал и там и там. По моему обе страны на дне.

@@alexb6036 1. Это бот. 2. ИТ на украине на порядок выше классом, чем ИТ в России. потому что ИТ на украине это придаток ИТ в США, с их подходами , менеджментом и технологиями. У нас это почему-то "свой путь." Наблюдаю это на примере тех же "микросервисов". Только русские крупные компании продолжают делать распределённый синхронный монолит, вместо асинхронной EDA - трушной мс архитектуры. И ещё спорят с пеной у рта.