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

Я вообще не рассматриваю причины того, почему некий обобщенный человек идет в программисты - это и так на поверхности

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

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

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

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

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

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

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

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

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

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

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

Значит у вас хреновый стейджинг или хреновые QA

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

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

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

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

Но мне кажется в таких условиях причина микросервисов в том, что хочется структурировать проект, а не иметь огромную монолитную портянку

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

иногда нет (когда на выходе будет такое говно, что его никто не купит или переделка будет стоить слишком дорого).
Второй случай, кстати - эталонный провал стартапа

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

Всё зависит от того сколько бабок вложили и насколько компетентное руководство собралось работать над проектом. Обычно и бабок мало и руководство надо в дворники переводить. Кадры решают всё

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

Спор идет по поводу того, какие это одни случаи, и какие — другие.

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

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

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

Гарантии тебе только бог даст. А вот на количество ошибок да, влияние прямое

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

Классический пример — иерархии наследования.

Это не перфекционизм. Это паттерн головного мозга

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

Широко распространяться в штатах ПК начали в середине 80-х, а я писал про начало, когда уже давно были и 4-битки, и 8-битки, но массовыми стали только 16-битки. Мой основной аргументы был о том, что сначала создавались технологии, а потом находились применения. Советский союз откровенно отставал от запада, у него не было технологий даже когда для них уже нашли применения.

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

От каких? Ты хочешь сказать, что в тойоте сидят говнокодеры?

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

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

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

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

Я могу. Я 8 лет сидел на одном проекте с околоначального этапа развития до отправки на пенсию по неактуальности. И к финансовым показателям доступ имел. У меня очень редкий для индустрии опыт, за который я заплатил временем и молодостью, но я совершенно бездарно его реализую.

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

На самом деле не совсем финансовый аспект, а то, что я называю «маркетинговый». Говоря по-русски «бросить пыль в глаза». Он может превращаться в прибыль, но не всегда для того, кто эту прибыль хотел получить. Очень часто заказчик покупает уверенность в надежном вложении денег, особенно это актуально для американского венчурного инвестора — но по статистике 95% таких вложений банкротятся в течении 5 лет. «Почему же они вкладывают туда деньги?» — спросит дотошный читатель. За тем же, зачем несли деньги в МММ — стартапы силиконовой долины в большинстве своем не преследуют никакой технической цели, они служат исключительно оправданием для финансового пузыря, который в чистом виде запрещен законом, но если ты занимаешься видимостью деятельности в реальном секторе — к тебе никто претензий не предъявит.

Широко распространяться в штатах ПК

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

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

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

От каких? Ты хочешь сказать, что в тойоте сидят говнокодеры?

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

Классический пример — иерархии наследования.

Это не перфекционизм. Это паттерн головного мозга

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

Ты забываешь, чтог хороший софт = простой софт.

Как это забываю, если только об этом талдычу чуть ли в каждом топике, касающимся качества софта )

А для простого софта миллиарды долларов не нужны

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

Я могу. Я 8 лет сидел на одном проекте с околоначального этапа развития до отправки на пенсию по неактуальности. И к финансовым показателям доступ имел. У меня очень редкий для индустрии опыт, за который я заплатил временем и молодостью, но я совершенно бездарно его реализую.

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

не совсем финансовый аспект, а то, что я называю «маркетинговый».

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

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

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

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

Я чот не пойму, ты имеешь отношение к разработке софта, или же просто слышал про оную? Софтина, написанная на жаве, работает на порядки надежнее, чем софтина, написанная на сишке за то же время. Просто потому, что язык Си никогда не проектировался и провоцирует на написание ошибок, что никак не оправдано близостью к железу, в то время, как Java защищает от уже написанных ошибок, хотя байткод JVM не сильно выше уровнем, чем ассемблер:

https://en.wikipedia.org/wiki/List_of_Java_bytecode_instructions

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

Не ты один:
https://twitter.com/YossiKreinin/status/1519760528272408577

Programming is tetris, you win by regularizing complexity away. The tetris blocks are coming at you too fast if workarounds are piling up instead of becoming unneeded & deleted. Blocks filling up the entire screen so you need a fresh one is when you lose and rewrite the program
^
-- But complexity is conserved. So the blocks don't disappear but instead reappear on another player's screen
    ^  
    -- This is rich kid's tetris played by fast-growing companies - when you run out of screen space, just ask dad to buy a bigger screen (hire more people)

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

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

И я прежде всего апеллирую к тому, что в 99% случаев не существует технического оправдания для применения микросервисной архитектуры, хотя ты сам намекал на техническую составляющую:

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

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

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

