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

не путай божий дар с яичницей!

Знакомьтесь: https://habr.com/ru/post/86876/

Ты никогда не задумывался, почему шатлы никогда не садились по автопилоту? У них ведь тоже были автопилоты. Посадка утюга с крыльями — не такая сложная задача, но в случае отказа астронавты уже в кабине будут рвать волосы на голове и кричать «вернись». Хитрожопые совки ведь не посадили космонавта в кабинку, заметь. Именно так рвут волосы на голове пилоты современных Airbus/Boeing, между прочим, которые докатились до того, что компы имеют приоритет в принятии решений, то есть, если человек решил спасти самолет, а компьютер — разбить его, то самолет разобьется. По иронии судьбы, первый же Airbus с таким компьютером разбился на презентации. Или вспомни проблему с датчиком угла атаки, который внезапно и очень резко разворачивал самолет носом вниз — сказочная отказоустойчивость, ага. Проблема автопилота НЕ РЕШЕНА ДО СИХ ПОР, ололо. Проблема как в обработке отказов, так и во внешних условиях, вроде других самолетов — всю эту информацию агрегировать и использовать для принятия решений крайне сложно, это тебе не утюг с крыльями посадить на стерильно чистую полосу с полностью исправным сигнально-посадочным оборудованием.

Если тойота решила что-то писать на голых сях - скорее всего у них были на это основания

Я тебе скажу. какие основания: «мы аккуратно, у нас ответственные работники, всё получится, к тому же, вся индустрия пишет прошивки на Си — мы чо, самый лохматые, чтобы другой ЯП брать?». И получилось то, что всегда получается при программировании ПО для машины Тьюринга на низкоуровневом ЯП без архитектуры — нескончаемая череда глючных контроллеров, которые полируют-полируют, полируют-полируют, но баги не кончаются, а просто становятся намного реже. Аргументация плана «все равно какая-то часть разобьется в авариях по вине водилы, наши сбои на этом фоне отсвечивать не будут».

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

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

Я прекрасно знаю задачи — я это контроллеры писал.

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

Я стебусь над вполне конкретной культурой микросервисов, а не микросервисным подходом в общем.

Значит у них не задачи а херня, всё можно зделать на пхп и говорить вообще не о чём

Где-то тихо в углу засмеялся Цукерберг.

А если платежи отвалились, когда у бухов отчеты идут?

И что? У бухов холодные данные

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

Так там в любом случае нельзя будет делать заказ, если таки легло что-то критическое

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

и цифровую подпись в банке, которая не работает на 10% устройств.

И какое отношение фротнэнд банка имеет к сабжу?

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

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

Ну вот, видишь, ты и сам уже согласен, что микросервисы - это няшно

Вообще-то NewSQL БД — это классические монолиты, зачастую даже не модульные.

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

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

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

Сеть прилягла до бд. Не что-то такое из ряда вон. Недавно было такое, например

Я фанат SQLite.

Заплатить-то заплатили, а толку с этого? Оплата должна приводить к оказанию некой услуги, а не просто к получению квитанции

В нашем случае, например, достаточно просто квитанции

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

Ты опять начинаешь говорить о сферических в вакууме системах, идеальных донельзя. Повторюсь: мы не делаем систему управления АЭС. Речь об обычной коммерческое разработке, где можно фейлиться, надо просто узбагоить свое чувство прекрасного

Конечно. Потому на самом деле вам микросервисы изначально не нужны были. Дальше уже кому как нравится, тот так и делает, но НЕОБХОДИМОСТИ нет.

Ты никогда не задумывался, почему шатлы никогда не садились по автопилоту?

Я не уверен, что вы правильно задаете вопрос. Шатл, в отличие от бурана, летал с людьми и мы не знаем причин. И не имея информации, я не собираюсь фантизировать как вы, и тем более озвучивать свои фантазии как убеждения.

Посадка утюга с крыльями — не такая сложная задача

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

Проблема автопилота НЕ РЕШЕНА ДО СИХ ПОР, ололо

Вы идеалист? Или инфантил-максималист? Стопроцентной надежности не бывает, она недостижима, как число пи.

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

Ваши представления по детски ярки, но безнадежно далеки от реальных производств.

Я прекрасно знаю задачи — я это контроллеры писал.

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

