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

монолиты рулят потому что стектрейсы читать это очень удобно

На фоне «стектрейса» по дюжине сервисов (А вызвал Б, тот вызвал В, тот вызвал … Л, тот вернул ошибку и все по цепочке тоже получили ошибку), который часто еще надо руками собрать, и который часто неполон, так как «трассировка делается для каждого N-го запроса», монолитный стектрейс читать очень удобно.

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

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

все эти вещи не решаются технологиями, что не применяй, многие этого так и не поняли

Микросервисы это просто способ организации. Где-то он нужен, где-то нет.

Как и любой инструмент его можно применять правильно и неправильно.

То что во многих случаях это превращается в кашу, так это не проблема микросервисов, а проблема людей и команд. Им что не дай - лучше не будет.

Ад - он в головах твоих товарищей.

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

Ад - он в головах твоих товарищей.

скорее - руководства )

главное - это планирование задачи и общий проект

Наверное, все-таки грамотная, целенаправленная организация всех процессов, и (пере)планирования в том числе.

Ты вообще хотя бы кибану видел (не будем пока говорить про splunk)? Логирование в Sentry? Блин, ей-богу, как будто в 2010 вернулся.

ну, если вам охота непременно как-то перефразировать сказанное, то почему бы и нет

А что делать, когда контракт меняется? Сервис информации о пользователях должен в новой версии предоставлять поле «возраст».

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

Humans (социалка+финтех+виртуальный опсос). Juno (такси). Вебня в world of tanks (хотя у нас тут прям чистых микросервисов немного, большинство выполняет несколько функций, и есть парочка древних монолитов, где это оправдано или переписывание слишком дорого).

Как написать много слов, и не сказать ничего. Ты случайно не родственник anonimous’а?

Микросервисы это возможность сделать сервис без единой точки отказа. Эта возможность стоит определенных денег. На начальном этапе она может быть не нужна. Поэтому ничего плохого в том, чтобы развернуть их на одном сервере - нет. Со временем появится несколько серверов, деньги на кластер и развернут без точек отказа. Архитектура позволяет.

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

Смысл микросервисов в том, чтобы быть гибкими в плане реализации. Когда можно каждый микросервис писать на разных ЯП, к примеру. Или разными программистами. С минимальным взаимодействием, достаточно утвердить API.

Но всё это сопряжено с рядом сложностей, да. Если где-то становится проще, то где-то становится сложней. Но в целом мир движется в этом направлении и для этой сложности есть свои решения. Ничего плохого в микросервисах нет.

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

Но при типичном рейте запросов от тыщи рпс эта вероятность начинает стремительно уменьшаться

Ты серьёзно утверждаешь что если ты включаешь трейсинг для каждого N-ого запроса, то вероятность будет ли у запроса включён трейсинг или нет зависит от рпс?

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

Суть всей дискуссии что микросервисная архитектура имеет смысл в достаточно редком и узком кругу задач, и она имеет весьма нифиговую стоимость как в ресурсах, так и в людях. Когда во всей компании всего 3-4 бэкендера и нет даже выделенного админа (что абсолютно нормально для большинства небольших компаний) - никакие микросервисы не нужны, только хуже будет. Вон прям как в примере выше про сервис транзакций - он нахрен не нужен если у тебя всего один продукт. Как и mq и прочие навороты. Это создаёт хайлоад на пустом месте и поднимает стоимость обслуживания в потолок

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

Сорри за простыню, весь этот тред мне наступил на больное. Я не спорю что оно все нужно, смысл что оно нужно гораздо реже чем его рисуют

Лично я бы советовал сервисную архитектуру. Это когда команда до 5-10 разработчиков работает над одним проектом. Если требуется больше - то уже выделяется два сервиса и тд

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

Я пытаюсь понять почему «эта вероятность (поймать ошибку) начинает стремительно уменьшаться». Это твоё утверждение.

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

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

Ты серьёзно утверждаешь что если ты включаешь трейсинг для каждого N-ого запроса, то вероятность будет ли у запроса включён трейсинг или нет зависит от рпс?

Я говорю, что увидеть проблему (если она есть) будет проще, и только.

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

60k rpm это далеко не фаанг :) На самом деле, в том же мобильном гейминге нагрузки дай боже.

Ни разу бложик на микросервисах не видел?

А вот это уже извращение

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

Видимо, у меня реально какой-то другой мир вокруг. В моем люди используют микросервисы с умом.

Микросервисы и точки отказа. (комментарий)

видимо, у нас недопонимание возникло

А потом в сервисе обнаруживается ошибка при какой-то комбинации данных и оно откатывается на предыдущую версию.

Почему оно должно откатиться? Зачем ты мешаешь контракты с багами?

И так пока версии не кончатся, после чего всё упадёт.

Утрирование такое утрирование.

60k rpm это далеко не фаанг :) На самом деле, в том же мобильном гейминге нагрузки дай боже.

Звучит как задача под (веб)сокет если честно. Но да, я про вебню говорю, для веба 60 килорпс даже у крупных типа Я далеко не всегда и не везде.

