Микросервисы и точки отказа.

А вот теперь скажи мне, как ты собрался искать причину проблемы, проявившейся при интеграции сервисов?

Вцелом также как при интеграции модулей в один процесс, но с одним плюсом описанным ниже:

Воспроизводим проблему на тестовой системе, берём сервис в котором наблюдается непрядок. Даём доступ к стенду команде которая делала этот микросервис и задаём вопрос «ваш сервис лагает или ему данные неправильные дают?». Команда исследует знакомый ей сервис. По результатам отладки - «или косяк у нас» или «приходят плохие данные, вот инфа для анализа другой команде».

Если вместо микросервисов модули в рамках одного процесса - то на этапе «команда исследует знакомый ей сервис» иногда возникает затык в том что «вы как-то странно интегрировали нашу библиотеку, мы не знаем как её нормально отладить в таком контескте».

Из реальной практики с C++ без микросервисов - одна команда делала запутанную логику не жрущую ресурсы, а другая простую числодробильную. И собиралось только всё вместе с оптимизациями или всё вместе без, так как на винде были сложности собрать микс.

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

И собиралось только всё вместе с оптимизациями или всё вместе без, так как на винде были сложности собрать микс.

На винде же есть DLL. Не верю, что под каждый уровень оптимизации они разные.

И что, ты хочешь сказать, что в никсах не так, в никсах заранее известная структура сообщений? Байты текста — это еще менее структурированный формат, чем JSON.

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

там точно разное ABI у С++-ной библиотеки, разные экземпляры менеджера кучи в msvcr*.dll (аналог libc), и кучка каких-то ещё более мелких проблем с которыми продолжили иногда сталкиваться решив первые две.

И решение первых двух оказалось совершенно не интуитивным, каждому новому члену команды пришлось изучать набор «как не надо и почему».

Всегда снижай точки отказа

Our entire field is bad at what we do, and if you rely on us, everyone will die.

docker, kubern8s, микросервисы

Whatever they sold you, don't touch it. Bury it in the desert. Wear gloves.*

*5.5 Намеренное искажение правил русского языка.

Из реальной практики с C++ без микросервисов - одна команда делала запутанную логику не жрущую ресурсы, а другая простую числодробильную. И собиралось только всё вместе с оптимизациями или всё вместе без, так как на винде были сложности собрать микс

Кокое это всё имеет отношение к вопросу «микросервис-монолит»? Я бы начал с того, какого черта всё может собираться только с одной настройкой компиляции? Это что за такая волшебная модульность? И закончил бы тем, что да, C++ говно, но все хавают его вёдрами и просят добавки, и сделать с этим ничего в ближайшем будущем не получится.

В остальном проблема «а что это тут у вас, мы не понимаем», может случится при любой архитектуре системы.

Our entire field is bad at what we do, and if you rely on us, everyone will die
Whatever they sold you, don't touch it. Bury it in the desert. Wear gloves.*

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

Странно, что эти «технологии» выходят в свет из компаний, куда простым плебеям вход заказан, куда берут только по рекомендации + после кучи сложных технических и поведенческих интервью. А на выходе имеем бесконтрольность, безответственность, да и что греха таить, бесталанность.

Микросервисы разворачивают в основном в кластере кубернетеса в контейнерах. Никаких «серверов» как абстракции в данном виде не существует.

Бизнесу нужны решения здесь и сейчас, а не идеальные никогда. Типовое время жизни программиста на проекте года полтора и микросервисы это практически единственная возможность не оказаться спустя год-полтора с полностью новой командой перед монолитным лапшакодом, где сквозь монолит протянуто 100500 костылей из разных мест в разные места и поменять иконку стоит полгода дебага, т.к. от правки в одном месте рассыпается 100500 других, казалось бы не связанных мест. Причём это именно возможность, а не гарантия. Микросервисы говно, но монолиты в имеющихся кадрово-экономических условиях могут жить только первый год стартапа, пока надо наговнять серебряную пулю этого стартапа. И спустя год монолит должен либо сдохнуть вместе со стартапом, поскольку стартап оказался ненужной фантазией, либо проект будет признан стоящим развития, получит финансирование и для начала его быстрого роста во все стороны монолит безжалостно пилится на доменные зоны, каждая из которых отдаётся толпе свеженанятых программеров. А то, что топикстартер имеет только один локалхост для запуска нагрузки стартапа, говорит нам о том, что он работает в ларьке «У Ашота» и деньги Ашот зарабатывает на огурцах и луке, поэтому топикстартеру у Ашота не светит ничего кроме его древнего локалхоста.

Тебе сейчас про Kubernetes расскажут.

Слишком разные истории успеха. Рост - не всегда вертикальный. Иногда монолит может оставаться монолитом, быть продаваемым и приносить прибыль. Как пример - Hikvision. Капитализация - 5.6 млрд долларов. Основной род деятельности - системы видеонаблюдения. Программный продукт - линуксовый БИНАРНИК, который сам себе жнец, кузнец, и на дуде игрец, т.е. motion, nginx, proftpd, ntpd, ffmpeg и прочая в одном флаконе - монолит. И ничего, работает, обновляется, при чем работает намного быстрее аналогов.