Я не уверен, что вы правильно задаете вопрос. Шатл, в отличие от бурана, летал с людьми и мы не знаем причин. И не имея информации, я не собираюсь фантизировать как вы, и тем более озвучивать свои фантазии как убеждения

Я тоже могу сесть на жопу, закрыть глаза и уши, и орать «у меня нет информации, я не собираюсь фантазировать, как вы». Как минимум STS-3 спускался на автопилоте, который вообще-то был уже на STS-2, а это, на секундочку, 1981-1982 год против бурана 1988 — порядка 6-7 лет отставания совком.

Посадка утюга с крыльями — не такая сложная задача

Я понимаю, что вы пытаетесь изобразить пренебрежение

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

в 80-х даже в СССР сущестовавали полноценные автопилоты - не уровня «круиз-контроль», как в современных пассжирских самолетах, а полноценный автомат

Какие еще, кроме бурана?

Вы идеалист? Или инфантил-максималист? Стопроцентной надежности не бывает, она недостижима, как число пи

Самолеты ломаются постоянно, но по всем стандартам одиночная поломка не должна приводить к крушению. Вплоть до того, что самолет с незначительной поломкой может эксплуатироваться годами. Однако, автопилот не способен обрабатывать почти никакие отказы — потому при отказах автопилот выключается и управление передается человеку. Не говоря уже о намного более сложной реакции на окружающую обстановку. А это значит, что ни один пассажирский самолет в обозримом будущем не разрешат выпустить в полет без пилота за штурвалом. Именно пилота, а не оператора ЭВМ, хотя в России нынче за сало выдают лицензии даже тем, кто не умеет пилотировать.

Ваши представления по детски ярки, но безнадежно далеки от реальных производств

От каких? От советских забиваний болтов? В японии если заметят — сразу крест на карьере. Вплоть до того, что люди самоубиваются, потому что на квалифицированную работу после этого их никто не возьмет.

Я тоже могу сесть на жопу, закрыть глаза и уши, и орать «у меня нет информации, я не собираюсь фантазировать, как вы». Как минимум STS-3 спускался на автопилоте, который вообще-то был уже на STS-2, а это, на секундочку, 1981-1982 год против бурана 1988 — порядка 6-7 лет отставания совком.

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

Что за бессвязный поток информации? Что сказать то хотите и что этим продемонстрировать?

Какие еще, кроме бурана?

Зачем вам «еще»? Вы сомневались в том, что в 80-е уже вовсю существовали цели и применения для компьютеров. Сомневались в сущестовании автопилотов в то время. Ну получите бураны и шаттлы, распишитесь.

Самолеты ломаются постоянно, но по всем стандартам одиночная поломка не должна приводить к крушению. Вплоть до того, что самолет с незначительной поломкой может эксплуатироваться годами. Однако, автопилот не способен обрабатывать почти никакие отказы — потому при отказах автопилот выключается и управление передается человеку. Не говоря уже о намного более сложной реакции на окружающую обстановку. А это значит, что ни один пассажирский самолет в обозримом будущем не разрешат выпустить в полет без пилота за штурвалом. Именно пилота, а не оператора ЭВМ, хотя в России нынче за сало выдают лицензии даже тем, кто не умеет пилотировать

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

От каких?

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

Зачем вам «еще»? Вы сомневались в том, что в 80-е уже вовсю существовали цели и применения для компьютеров. Сомневались в сущестовании автопилотов в то время. Ну получите бураны и шаттлы, распишитесь

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

https://www.youtube.com/watch?v=241-5DZyons — Showing Some Secrets Of The Magnificent Airbus 350

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

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

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

У нас поезд метро без машиниста не разрешают выпустить. Хорошо, хоть лифты разрешили. Дело не в сложности задачи, а в том, что в любой ситуации, где потенциально могут быть человеческие жертвы, автоматизация фактически запрещена. В случае аварии должен быть виноватый (с точки зрения УК).

У нас поезд метро без машиниста не разрешают выпустить. Хорошо, хоть лифты разрешили

Мошинист — то другое, то именно оператор ЭВМ, иногда механик, но это не пилот.

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

Ну а как же Tesla?

Да. Но в микросервисах тормоза безальтернативно.

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

Где-то тихо в углу засмеялся Цукерберг.

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

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

Я ничего не понял, а она *должна* выполнять при отказе сразу всей критической инфраструктуры? В чем наезд? Любая система уйдёт в отказ, если питание везде вырубить.

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

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

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

