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

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

Боже мой, какой УЖОС, сделать трейс и размотать цепочку и поспрашивать всех по одному. А, вы не сделали трейс? А кто вам его должен был сделать? Да, в распределённой системе нет стектрейса как везде. Откуда же ему там взяться? Его надо делать руками, надо чтобы микросервисы были умненькими, могли за себя ответить в случае чего. Вы что не знали? А чем вы думали, когда садились пилить свой монолит? Из астрала хотели трейс доставать? Ну кто вам теперь доктор.

Кодерки сделали говно и, ууу, как страншо, всё отваливается, транзакция не коммитистя целиком.

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

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

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

А микросервисы этот ущерб обычно увеличивают.

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

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

Для чего-то, что в монолите всегда просто работало, надо прикладывать усилия, а что-то, что на микросервисах просто работает, на монолитах вообще недостижимо. Тут не бывает серебряных пуль, всё как всегда.

Примерно эту вещь в этом треде я и пытаюсь выяснить.

Как отличить культизм от реальной необходимости использовать микросервисы?

а что-то, что на микросервисах просто работает, на монолитах вообще недостижимо

Например?

Как отличить культизм от реальной необходимости использовать микросервисы?

Когда монолит объективно не может сделать то, что от него хотят, или очевидно, что он не сможет это сделать, тогда его и пилят. Например, еще на этапе проектирования подразумевается какая-то жирная обработка сервером несвязанных между собой данных. Тут всё понятно, что сервер, какой он там толстый не будет, быстро упрётся в железо и надо делать как минимум сервис-насяльника и сервисы-работяги.
А когда у нас был acid, нам нужен был acid, всегда это работало нормально только через acid, но тут пришли хипсторы и подвернули всем штаны, то понятно, что дело имеем с Культом. Это как была касса, там сидела кассирша и принимала деньги. Потом к ней подсадили еще двух: одна деньги принимает, другая их считает и складывает, третья выдаёт чек и сдачу. Между собой они ни в коем случае не общаются, каждая делает только свою работу и посылает всех нахер. Зачем? Потому что так модно и прогрессивно.

Например?

Горизонтальное масштабирование, возможность горячей замены, резервирования и репликации кусков системы.
Ну вы чо? Всё же примеры распределённых систем всегда перед глазами и работают уже много лет. Возьми, например, DHT и битторент. Для хттп файлопомоек обмен данными такого масштаба просто невозможен. И игруны, например, встраивают себе его в лаунчер, чтобы народ не нагибал из сервачок после каждого обновления. Ну или cdn какой-нибудь с dns.

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

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

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

А на что тебе лоадбалансер будет раскидывать нагрузку? На один единственный монолит? И смысл? Плюс запросы бывают разные. Бывают худые, а бывают жирные. И худым бы не надо, чтобы рядом кто-то жиром трёс, ложил им базу и мешал жить. Так и появляются домены под микросервисы, а потом приходит осознание, что acid на самом деле не сильно-то и нужен в некоторых местах, можно на него положить хер, разъехаться, и жить отдельно.

А на что тебе лоадбалансер будет раскидывать нагрузку? На один единственный монолит?

На монолит запущенный на нескольких компьютерах, коль уж одного не хватает.

(Вообще мода на микросервисы похоже пошла ещё из-за того, что вместо того, чтобы купить пару-тройку нормальных компьютеров, люди пользуются тонко нарезанными виртуалочками за 5 долларов за гигабайт рамы в месяц)

Меняй окружение, лол.

Не совсем тебя понял.

Вот так ГИС ЖКХ сделали монолит сраный, который работает в Москве и прикладывается спать, когда народ со всей страны начинает передавать в конце месяца платёжки. Такие же не криворукожопые делали с вёдрами вместо головы. Даже федерацию не смогли осилить, не то, чтобы какие-то там тестовые окружения.

Монолитность \ микросервисность тут ни при чем. Здесь есть бутылочное горлышко (например слабый сервер для такого количества запросов). Какая разница ЧТО на этом сервере потухнет - монолит или микросервис ?

На монолит запущенный на нескольких компьютерах, коль уж одного не хватает.

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

Вообще мода на микросервисы похоже пошла ещё из-за того

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

нарезанными виртуалочками за 5 долларов за гигабайт рамы в месяц

Краежопить на серверах конторе, которая что-то там зарабатывает на своей ИС как минимум странно.

Не совсем тебя понял.

Работаешь с вордпрессами рассуждаешь что-то про архитектуры.

Монолитность \ микросервисность тут ни при чем.
Какая разница ЧТО на этом сервере потухнет - монолит или микросервис ?

Ты не понял нихрена походу. Распределённые системы затем и существуют, чтобы не иметь одной точки отказа. Если кто-то там сделал вместо вызова функции/метода сетевой и назвал это говно микросервисами, то это ничего ровным счётом не значит. Микросервисная архитектура это про распределённые системы см, опять же CAP теорему. Не нужна согласованность, берешь доступность и устойчивость к разделению. Нужна согласованность, отдаешь доступность или устойчивость. Но делуны, конечно, есть такие, что сядут на оба стула, выколов себе глаза вилкой.