Странно, что эти «технологии» выходят в свет из компаний, куда простым плебеям вход заказан, куда берут только по рекомендации + после кучи сложных технических и поведенческих интервью. А на выходе имеем бесконтрольность, безответственность, да и что греха таить, бесталанность

Ты о ком/о чем конкретно пишешь?

и поменять иконку стоит полгода дебага, т.к. от правки в одном месте рассыпается 100500 других

Как мне показалось, единственное, что микросервисы привносят в подобное это игру «угадай, в каком репозитории находится эта иконка».

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

... а оказаться вместо этого с микросервисной архитектурой, где сквозь десять сервисов протянуты костыли из разных сервисов в разные сервисы и поменять одну иконку стоит полгода дебага, так как от правки в одном сервисе сыпятся казалось бы не связанные сервисы. Это я уже не говорю про то, что поменять схему БД в микросервисах — mission impossible.

Мне иногда приходится ревьюить кастомерский говнокод. И больше чем лапшу, я ненавижу десятки include в include, где в каком-то 6-м инклуде стоит приглушение ошибок и хрен поймешь, что вызывает эту 500-ю ошибку. А ведь это всего лишь говнопых.

Если же микросервисы не имеют доступа друг к другу не иначе чем через API - наверное дебажить это сущий ад.

Мне иногда приходится ревьюить кастомерский говнокод. И больше чем лапшу, я ненавижу десятки include в include, где в каком-то 6-м инклуде стоит приглушение ошибок и хрен поймешь, что вызывает эту 500-ю ошибку. А ведь это всего лишь говнопых

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

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

Если же микросервисы не имеют доступа друг к другу не иначе чем через API - наверное дебажить это сущий ад

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

«поздравляю, гражданин, соврамши!»

Какой такой «поменять схему БД в микросервисах — mission impossible», когда у каждого микросервиса своя собственная независимая база данных, иногда даже денормализованная для сохранения развязанности между D этого самого DDD

А как же трейсинг со всеми его «тык в поиск по уникальному хидеру запроса» и получил подробнейший комплект трейсов внутри каждого микросервиса со всеми этими «на вход пришло то-то», «запросы в базу выглядели так-то», «в логи попало то-то» и «тайминги на колл такие-то»? Монолит в дебаггере надёжнее говоришь?

Блин, ну такими темпами я могу текстовый файлик на диске назвать «база данных». Имелось в виду все-таки что-то более-менее общее и организованное для пользования несколькими сервисами.

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

А ошибка на самом деле в совсем других сервисах, бг-г-г. Выше правильно писали про «детективную историю».

А, т.е. ты строишь распределённый монолит, но ругаешь микросервисы. Ясно, понятно.

И? В норме ты знаешь какой микросервис отвечает за облажавшийся функционал, посмотрел в его трейсы, отфильтровал нужные id запросов и увидев детали «вошло, отработало, вызвало, вернуло», назвал виновного. А не в норме детектив можно устроить в любом кривом решении на любой архитектуре. Не, если ничего не делать ради поддержания функциональной изоляции при микросервисной архитектуре, держать всех в одной общей базе данных, то да, толпой короткоживущих бизнес-задач и программеров быстро получишь распределённый сильно связанный монолит и будешь рыдать о том, что локальный монолит проще дебажится. Но в том, что у тебя получился распределённый монолит не микросервисы виноваты, а твои процессы.

Буагого! :-)

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

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

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

И вообще в треде куча людей окончательно потерявших связь с реальностью, мде

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

Ты прям будешь в лог пихать каждый запрос к каждому сервису? Ну так логируй все входы во все функции в монолите, один хрен будет, за исключением того что тебе distributed tracing не надо будет настраивать. Да и как бы все что ты написал вообще не относится к архитектуре самого приложения, только к расстановке точек логирования

В монолите скорее всего API которое ты вызываешь уже обновленно, в микросервисах скорее всего забыли. Часто такое бывает особенно в идентефикации.

архитектор, если уж он совсем гуманитарий

В каком месте встречаются такие архитекторы?

что их условный curl тратит 20мс на резолвинг доменного имени - это уже такое, неважное

Раз в час. Да, это неважное.

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

Короче тонна ненужных действий вместо тупо вызова функции

В каком месте встречаются такие архитекторы?

В любой галере.

Раз в час. Да, это неважное.

Если я узнаю что для сервиса «раз в час» мой программист наготовил лапшу из микросервисов - я его уволю за профнепригодность.

когда у каждого микросервиса своя собственная независимая база данных

О, этого тоже накушались, с характерными симптомами: «одна и та же сущность обрастает несколькими независимыми id» и «у разных компонентов системы разное мнение о состоянии этой сущности».

А, т.е. ты строишь распределённый монолит, но ругаешь микросервисы. Ясно, понятно