Кто-то сделал херовый фронт, и что? А кто-то сделал херовый забор. Наверное это значит все пилы, молотки и гвозди - говно, надо лить из бетона.

«Нормально определить зоны ответственности» — это что-то вроде «писать без багов»

Это что-то из solid.

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

Когда пилят ооп монолит, там конечно, никто ни на что не такое не тратит время и не дрочатся со своей иерархией классов, интерфейсами, слоями и прочим говном. Тоже странная претензия.

Ладно, но тогда ваши сервисы независимы — они не составляют систему.

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

Ну а как же Tesla?

Кто за рулём сидит, тот и отвечать будет. В инструкции к тесле отмазка есть.

Вот мне ничего не мешает спасить код/сделать импорт и сделать вызов функции/метода вместо сетевого вызова.

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

Тогда асинхронность потеряется.

Что мешает на ноде то, что было микросервисом засунуть в worker thread и сделать его через await?

Где-то тихо в углу засмеялся Цукерберг.

Ну, смех смехом, а вкотнактник в свои лучшие годы вполне себе на пхп работал

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

Я ничего не понял, а она *должна* выполнять при отказе сразу всей критической инфраструктуры? В чем наезд? Любая система уйдёт в отказ, если питание везде вырубить

Опять же, это к тебе был вопрос: каким образом тут помогает микросервис?

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

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

«Нормально определить зоны ответственности» — это что-то вроде «писать без багов»

Это что-то из solid

Того солида, адепты которого выдают самый блевотный нечитаемый код? Нет, спасибо. Когда я искал работу, у меня SOLID и TDD были в игнор-листе, потому что там адепты такой лапшы налепят, что микросервисы, действительно, курят в сторонке.

Когда пилят ооп монолит, там конечно, никто ни на что не такое не тратит время и не дрочатся со своей иерархией классов, интерфейсами, слоями и прочим говном. Тоже странная претензия

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

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

На бумажке распечатать, LOL.

Что мешает на ноде то, что было микросервисом засунуть в worker thread и сделать его через await?

Например, блокирующий системный вызов в микросервисе.

И вообще, я немножко про другое. В пределе, понятно, что любой алгоритм можно реализовать как угодно.

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

То есть, если я пишу на Эрланге (или Эликсире), то микросервисная архитектура достаётся бесплатно, но появляются ограничения языка программирования. Если же писать на Си++, то микросервисная архитектура настолько отличается от многопоточной, что для перехода от одной к другой переписывать придётся столько же сколько от модульно-монолитной к микросервисной.

Что мешает на ноде то, что было микросервисом засунуть в worker thread и сделать его через await?

Тот факт, что код с воркерами на ноде, как правило, представляет собой нечитаемую неотлаживаемую дристню. В JS крайне примитивные механизмы многозадачности, какому-нибудь Erlang-у, Go, или даже моему PSO они в подметки не годятся.

То есть, если я пишу на Эрланге (или Эликсире), то микросервисная архитектура достаётся бесплатно, но появляются ограничения языка программирования.

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

Если же писать на Си++, то микросервисная архитектура настолько отличается от многопоточной, что для перехода от одной к другой переписывать придётся столько же сколько от модульно-монолитной к микросервисной

Скорее проблема в том, что многопоточность в C/C++ — это просто цирк, стояние на двух лодках сразу. Обычно оно скатывается в полностью независимые задачи, которые изредка сливаются семафороми в один поток. При таком огромном грузе наследования особо не потанцуешь. Я вот как раз щас пишу асинхронщину на C++ — это больно, очень больно, очень куцый язык, смехотворная «расширяемость», она может казаться расширяемостью только на фоне Си.

На самом деле на Эрланге ты платишь цену микросервисов всегда в виде усложнения базовых примитивов и таким образом алгоритмов в целом

Так я и пишу «ограничения языка программирования».

Но это все равно сетевое взаимодействие, то есть, взаимодействие асинхронных задач.

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

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

Скорее проблема в том, что многопоточность в C/C++ — это просто цирк, стояние на двух лодках сразу.

А есть альтернатива? Чтобы скорость работы приложения была при этом не меньше, чем на Си++?

На самом деле на Эрланге ты платишь цену микросервисов всегда в виде усложнения базовых примитивов и таким образом алгоритмов в целом