К тому же, до развития компов просто не было методологии для разработки ПО

Методологии может и не было, а разработки были ) Знание накапливалось интегрально, а не из-за того, что создали более навороченные компы.

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

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

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

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

И я прежде всего апеллирую к тому, что в 99% случаев не существует технического оправдания для применения микросервисной архитектуры,

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

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

Какая нафик полноценные автопилоты? Полноценный автопилот — это Airbus 330, который 90-е годы, а у боинга еще позже.

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

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

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

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

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

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

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

Вчера впервые попробовал питон: написал 50 строк кода - беру данные из постгрес, делаю запрос к своему же api на другом сервере через requests, проверяю результат и кладу в постгрес обратно (в другую базу).

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

Что я пробовал: обернул все в функцию, запустил через while True:, запустил скрипт - все работает. Запустил это через xargs/parallel - сдох процессор (epyc 7351P), вытащил только около 2к копий скрипта.

Взял multiprocessing, но он делает то же самое, что и запуск через xargs, результаты не изменились.

Ок, взял pypy, нагрузка на cpu упала примерно в 5-7 раз, но т.к. multiprocessing плодит копии процессов - кончилась память, сожрало где то 120гб рам (там одна копия pypy мегабайт 150-200 берет) и умерло от оом киллера.

continuous-threading пробовал, разницы не заметил (правда на pypy еще не тестил).

Потестил то же самое на bash+curl+psql(через pgbouncer)+xargs или php8 - оно и то меньше ресурсов тратит.

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

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

С половиной проблем. Нет дикого оверхеда на HTTP/JSON.

Зделай на tcp/udp передачу, как некоторые, кто тебе мешает.

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

Ты руками всё собрался обслуживать, бекабить, ага?

Но с другой тебе нужно гораздо больше народу чтоб следить за всем этим

Больше, но не кратно.

Значит у вас хреновый стейджинг или хреновые QA

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

Да, монолит. Да, приложения разные. Как раз монолит является единственным способом координации — потому все микросервисы опираются на монолитные БД для координации.

А распределенный систем не бывает как класса?

Почему на единственную? Поставь две таких железяки, три.

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

По итогу на микросервисах всегда стоит

Или не стоит. Кто тебя обязывает?

Хотя, конечно же часто есть точка централизации уровнем ниже в виде какой-нибудь БД.

Если она нужна и нельзя сделать по-другому.

Ну да, и пусть система не работает

Ну если у тебя система или строго централизованна или работает.

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

Не микросервисы, а то, что ты под ними подразумиваешь. Не путай. Микросервисы - это просто инструмент, а не реализация.

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

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

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

Так если acid не нужен, то и централизованность не нужна. И монолит не нужен. Когда-то там будет консистентность и ладно. Значит дробить можно на куски. Проблемы?

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

Выяснить это не такая уж проблема, как уже говорилось выше.

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

Как и что-то там внутри монолита.

Гейт отвечает подтверждением после двух подтверждений от конечных БД - вот и всё решение.

БД или сеть легли. Всё, отказываешься от обслуживания?

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

Нет «какой-то логической ошибки». В данном случае есть контракт, т.е. конкретные требования к запросу при которых он *должен* быть принят. Таким образом сервис для приёма платежей можно сделать очень маленький, быстрый, надёжный, нужные данные реплицировать на него, его легко будет дублировать, вместо того, чтобы дублировать вообще всё.
Да, не всё так можно, где-то есть очень жирный acid. Но что-то можно очень даже.

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

Но как? Настолько отсутствует документация на алгоритмы? И почему затестить не выйдет? Хоть платежи хоть антифрод должны в ответ на какие-то входящие данные выполнять какие-то действия. Это всё можно проверить.

И как вообще можно хоть что-то менять в системе (даже костылями), если нет возможности проверить, что после костыля она продолжает корректно работать? Если система стала чёрным ящиком, определяемым реализацией, то её внутри вообще менять нельзя (кроме эквивалентных преобразований кода).

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

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

А сеньора найти это кхм

Вот сеньор и может выбирать: либо больше денег либо больше результата, которым можно гордиться.

Ну вот президент Пу — он себя продает?

Отставить провокацию!

Теперь хочется запустить это скажем одновременно в 5 тысяч бесконечных потоков

Чтобы что? Быстрее работало? Ахахахахахаха. Сделай по числу ядер + 1.

Вчера впервые попробовал питон: написал 50 строк кода - беру данные из постгрес, делаю запрос к своему же api на другом сервере через requests, проверяю результат и кладу в постгрес обратно (в другую базу).