Работаешь с вордпрессами рассуждаешь что-то про архитектуры.

1. Работаю с тем, что дают;

2. Это был пример;

3. Твое выражение из разряда «зачем мне пельмени, я же заказывал еду». Чувак, архитектура - это архитектура. CMS - это CMS. Они ни отменяют друг друга, ни взаимодополняют.

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

Распределенная система - это распределенная система, оно существовало задолго до микросервисов.

Микросервисная архитектура это про распределённые системы

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

Архитектура из одного ЯП-файла, который загружает картинку на сервер через поле ввода, и который ее конвертирует в PNG - монолит. Архитектура из ЯП-файла, который загружает картинку на сервер через поле ввода, и ЯП-файла который конвертирует загруженные картинки в PNG не опираясь на первый ЯП-файл - микросервисная. Всё. Никаких распределенностей.

С одной стороны такой способ удобен. Если нужно переделать конечный формат с PNG в JPG - достаточно отредактировать один модуль. С другой стороны, если вдруг возникнет ситуация, когда PNG-картинки не появляются на сервере - придется копаться во всех модулях чтобы понять - картинка не загрузилась, или картинка не сконвертировалась.

Все что ты написал - вполне себе делается в монолитной системе, которая кстати говоря, тоже может быть распределенной. Даже ванильный Wordpress ты можешь сделать таким, что MySQL использует на одном сервере, веб для API на другом сервере, а контент хранит и берет на третьем сервере. И сам вызывается через proxy_pass используя например round robin. И шо ? От этого он не стал микросервисным.

Сейчас такая мода на микросервисы

примерно с 2010 года

Но смищно когда все микросервисы разворачивают на одном сервере

да смищно, а это где так?

Притом админ при каждом обновлении фронта и бэка ставиться бешенной собакой

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

Обновления «экосистемы» становяться каким-то нетривиальным делом. Еще и микрофронтэнд тут сбоку подползает.

нетривиальным это да

Вам нужно срочно нанять несколько девопсовс 300К штука, крутых архитекторов и все переписать под их хотелки

короче нужен опыт, вы конечно его в итоге родите, но табличка «в связи с переходом на новую программу работа замедленна» будет вас позорить…

в общем обратитесь к специалистам

хороший, годный тред, может быть стоит заходить на лор чаще раза в месяц. Хабр давно не место для общения, и заходить не стоит, так что только reddit и остаётся.

http://book.mixu.net/distsys/single-page.html - просто оставлю тут. Кто захочет ознакомится.

Горизонтальное масштабирование …

Всё же примеры распределённых систем всегда перед глазами и работают уже много лет. Возьми, например, DHT и битторент.

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

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

Lisp. Любая SQL СУБД.

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

контракты?

поменять схему БД в микросервисах — mission impossible

4.2

Ты опят бредишь на основании своего опыта в ларьке у Ашота?

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

От уровня оптимизации не зависит. Но есть две версии libc, дебажная и релизная и вместе в одной программы разные libc использовать нельзя.

Но без оптимизации можно собирать и с релизной версии libc.

Обычно трассировка делается для каждого N-го запроса, либо включается для запроса безусловно при наличии какого-нибудь специфического заголовка, например.

Обычно трассировка делается для каждого N-го запроса, либо включается для запроса безусловно при наличии какого-нибудь специфического заголовка, например

В этом случае ты потом умрешь искать почему куда-то внезапно пришёл null

Но есть две версии libc, дебажная и релизная и вместе в одной программы разные libc использовать нельзя.

А все остальные библиотеки кроме libc там тоже принято держать в двух экземплярах?

А все остальные библиотеки кроме libc там тоже принято держать в двух экземплярах?

дебажная версия libc не входит в redistributable и устанавливается только вместе с компилятором и не предназначена для конечного пользователя.

Переодически приходят запросы от пользователей распространять дебажные библиотеки тоже: https://developercommunity.visualstudio.com/t/220262

Но да. Все библиотеки тоже в двух экземплярах, например вместе с Qt Creator устанавливаются и дебажная и релизная версия Qt, boost тоже распространяет две версии.

Любой адекватный кодер такое предусмотрит и допускать не будет

Конечно предусмотрит. Ровно до момента пока до него не дойдёт пм и не обрадует что «в ответ Х надо досыпать Y чтоб юзеру красиво было», а для «юзеров с опцией А надо проставлять Б и запрещать В», которые кстати в трех разных сервисах сидят. И буквально через пару таких запросов все твои адекватные границы сервисов полетят псу под хвост, потому что ты будешь на каждый чих десять раз по сети бегать, создавая нагрузку на ровном месте

Но да. Все библиотеки тоже в двух экземплярах, например вместе с Qt Creator устанавливаются и дебажная и релизная версия Qt, boost тоже распространяет две версии.

И всякие DirectX, COM, ASP, драйвера к Kinect, … тоже? Ужас какой.