Так я и пишу «ограничения языка программирования»

Да, не заметил, устал, извиняюсь.

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

Бесплатно после фиксированного начального взноса.

Скорее проблема в том, что многопоточность в C/C++ — это просто цирк, стояние на двух лодках сразу.

А есть альтернатива? Чтобы скорость работы приложения была при этом не меньше, чем на Си++?

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

Бесплатно после фиксированного начального взноса.

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

Напоминаю, что прежде всего многопоточные приложения на C++ работают медленнее, чем однопоточные на C++.

Четырёхпоточное на четырёхядерном процессоре заметно быстрее сделает обработку массива чем однопоточное на нём же.

У нас была необходимость НЕ ДЕЛАТЬ монолит. Триста разработчиков, работающие над одним монолитным проектом, требуют намного больше контроля со стороны управления и намного большей квалификации этих самых разработчиков.

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

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

Я про то, что либо платформа (язык программирования) должна позволять на уровне ключей компиляции или автоматизируемых преобразований кода

Да как бы можно и такое скостылить.

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

чоэта?

В JS крайне примитивные механизмы многозадачности

Честно скажу, не делал многопоточку.

Для этого придумали модули.

и бесконечный рефакторинг

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

У меня сейчас под две сотни приложений. Из них «чистых» микросервисов десяток-полтора. Свести это все в один монолит означает, что в отсутствие контрактов у нас каждый ПР с изменением интерфейсов будет ревьюиться десятью разными командами.

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

жсон-схемы для api

синхронные вызовы

может еще и блокирующие? ;)

консистентные образы системы при ошибках

да, это реально плюс

и бесконечный рефакторинг

Так между микросервисами то же самое. Точнее, там это многократно сложнее, поэтому там где между модулями будет рефакторинг, в микросервисах просто скажут оставить как есть.

Свести это все в один монолит означает, что в отсутствие контрактов у нас каждый ПР с изменением интерфейсов будет ревьюиться десятью разными командами.

А изменение интерфейса микросервиса меньшим количеством команд?

жсон-схемы для api

Хоть один язык поддерживает это в своей системе типов? Или если имена полей совпали, значит это правильные данные?

может еще и блокирующие? ;)

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

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

Ну так ключевое слово «работал».

Опять же, это к тебе был вопрос: каким образом тут помогает микросервис?

А он должен помогать от взрыва всех ДС? Не много ли хотите?

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

Да ну не.

Того солида, адепты которого выдают самый блевотный нечитаемый код?

Ну если не упарываться, то чем плох солид?

На бумажке распечатать, LOL.

В конечном итоге да, но предже, чем это куда-то попадёт, там пара не простых выборок.

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

А ты не подумал, что эффект может быть положительным? Говнокод на асме будет работать медленнее, чем hello world на вылизанной либе C/C++/Rust/Pascal.

Четырёхпоточное на четырёхядерном процессоре заметно быстрее сделает обработку массива чем однопоточное на нём же

Или нет. Зависит от рук и алгоритмов. Та же история, как с мамкиными оптимизаторами на асме, которые не удосуживаются пробенчить свои «оптимизации».

У нас была необходимость НЕ ДЕЛАТЬ монолит. Триста разработчиков, работающие над одним монолитным проектом, требуют намного больше контроля со стороны управления и намного большей квалификации этих самых разработчиков

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

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

чоэта?

Ну я уже частично ответил — очень примитивные базовые инструменты. Грубо говоря, ты пишешь на сишке, с разделяемой памятью на голых интах, с мутексами, только эта сишка имеет синтаксис JS. Выстрелить себе в ногу суперпросто, колбэки заплетаются в лапшу, которая похуже, чем было даже на древних колбэках (до промисов), потому что эти колбэки хотя бы оперировали высокоуровневыми структурами данных. То есть, оно сделано именно с уклоном в производительность, потому что ты же воркеры делаешь для повышения производительности, и по итогу получается эдакий asm.js, только еще и с многопоточностью.

Для этого придумали модули.

и бесконечный рефакторинг

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

У меня сейчас под две сотни приложений. Из них «чистых» микросервисов десяток-полтора. Свести это все в один монолит означает, что в отсутствие контрактов у нас каждый ПР с изменением интерфейсов будет ревьюиться десятью разными командами