Звучит как задача под (веб)сокет если честно. Но да, я про вебню говорю, для веба 60 килорпс даже у крупных типа Я далеко не всегда и не везде.

Вебсокет тут не очень, это чистый бэк, сервис аутентификации, в который долбится urlllib’ом игровой сервер.

Ща вон свежак подогнали коллеги: напилили сервис логирования ивентов UI игрового (изучают приколы scaleform in the wild, плюс аналитика UX). На перфе выдавили 110k rps, потом умерла кафка :)

Микросервисы это возможность сделать сервис без единой точки отказа

В итоге точка отказа у нас в кафке и раббите 🐱‍👓

Кафка кластеризуется. Запусти в трех экземплярах и всё. Раббит вроде тоже.

это чистый бэк, сервис аутентификации, в который долбится urlllib’ом игровой сервер

У вас два сервера друг друга по хттп долбят? Звучит больно. Да и на таком рейте кмк проще если есть возможность ждать N мс собирать батч и слать пачкой, иначе если запросы мелкие (как это обычно с авторизацией бывает) будет дикий оверхед на сеть. Но я не настоящий сварщик, могу ошибаться

потом умерла кафка

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

Но всё это сопряжено с рядом сложностей, да

И ещё с высокой начальной стоимостью поддержки. У монолита эта стоимость растёт быстрее, но у микросервисов она изначально конская. Хочешь трейс - нужно поддерживать инфру для него, грепнуть три сервака уже не выйдет. Хочешь деплой без тонн боли - аналогично, сидишь ваяешь blue-green велосипед. Хочешь быть гибким и не юзать провайдерский control plane - изволь сам часами искать какого хрена у тебя ipvsadm показывает 6 адресов вместо 4 или почему сварм опять провафлил очистку внутреннего dns. И это даже не говоря про то насколько больнее распределенную систему тестировать и поддерживать инфру для qa.

как ты обычно обрабатываешь переводы строк в именах файлов

Я сейчас на винде (т.к. речь о PS) за десять минут не нашёл ни одного способа создать файл с переводом строки в имени. Что это за магия? А главное нах*я?

Я сейчас на винде (т.к. речь о PS) за десять минут не нашёл ни одного способа создать файл с переводом строки в имени. Что это за магия? А главное нах*я?

Под виндой к файлам более жесткие требования, там можно с такими работать, но тулза должна использует UNC path, которые с префиксом \\?\.

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

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

Зачем ты мешаешь контракты с багами?

Нарушение контракта всегда является багом. При достаточно полном контракте баг всегда является нарушением контракта.

В нашем примере сервис при какой-то комбинации данных вернул результат без нового обязательного поля. Контракт нарушен. Что дальше? Всё падает сразу? Ошибочные данные идут дальше? Что-то ещё?

Почему оно должно откатиться?

Так тебя спросили, что будет при нарушении контракта. Ты ответил, что автоматический откат на предыдущую версию.

Я сейчас на винде (т.к. речь о PS) за десять минут не нашёл ни одного способа создать файл с переводом строки в имени.

Запустить bash и создать.

Код с нормальной документацией всего лишь в два раза дороже кода без документации вообще. Это же не поиск багов, который может быть бесконечен, а вполне формализованный процесс.

Код с нормальной документацией всего лишь в два раза дороже кода без документации вообще. Это же не поиск багов, который может быть бесконечен, а вполне формализованный процесс

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

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

Претензия ко мне было про «напишите четкие контракты, и у вас ничего за пределами сервиса не сломается».

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

Претензия ко мне было про «напишите четкие контракты, и у вас ничего за пределами сервиса не сломается».

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

У вас два сервера друг друга по хттп долбят? Звучит больно. Да и на таком рейте кмк проще если есть возможность ждать N мс собирать батч и слать пачкой, иначе если запросы мелкие (как это обычно с авторизацией бывает) будет дикий оверхед на сеть. Но я не настоящий сварщик, могу ошибаться

Все так и есть, запросы батчами летят. А там где реальная аутентификация происходит на стороне xbox live/psn - там вообще отдается серверу 202 и асинхронная проверка.

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

Может и поэтому. У нас отдельные команды дба, инфры, рутов. Хотя вот на том же Juno справлялись силами 1 дба и трех девопсов на три сотни микросервисов с кафками, двх и прочим.

В нашем примере сервис при какой-то комбинации данных вернул результат без нового обязательного поля. Контракт нарушен. Что дальше? Всё падает сразу? Ошибочные данные идут дальше? Что-то ещё?

Он просто не задеплоится, тесты упадут и произойдет откат.

Он просто не задеплоится, тесты упадут и произойдет откат.

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

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

Алсо при аудитории в несколько миллионов человек можно себе позволить заигнорить проблемы у 50 (кстати, они напишут максимум 20 отзывов).

слепые кутята

Я теперь знаю как называть junior Qt developers

Алсо при аудитории в несколько миллионов человек можно себе позволить заигнорить проблемы у 50 (кстати, они напишут максимум 20 отзывов)

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