В этом случае ты потом умрешь искать почему куда-то внезапно пришёл null

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

По трассировке сразу видно, в каком сервисе «что-то пошло не так»

Ты же пишешь «трассировка делается для каждого N-го запроса». То есть вероятность того, что на внезапный null есть трассировка равна 1/N.

И всякие DirectX, COM, ASP, драйвера к Kinect, … тоже? Ужас какой.

Да, но не для всего. Сейчас погуглил, например DirectX 9 debug runtime есть только для Windows 7, для более поздних версий Windows нужно либо разрабатывать на более новой версии DirectX, либо использовать Release Runtime.

https://social.msdn.microsoft.com/forums/office/en-US/e495cb7d-f199-4b3e-a291-94ae56fed87f/windows-10-directx-debug-runtime-not-loaded?forum=windowsgeneraldevelopmentissues

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

А ты смищной. Напомнить основную задачу любого коммерческого предприятия?

Так вот, «да» тебе все равно придётся сказать, как бы ты не крутился. Можно торговаться, пугать сроками, выбивать уступки, можно перекинуть часть работы на фронтов и попытаться разбить на подзапросы (спойлер: фронты будут не рады), но в конечном итоге тебе придётся расслабить булки и протащить ту логику, которая нужна бизнесу. Хотя бы потому что именно за это тебе платят.

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

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

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

Микросервисная архитектура - это про модульность

Я бы немножко остановился здесь. Я считаю, что в модульность почти никто на массовом рынке не умеет. Тесно сплетенные микросервисы, где падение одного валит всю систему, являются примером слабой модульности. То есть, модульность — это степень независимости кода от другого кода. Получить отказоустойчивые модули-сервисы можно в рамках одного процесса ОС — смотри Erlang. Что кому-то когда-то пришло в голову называть настоящей изоляцией только помещение в разные контейнеры — это его проблема. Мы лишь применяем к этой модели слово «микросервисы». Нам лишь важно, что микросервисы не обязательно будут модульны, и не обязательно распределенные — несмотря на то, что чисто в теории подразумевается, что микросервисы будут модульны и распределенны. Это как можно построить самолет из соломы, но он не будет летать и на него нельзя будет установить реактивный двигатель. Но он будет похож на самолет.

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

контракты?

Ты хочешь рассказать, что «соблюдайте контракты — и у вас система падать не будет?». Прохладна история. Хорошо, когда всё хорошо, но когда всё плохо — тогда всё плохо.

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

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

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

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

Да, нормальный читабельный npe и после него тыща строк говна. Или, для любителей, эрланговые фигурные скобочки, 500 килобайт на одно сообщение.

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

Я еще в году 2007-м писал панельку управления сервером (то что сегодня зовут Cpanel), так у меня все фронтендовые действия были четко отделены от бекенда: гуй перезапускающий апач, записывал в бд команду «restartapache», крутящийся в памяти демон, видел эту запись, рестартил апач и срал в лог. Но это делалось исключительно с т.з. безопасности, и если бы я писал это ДЛЯ СЕБЯ, то просто делал бы <?php exec('service httpd restart');?> как это делается в современных ЦПанельках.

И обзывать это какими-то микросервисами у меня и в голове никогда не было, как и у десятков тысяч других нормальных людей =) Хотя звучит однозначно круто «микросервис рисующий кнопку Restart Apache; микросервис выполняющий перезагрузку Apache»

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

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

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

В подавляющем большинстве - да. Я ж об этом и говорю.

Думаю из 100% проектов, разнесение в модули оправдано для 10-20 процентов, остальное просто для соответствия тренду.

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

Например ?

Назови мне ТРИ известных тебе продукта, с тезисным описанием каждого из них. Даже интересно.

Да, нормальный читабельный npe

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

это не программирование встало с ног на голову, а суровая реальность в пересчёте на среднее по случайной выборке из 100 программистов даёт лучшие результаты в виде микросервисов. Это как с переходом армий с калибра 7.62 на 5.45: сотня случайных солдат на оружии с меньшей отдачей будут чаще попадать в цель.

эта вероятность начинает стремительно уменьшаться

Вероятность поймать ошибку? В смысле вместо 1/N становится 1/100N ?

За счёт того, что даже если трейс есть, его надо ещё угадать из сотни логов?

Если твое приложение перестает работать по контракту - оно откатывается на предыдущую версию. Автоматически.

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

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

Racing condition, thundering herd, в конце-концов некоторые инварианты (то есть неформальные контракты), на которые опирался третий сервис (не один и не второй), что часто слдучается в достаточно сложных структурах данных с динамическими типами. Если бы всю отладку можно было бы уткнуть в набор контрактов, то разрабатывать софт было бы очень и очень просто. Но выясняется, что у одного модуля есть 10 вариантов исполнения, у второго 10, у третьего десять — и внезапно оказывается 1000 вариантов выполнения. За миллион перескочить можно вообще изи, но даже если прямо все-все сценарии учесть, то все равно один-два пропустишь, и именно они выстрелят в проде.

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

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