Во-первых, монолит не означает отсутствие контрактов. Во-вторых, что это за «грязные» микросервисы, которые 95% системы?

жсон-схемы для api

М'сье знает толк в извращениях.

Ну так ключевое слово «работал»

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

А он должен помогать от взрыва всех ДС? Не много ли хотите?

Я о том, что твои претензии к монолиту здесь пусты. Отвалились все БД — умер монолит да. И микросервис тоже.

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

Да ну не

Да ну да — посмотри, какие системы делались командами 5-10-20 человек, и которые теперь делаются командами 100-500 человек. Тупо по человекочасам получается на один-два порядка больше. Это как в многопоточных приложениях: вместо одного потока запускаешь задачу в 8 потоков, но в итоге она выполняется всего-лишь в 2 раза быстрее.

Ну если не упарываться, то чем плох солид?

SOLID чисто теоретически говорит про абстрактное «давайте жить дружно». Черт кроется в применении. Все знают, что нужна модульность — но никто не умеет ее делать. Чем больше ты кричишь про «я умею писать правильно» — тем больше шанс, что ты ничерта не умеешь, а только умеешь кричать. Потому что если ты умеешь, то будешь хвастаться результатом, а не «я бы мог, ой как много я бы мог». Смотришь на его код — а там мелко-мелко нарезанные однострочные, мельче, и еще мельче, каждый шаг алгоритма нужно наблюдать в новом файле, потому что dependency inversion и горы интерфейсов с безликими именами, или, еще хуже, наследованием. И как бы имена тут лучше не придумаешь инетрфейсам, потому что всякие FactoryCreator и JobDoerRunner возникают из-за того, что все осмысленные имена уже давно заняты и перегружены, что наблюдаемая сложность вспомогательных структур во много раз превышает сложность выполняемых алгоритмов. И самое страшное то, что автор сего творения тебе пояснит, что ты ничего не понимаешь в кодинге, что вот здесь солид, здесь I, здесь O — ты хоть знаешь, как они расшифровываются?

В конечном итоге да, но предже, чем это куда-то попадёт, там пара не простых выборок

«Голбат, я выбираю тебя!».

У нас был рост со 100 человек до 1500 за два года. Некоторые монолитные проекты в итоге разобрали на отдельные сервисы, некоторые остались монолитами, а некоторые изначально делались в виде микросервисов.

Во-вторых, что это за «грязные» микросервисы, которые 95% системы?

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

У нас был рост со 100 человек до 1500 за два года. Некоторые монолитные проекты в итоге разобрали на отдельные сервисы, некоторые остались монолитами, а некоторые изначально делались в виде микросервисов

Давай посмотрим правде в глаза: 1500 человек — это весь кор-тим гугла, этим можно сделать второй гугл в его современном виде. Team 1 близарда в 2020 году — 200 человек. С дизайнерами и прочей мишурой. При этом уровень SC II в ближайшие 10-20 лет никто не сможет повторить — можете скринить. Даже несмотря на доступность готовых pathfinder-ов на рынке. Слишком глубоко нужно проинтегрировать систему, а на этом фоне спрос на продвинутые игры падает, потому награда за успешное выполнение этой задачи намного ниже. Вместо этого детишкам подавай кинцо и песочницы, которые по совместительству прекрасно микросервисятся, то есть, можно посадить тысячу индусов рисовать текстуры усов или клепать вразнобой сто примитивных геймплеев на 10 минут каждый.

Во-вторых, что это за «грязные» микросервисы, которые 95% системы?

Это те, которые выполняют не одну функцию, а две-три

«Какую книгу Толстого вы прочитали? — А у него что, их было две?».

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

Кошмар, как же вы беспощадно перегружаете свои сервисы.

А ты не подумал, что эффект может быть положительным? Говнокод на асме будет работать медленнее, чем hello world на вылизанной либе C/C++/Rust/Pascal.

Говнокод на C/C++/Rust/Pascal будет работать медленнее, чем вылизанный код на эрланг. И?

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

Понятно, что существуют краевые случаи, где обработка массива совсем тривиальна и всё упирается в скорость памяти. И криворукие, которые делают выполнение потоков по очереди. Но в общем случае многопоточная обработка скорость увеличивает.

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

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

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