Если тебе надо быстро быстро делать insert по одному в pg, то ничего не получится, всё упрётся в бд. Если у тебя операция не в одну транзакцию, складывать insert'ы в кучу и делать batch insert. Всё. Быстрее только кеши или записать всё в файл и сделать экспорт, если у тебя одноразовая акция.

БД или сеть легли. Всё, отказываешься от обслуживания?

HTTP 503

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

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

Или сервис для приёма запросов должен иметь своё надёжное хранилище

Ну да, так оно и происходит.

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

А распределенный систем не бывает как класса?

Ну а я о чем? Распределенные монолиты. Гетерогенную распределенную систему весьма тяжело сделать, а вот монолитную распределенную — намного проще.

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

Производительность не нужна 99% заказчиков. Точка. Можно говорить про какой-то там 1%, которому это важно, «давайте не будем забывать про идеалы», и всё такое, но по факту необходимость иметь десять машин происходит из-за того, что у нас данные обрабатываются питоном, который в 100 раз медленнее C/C++ и в 30 раз медленнее жавы — на любом из этих ЯП система умещалась бы в одну машину с большим запасом. Не говоря уже о том, что часто большая часть ресурсов тратится тупо на сериализацию-десериализацию — туго серят они.

Я сейчас посмотрел цену на сервак, 64 ядра EPYC 7252, 2 ТБ ECC оперативы, 32 ТБ дисков RAID 1 — 3 млн рублей. Условно — годовая ЗП среднего кодера в СНГ.

Хотя, конечно же часто есть точка централизации уровнем ниже в виде какой-нибудь БД.

Если она нужна и нельзя сделать по-другому

Неизбежно что-то с чем-то нужно координировать, будь это CRM, интернет-магазин овощей, или видеохостинг. Точек координации может быть больше одной, но они будут. Хотя бы в виде etcd.

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

Не микросервисы, а то, что ты под ними подразумиваешь. Не путай. Микросервисы - это просто инструмент, а не реализация

Грубо говоря, я имею в виду 95% реализаций микросервисного карго культа. Они похожи друг на друга, как близнецы, потому что в этом и заключается суть карго культа — бездумно копировать всё подряд.

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

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

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

Так если acid не нужен, то и централизованность не нужна. И монолит не нужен. Когда-то там будет консистентность и ладно. Значит дробить можно на куски. Проблемы?

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

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

Выяснить это не такая уж проблема, как уже говорилось выше.

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

Как и что-то там внутри монолита

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

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

БД или сеть легли. Всё, отказываешься от обслуживания?

Прямо все БД и все сети? Ну тогда прятаться в подземный бункер.

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

Это как у Луи Си Кей:

That’s like going to the movies, you pay for your ticket and they say ‘Get the fuck outta here, go home!’ …But I paid for the movie? ‘No, you paid for a ticket, motherfucker, you didn’t pay for a movie!’

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

Какая нафик полноценные автопилоты?

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

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

Давайте вы как минимум будете пытаться думать, когда читаете мой текст. И не придумывайте глупостей. Языки пишутся для своих задач и оптимальны для своих применений. Они не конкурируют в вакууме. Язык - это не больше чем инструмент. Если тойота решила что-то писать на голых сях - скорее всего у них были на это основания. Не пытайтесь противопоставлять один язык другому без знания задачи и всего остального. Хотя бы попробуйте представить, что вы не обычный лоровец, а чуть умнее.

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

Все есть и все развивается. Но далеко не все добирается до видимымых вам применений из экономических соображений и непрофессионализма.

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

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

Зделай на tcp/udp передачу, как некоторые, кто тебе мешает.

Всё равно тормоза. А разделяемая память для микросервисов моветон.

Всё равно тормоза

Так если с ерланга растаскивать выполнение по нескольким серверам тоже самое будет.

Распределенные монолиты.

В вакууме.

Производительность не нужна 99% заказчиков.

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

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

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

А я вижу интернет-магазины, на которых нельзя сделать заказ

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

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

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

Почему-то ты рассматриваешь самую удобную ситуацию.

Давай, рассмотри неудобную еще раз.

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

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

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

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

Прямо все БД и все сети? Ну тогда прятаться в подземный бункер.

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

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

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

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

Да. Но в микросервисах тормоза безальтернативно. В эрланге я могу крутить сервисы внутри одной ноды, в ракете я могу использовать разделяемую память (да, тогда переход от одного узла к нескольким не так тривиален). Даже в SQL клиент-сервер предлагает на выбор разделяемую память и TCP.

Все так

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

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

Ну и контракты, родненькие, в качестве костыля :)

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

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