Всё, что вам нужно знать про гарантии целостности данных-логики в современных микросервисах

В монолитах не так?

Лови задачку: у тебя есть игровой сервер (горизонтально масштабируемый монолит), написанный десять лет назад. Тебе надо научиться считать рейтинги среди игроков по суммарной эффективности за день/неделю/месяц и отдельно по их результатам в каждой роли (танк, хил, снайпер и т.п.). В сутки играется десять миллионов игровых сессий по 10 игроков в каждой. Предлагай решение.

В монолитах не так?

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

Лови задачку: у тебя есть игровой сервер (горизонтально масштабируемый монолит), написанный десять лет назад. Тебе надо научиться считать рейтинги среди игроков по суммарной эффективности за день/неделю/месяц и отдельно по их результатам в каждой роли (танк, хил, снайпер и т.п.).

И в чём проблема? Делаешь ещё один поток и в нём считаешь. Агрегированную статистику хранишь в БД сервера (ещё в одной таблице).

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

Да нихера ты не знаешь, вротпрессник :)

И шо ? От этого он не стал микросервисным.

И то, что про это вам и говорят весь тред.

Лови задачку: у тебя есть игровой сервер (горизонтально масштабируемый монолит), написанный десять лет назад. Тебе надо научиться считать рейтинги среди игроков по суммарной эффективности за день/неделю/месяц и отдельно по их результатам в каждой роли (танк, хил, снайпер и т.п.). В сутки играется десять миллионов игровых сессий по 10 игроков в каждой. Предлагай решение

Люблю разговоры по делу. Прежде всего я бы хотел заметить, что постановка задачи странная. Почему не «в сутки десять тысяч игровых сессий длиной 5-50 часов с открытым бесшовным игровым миром в каждой сессии, 100 человек одновременно и 5-20 тысяч за сессию»? В CS 1.6 картина была в несколько раз меньше (20 человек макс, под сотню игроков за одну сессию), но на то она и спиномозговая стрелялка, а не MMO. Изначально твое условие задачи является решением, оптимизированным под микросервисы. Естественно, что оно по крайней мере будет решаться микросервисами (не обязательно лучшим образом, это не важно).

Мое решение «в лоб»: одна или несколько сессий на серверный воркер, который обслуживает все функции сессии от начала док конца, и он же собирает статистику по своей сессии. Эта стата добавляется в режиме append-only в распределенную БД, потом map-reduce достается стата, которую нужно отобразить игроку. Можно делать промежуточную агрегацию аля ETL для старых данных, чтобы периодически превращать старые сырые данные в компактную выжимку, разгружая серверы.

Так это как раз контрпример. rtorrent является просто каноническим примером монолита.

Там «монолит» только каталог.

Lisp

Што лишп?

Любая SQL СУБД.

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

«в ответ Х надо досыпать Y чтоб юзеру красиво было»

И в чём проблема в ответ на X досыпать Y?

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

Давай нормальный пример из практики. Твои теоретизирования - ни о чём.

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

Так тут нет «никакого срока релиза». Да и вообще нет релизов. Ты тоже не понял, в чём вся соль и почему все так с них прутся. Можно релизить кусками. У тебя какая-нибудь кор команда всё сделала, а остальные от них пляшут. Не вывалили отчеты, ну и хер с ними, когда сделают, тогда сделают. Остальная часть системы же работает.

Можно релизить кусками. У тебя какая-нибудь кор команда всё сделала, а остальные от них пляшут. Не вывалили отчеты, ну и хер с ними, когда сделают, тогда сделают. Остальная часть системы же работает

У меня дежавю на модульные монолиты. Вот прям слово в слово так и было.

В твоём микросервисе будет точно такой же

Точно такой же, только в 10 раз меньше, если речь именно про стектрейс.

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

Ну как бы тебе сказать. Там где у тебя везде rpc, словить какой-нибудь null pointer exception становится намного сложнее, просто из-за низкой связанности и более строгого контроля входных параметров. И вообще оказывается так, что любая динамическая дрисня при таком использовании оказывается более строготипизированной, чем типа все строгие и типизированные язычки.

У меня дежавю на модульные монолиты.

Ничего нового под солнцем. Просто другой механизм взаимодействия модулей + связанные с этим плюшки.

монолитный стектрейс читать очень удобно.

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

Ничего нового под солнцем. Просто другой механизм взаимодействия модулей + связанные с этим плюшки

Да. Наиболее близкая аналогия «зачем нам вызывать функцию напрямую, если можно бинать запустить отдельным процессом — же безопаснее». Ну как бы да... а может и нет. Когда выбора нет и есть только бинарь, то выбора нет, но добровольно идти на жирную НЕНАДЕЖНУЮ прослойку межмодульного взаимодействия ради какой-то абстрактной архитектуры — это такое-себе. Это то, что убило никсовое башеговно, то, почему Meson+Ninja сейчас нагибают раком Autotools+Make, поскольку первый работает эдак раз в СТО быстрее, чем башпортянки, при этом имея минимум зависимостей и точек отказа.