А деваться некуда. Мало кто может позволить платить как Гугл или Близард. А если у тебя вместо 50 гениев есть 500 средних программистов, они не смогут написать то, что могут написать 50 гениев. Потому что для написания единого проекта нужно взаимодействие каждого с каждым, которое требует времени квадратично от количества человек в команде. И где-то за второй сотней человек остаётся только общение без работы.

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

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

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

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

В Джуно, есличо, было около 80 разработчиков+qa+менеджмента.

Вы в бесконечном цикле хотите выполнять 5тыс потоков в которых ничего намекающего на sleep и т.п. ?

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

Это не только в машинном обучении select * from tablename можно встретить. :)

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

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

У нас поезд метро без машиниста не разрешают выпустить.

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

Кто за рулём сидит, тот и отвечать будет. В инструкции к тесле отмазка есть.

Хорошо, а как же форд с глюком руля?

Что приводит к необходимости ещё и контролировать каждым микросервисом все входящие данные на корректность.

Два, нет четыре чая этому господину! И добавить сюда обработку ответа вида «дядя ты мне дал что-то не то», в пинг-понг можно играть долго.

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

Я бы начал с того, что в габеновой Вольве 400 человек ВСЕГО. Я не понимаю манагеров, которые делают рост ради роста. Ну типа да, до 2008 в штатах можно было получить инвестиции под снижающийся процент, вырости, легко отдать долги с выросшего дохода, взять в кредит еще — таким образом удается расти с умопомрачающей скоростью, но это же и недостаток: если компания не растет, то фокус перестает удаваться. А расти бесконечно нельзя. То же самое случилось с пузырем ипотек. Тем временем, Вольва — самая доходная или одна из самых доходных фирм в индустрии так-то.

Близзы половину отдают на аутсорс, и наши сервисы работают намного стабильнее балтнета

Activision Blizzard сам никогда не будет таким, как Blizzard. Blizzard никогда не отличался оригинальностью своих изделий — он отличался качеством их проработки. У них был свой формат игровых данных MPQ, свой язык скриптов, в конце-концов свой движок и свои средства разработки игр на нем, которые отдавались на растерзание всем, кто купил игру. То есть, что-то вроде Unreal Engine. Разве что звук у них был чужой (Miles 2D, EAX, Dolby, FMOD).

Это потом выяснилось, что с 2008 года игровая индустрия в частности и экономика в целом переходит в период стагнации, нужны новые ниши, чтобы отличаться от конкурентов, а новым нишам не нужны качественные реализации — это унылые «tap to win» или более сложные «swipe to win», и теперь на коне idle дрочильни вроде hero wars, смысл которого заключается в предельно примитивном и растянутом игровом процессе.

С тех пор уже Activision Blizzard начал больше и больше аутсорсить, а также доить верных фанатов. Последний Warcraft Reforged — это чистый аутсорс крайне низкого качества, который окончательно запятнал репутацию. Намного веселее то, что происходило еще раньше в фоне, во внутренностях игр и серверов. Как известно, Battle.net одновременно поддерживал целый зоопарк продуктов, от старенькой диаблы и брудвора до новых SC II и WoW. В диабле даже не было аутентификации — подразумевалось, что если ты смог подключиться к серверу через проприетарный протокол, то ты уже купил игру. Это как раз требует хотя бы модульности, чтобы каждый клиент общался со своей мордой.

Под соусом распространения интернетов менеджмент сказал «давай по-новой, Миша, всё не так». статичные архивы MPQ были заменены на CASC с дистрибуцией TACT, старые игры были перешиты на новый Battle.net (последняя версия Broow War выпущена в 2020), и в конце-концов дистрибуция перешла с бинарного протокола на HTTP — попутно создавая эпичные баги, вроде 10-минутного зависания при запуске, который решается блокировкой IP адресов. Это баг был актуален примерно полгода-год. А еще эффективное масштабирование мощностей серверов позволило получать регулярные отвалы игровых сессий.

Очевидно, что Activision Blizzard больше и больше идет к сторону популярных технологий и взаимозаменяемых разработчиков, но результат один — снижение качества, повышение числа отказов. И именно на примере Blizzard можно увидеть, как смена подходов влияет на результат, а не «у нас всё всегда работало» — это плохой пример, хотя бы потому, что ваши сервисы не поддерживали 5 клиентов, выпущенных в период 12 лет и не переходили на поддержку ограниченным числом ресурсов.