Да, ты всё правильно понял, мне нужна распределенная система, а не микросервисы.

Ты о ком/о чем конкретно пишешь?

Our entire field is bad at what we do.

В норме ты знаешь какой микросервис отвечает за облажавшийся функционал, посмотрел в его трейсы, отфильтровал нужные id запросов и увидев детали «вошло, отработало, вызвало, вернуло», назвал виновного

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

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

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

Далее, ты будешь в шоке, но лидеры рынка приходят именно к этому — единой распределенной БД на семейство задач. Да, их может быть несколько, два, три, но все равно очень мало. Просто потому, что бесконечный зоопарк БД держать ресурсоемко как по поддержке, так и по стоимости серверов (общие данные можно закэшировать и просто не нужно повторно хранить). Для справки — весь парк мускулей на петабайты данных в фейсбуке поддерживается десятком админов.

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

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

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

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

Этого символа на клавиатуре нет.

У меня был клиент, у клиента магазин, тоже разделенный на «микросервисы» на разных серверах. Так было круче. Но потом он разосрался с гением сей чудной мысли, и обратился на фриланс с проблемой: продукты не добавляются в интернет-магазин. У него престашоп + куча хрен пойми зачем микросервисов, которые то тырят продукты с ценниками с алиекспресса, то ищут для них картинки, то конвертируют их в png, хранится все это на четвертом сервере, и тд итп. В общем все то, что я бы сделал одним скриптом на одной железке - было разнесено на ШЕСТЬ. Так вот продукты просто не добавляются. Но это видно уже в конечной веб-морде.

Потратил НЕДЕЛЮ. Денег заработал много. А причина оказалась банальна: хостинг провайдер четвертого сервера, решил поиграть в мега-сусурити, активировал файервол, и забанил нестандартные порты. При том, сообщение в логах про connection timeout, как ты понимаешь, генерировалось не на четвертом сервере, а на третьем, и определить, к чему там connection timeout, физически было невозможно. Починил случайно, поставив на каждый сервер свой самописный скрипт для мониторинга, увидел что нестандартные порты забанены, влез в файервол, открыл ВСЕ порты - заработало.

А вот где 100% нужны микросервисы - это в IOTне.

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

У меня сосед через квартал, типа новый русский, потратил на эти дорогие игрушки овер много денег, и не смог попасть домой. Оказывается его замок atis коннектится через какой-то роутер к какому-то «хабу», определяет чуть ли не отпечаток пальца на другой системе (не атисовской) и эта штука разрешает открывать замок или нет. Роутер потух - дом превратился в тыкву. ССЗБ конечно что физический ключ оставил дома, но пример поучителен.

Кмк «у меня ничего не работает» это не самое страшное. Страшно когда сервисы А и Б отработали, а сервис В выдал ошибку, в итоге часть сервисов транзакцию в базу закоммитила а часть нет, и финальный стейт зависит от фазы луны и порядка вызовов (и не дай бог они параллельные). Вот этот пипос очень больно откатывать

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

Замком должен заведовать свой сервис

Лол блин я один раз час просидел в проходной в цоде когда первая дверь сработала а на второй замок подвис после обновления и охранник бегал искал как его ребутнуть. Танунах, только механика.

Это я уже не говорю про то, что поменять схему БД в микросервисах — mission impossible.

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

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

«одна и та же сущность обрастает несколькими независимыми id»

Зачем? У сущности есть только один публичный глобально уникальный ID (например, UUIDv4), а что там внутри БД произвольного микросервиса ещё может храниться — не важно, это не должно выходить за пределы микросервиса.

для сервиса «раз в час» мой программист наготовил лапшу из микросервисов

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

Зачем?

Не знаю зачем, так просто получается.

не должно выходить за пределы микросервиса

Не должно. Но на практике всё равно выходит.

А у тебя конкретные примеры есть, или «просто получается»?

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

Ну и по своему опыту могу подтвердить, никаких проблем избегать зоопарка «независимых ID» ни у меня, ни у моих коллег никогда не было.

А вот где 100% нужны микросервисы - это в IOTне.

У меня сосед через квартал, типа новый русский, потратил на эти дорогие игрушки овер много денег, и не смог попасть домой. Оказывается его замок atis коннектится через какой-то роутер к какому-то «хабу», определяет чуть ли не отпечаток пальца на другой системе (не атисовской) и эта штука разрешает открывать замок или нет. Роутер потух - дом превратился в тыкву

При чем тут микросервисы, если олписанная проблема заключается в единственной точке отказа. С микросервисами или без, если у тебя есть точка отказа — она откажет. Потому у белых людей принято иметь независимые дублирующие системы.

Но смищно когда все микросервисы разворачивают на одном сервере, но это ССЗБ

«смищно», если ты думаешь, что микросервисы только для запуска на нескольких серверах :D

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

Так читай выше: БД разные, они всё комитят в разнобой. Как это собирать — понятия не имею, пусть stalkerbss рассказывает.

В нормально сделанных микросервисах

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