а нужны ли мне эти ваши docker-контейнеры?

Херак-херак и готово?

У меня бывало. Просто «давайте сделаем Х» - херак-херак и Х готов. Безо всякого аджайла, что характерно. Главное, людей, которые «херак-херак», не отвлекать.

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

google://distributed tracing

Их надо одновременно запустить на одном ноутбуке,

Ну и колхоз там у вас.

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

Так там тоже ничего не хранится. Сообщение пришло - сообщение ушло. Нигде не остается внутри.

Микросервисы — это противоположность БД

Ну да автобус - противоположность озеру. А монолит - это база данных? В чем разница то?

спросить у сервиса авторизации

Сервера авторизации.

А в чем разница?

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

Repeatable read с фантомами - это работа Комитета ANSI SQL. Я конечно не специалист, но вероятно это из-за того, что межделмаша база блокировочная и видимо трудновато ему будет эти строки скрыть. Вообще всю эту проблему создали в бородатых годах и сегодня это странно выглядит: в моем понимании никаких уровней не надо, должен быть только S, мне кажется не стоит оно того чтобы с пониженным уровнями возиться. Если в 90х межделмашевской бд которую они продали кастомеру за миллион становилась от этого однопользовательской - то как это меня касается в 2022 на версионнике? Короче нагородили говна в своё время. Люди в 99% в пределах одной бд не могут корректное и безопасное поведение реализовать, это думать надо. А тут еще пониженные уровни везде по-дефолту. Тупость. Причем всё идет по пути ухудшения. То есть люди которые даже этот problem space в простейшей системе не хендлят и не замечают, они еще предлагают распилить всё. То есть в пределах одной БД он не может потому что дурак, а когда распилит «на сервисы» - то у него всё правильно работать будет («зачем X знать об Y!»).

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

Про оракл - кстати единственный уровень, который стандартом определен нормально - это как раз S, т.к. он определен не через аномалии, а как сериализуемое исполнение.

На AWS был наезда по поводу охреневших цен на on-demand сервера.

А не надо использовать AWS для on-demand серверов. Он не про это.

С докером проблемы будут просто решать другие «другие люди»

Те же самые. Даже если их переназвали девопсами или sre, это всё равно физически те же самые админы.

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

Расскажите как. Примем, что у вас используется мегасервисы: один сервис на одну виртуалку. Таких виртуалок у вас несколько десятков в тройке-пятёрке ЦОДов. Как за нагрузкой следить будем, как узнаем отчего что-то заткнулось и не отвечает?

Уточняющий вопрос: откуда вышестоящий сервис узнает, что нижестоящий сервис упал?

По отсутствию ожидаемого ответа.

Следующий уточняющий вопрос — откуда нижестоящий сервис узнает, что вышестоящий

Ниоткуда. Не его ума дело.

У тебя какая конечная задача — отчитаться про «сервис авторизации стало проще понять» или же сделать работоспособную систему в целом?

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

Так там тоже ничего не хранится. Сообщение пришло - сообщение ушло. Нигде не остается внутри

https://stackoverflow.com/questions/48816530/how-does-rabbitmq-decide-when-it...

Ну да автобус - противоположность озеру. А монолит - это база данных? В чем разница то?

Противоположность потому, что не имеют состояния.

спросить у сервиса авторизации
Сервера авторизации

А в чем разница?

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

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

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

https://www.youtube.com/watch?v=5ZjhNTM8XU8&t=23s00s

Если в 90х межделмашевской бд которую они продали кастомеру за миллион становилась от этого однопользовательской - то как это меня касается в 2022 на версионнике?

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

Причем всё идет по пути ухудшения. То есть люди которые даже этот problem space в простейшей системе не хендлят и не замечают, они еще предлагают распилить всё

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

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

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

Про оракл - кстати единственный уровень, который стандартом определен нормально - это как раз S, т.к. он определен не через аномалии, а как сериализуемое исполнение

Ну да: «если всё работает хорошо, то это у вас serializable».

А не надо использовать AWS для on-demand серверов. Он не про это

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

С докером проблемы будут просто решать другие «другие люди»

Те же самые. Даже если их переназвали девопсами или sre, это всё равно физически те же самые админы

Ну и что ты мне хочешь сказать? «Вам не понять?»

Примем, что у вас используется мегасервисы: один сервис на одну виртуалку. Таких виртуалок у вас несколько десятков в тройке-пятёрке ЦОДов. Как за нагрузкой следить будем, как узнаем отчего что-то заткнулось и не отвечает?

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

Уточняющий вопрос: откуда вышестоящий сервис узнает, что нижестоящий сервис упал?

По отсутствию ожидаемого ответа.

Следующий уточняющий вопрос — откуда нижестоящий сервис узнает, что вышестоящий

Ниоткуда. Не его ума дело

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

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

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

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

Я понимаю, почему вам нравится авторизация — потому что простая и ее легко выделить. Но давай применим этот подход к какому-нибудь высоконагруженному индексу, который должен быть высокосогласованным, чтобы не выдавать ошметки данных разных версий или удаленные файлы пользователю, который их только что и удалил (привет амазону, который только в 2020 эту проблему решил). В монолите всё просто — у тебя данные на коротком поводке, обновил индекс и пошел дальше. А что делать в микросервисах? Вся система же встанет по этому узкому месту, там ведь нагрузка намного выше, чем при авторизации.

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

Спасибо, капитан. Так в чем отличие сервиса от сервера?

при оптимистичной блокировке

Это еще как?

Спасибо, капитан. Так в чем отличие сервиса от сервера?

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

при оптимистичной блокировке

Это еще как?

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

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

Ты хотел сказать, конфликтов между транзакциями.

Да, посмотрел в википедии, optimistic concurrency control еще почему-то иногда называют optimistic locking, хотя никаких блокировок там не происходит.

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

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

Да, посмотрел в википедии, optimistic concurrency control еще почему-то иногда называют optimistic locking, хотя никаких блокировок там не происходит

compare-and-swap в цикле и блокировка выполняют сходную функцию, особенно если учесть, что часто блокировки через compare-and-swap и реализовываются.

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

Читал?... Акцентируется?... Мало ли кто и что пишет. Эти статьи манагеров, секретарш, и тимлидов рассказывают про 10% сложности, опуская 90% сложности как несущественные. А 90% сложности — это сеть и протоколы (в том числе TCP, который весьма спорный как транспорт), это всего-лишь координация, всего-лишь всё хранение состояния. «А теперь мы займемся самым важным — будем сравнивать строку на входе со строкой из БД, и выдавать успех, если строки совпадают».

Возвращаясь к треду про Jira и Git — это инструменты, которые вообще не должно быть заметно.

Да. И именно поэтому я всегда и везде говорю, что гит - говно.

И именно поэтому я всегда и везде говорю, что гит - говно

Нет я говорю.

А ничего, что многоверсионка = отсутствие сериализуемости? Даже при оптимистичной блокировке, если я делаю агрегирующее чтение,

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

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

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

Ну да: «если всё работает хорошо, то это у вас serializable».

все эти уровни как в городе пониженная передача или блокировка дифференциала. блокировочнику от S становилось плохо, да и какие тогда ресурсы были вычислительные в 90х? процессор, память, диск. но сегодня в 2022 мы кстати ту же строчку 200 байт при записи на приём пишем. нет уровня кроме S, народ инертный, не могут этого осознать пока.

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

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

Они нужны когда есть команда поддержки.

• Внешний nginx, который проксирует запросы куда надо

• certbot для внешнего nginx, чтобы получать сертификаты

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

Пока что я встречал только контенеры с nginx, куда запихнули и certbot. Уж не знаю, насколько это православно…

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

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

Смотря что они там делают.

При том, что для этого нужно переделвать приложение и приколачивать гвоздями к AWS

О чём вы?

Ну и что ты мне хочешь сказать? «Вам не понять?»

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

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

Да хотя бы тот же Zabbix.

и какая разница заббиксу собирать записи с мегасервиса или с микросервисов? Вообще не понимаю логику.

Чо делать?

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

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

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

В монолите всё просто — у тебя данные на коротком поводке, обновил индекс и пошел дальше.

Только в случае однопоточной синхронной обработки. Но тут со скоростью всё может быть грустненько.

docker-контейнеры?

Не нужно.

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

Т.е. если процесс обращается за данными к файловой системе это хорошо, а если за теми же данными ходит в redis — это ужасно и неприемлимо?

а нужны ли мне эти ваши docker-контейнеры?

Теорию плоской земли, когда начнете обсуждать? …

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

Ну елы-палы, всё надо разжевать...

«the message will never be deleted from the queue», далее, если не совсем понятно, что такое «never» — https://www.rabbitmq.com/persistence-conf.html

То есть, в прямом смысле «never», прямо как в ACID СУБД.

В целом, если ты один собрался все это поддерживать, то докеры тебе только навредят

Я лучше сказать бы не смог.

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

Почему «в совке», а не «в силиконовой долине»? И почему «мудак», а не «человек работает»?

При том, что для этого нужно переделвать приложение и приколачивать гвоздями к AWS

О чём вы?

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

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

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

и какая разница заббиксу собирать записи с мегасервиса или с микросервисов? Вообще не понимаю логику

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

А как вы эту проблему будете решать своим мегасервисом? Замените два микросервиса на вызовы двух функций, всё то же самое будет

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

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

Обсуждение? У вас архитектурные решения принимаются «пока горячий кофе»? Я не спорю, что это модно, но это как бы путь вникуда.

Только в случае однопоточной синхронной обработки. Но тут со скоростью всё может быть грустненько

В случае индексов вполне допустима однопоточность — так делает Redis, например. Многопоточноа у него сеть. Еще много чего нетребовательного к координации можно так же в потоки вынести.

Т.е. если процесс обращается за данными к файловой системе это хорошо, а если за теми же данными ходит в redis — это ужасно и неприемлимо?

Да, поскольку в последнем случае возникает лишнее звено. Я — фанат SQLite и BerkleyDB, которые встраиваются прямо в приложение-логику. Redis/memcached в большинстве случаев применяются как костыли для ЯП, не умеющих в быструю работу с сырыми данными в локальной БД. Например, это относится к PHP/Python/Ruby.

Теорию плоской земли, когда начнете обсуждать?

С какой точностью в последний раз ты измерял радиус кривизны Земли?

А ты о чем?

Я о том, что плотно подсев на инфраструктуру AWS, можно неплохо облегчить себе жизнь. Но при чём тут изменение приложения? От того, обновляет вам зону bind9 или route53 прикладному коду ни жарко, ни холодно.

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

Вы там выше писали:

нужно переделвать приложение

Что и как нужно переделывать?

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

Факт.

и про простоту реализации мегасервиса.

Вот, это единственная с чем я согласен. У микросервисов есть прикольные фишки, но надо дорасти ещё, чтобы от этого был толк. Но если уж дорос, делать нечего.

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

Если вы упёрлись в сетку, то либо у вас какая-то особая ситуация, либо вы накосячили с архитектурой. Второе вероятнее.

Обсуждение?

А чем мы тут занимаемся? На рояле играем?

В случае индексов вполне допустима однопоточность — так делает Redis, например.

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

Да, поскольку в последнем случае возникает лишнее звено

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

«the message will never be deleted from the queue», далее, если не совсем понятно, что такое «never» — https://www.rabbitmq.com/persistence-conf.html

Ты все так читаешь?

То есть, в прямом смысле «never», прямо как в ACID СУБД.

Я даже боюсь представить зачем нужна очередь из которой ничего не удаляется. Как ты это видишь? Ты каждый раз обращаешься к последнему (первому) элементу и все? Зачем такое надо?

Я о том, что плотно подсев на инфраструктуру AWS, можно неплохо облегчить себе жизнь. Но при чём тут изменение приложения? От того, обновляет вам зону bind9 или route53 прикладному коду ни жарко, ни холодно

Легионер писал о том, что он хотел бы сэкономить деньги на эксплуатации готовых сервисов переносом на облако/on-demand. То есть, у них уже имеется нагруженный сервис. Нужно понимать, что у амазона цены на сервера и трафик примерно в 10-100 раз выше себестоимости. То есть, практически вся цена — это сами «услуги», готовые службы вместо необходимости нанимать админов. Как быстро легионер выйдет на уровень затрат в тысячи долларов? Ну типа это 10-20 ТБ исходящего трафика. Мой домашний интернет за $5 позволяет за месяц передать такой объем данных — это 5% загрузки гигабитного линка.

нужно переделвать приложение

Что и как нужно переделывать?

Если я скажу «не надо ничего переделывать, оставим на EC2» — ты скажешь «зачем вам амазон?». У них же огромный жавовы монолит, который кучу данных хранит в памяти. DNS и аналитику может быть еще можно натянуть, БД — уже не факт, а остальные сервис идут лесом. «По-уму» оперативку нужно заменить ElastiCache, а сами сервисы на лямбду — это если «по уму».

У микросервисов есть прикольные фишки, но надо дорасти ещё, чтобы от этого был толк. Но если уж дорос, делать нечего

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

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

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

О чем это я? Если у вас команда состоит из сплошных рукожопов, то вам не поможет ничего. AWS лишит рукожопов части рубильников, но по итогу они всё равно ошибутся в командах конфигурации AWS и система ляжет — только поверх всего этого вы еще и будете переплачивать амазону.

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

Если вы упёрлись в сетку, то либо у вас какая-то особая ситуация, либо вы накосячили с архитектурой. Второе вероятнее

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

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

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

Обсуждение?

А чем мы тут занимаемся? На рояле играем?

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

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

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

В случае индексов вполне допустима однопоточность — так делает Redis, например.

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

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

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

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

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

По иронии судьбы, я этим и занимаюсь, но к нашей дискуссии это не имеет отношения. Некоторые БД применяют обход ФС и прямую работу с разделом на диске, потому что иерархичная ФС не всем нужна. Тем не менее, ОС в этом случае вполне успешно абстрагирует работу со специфичным железом. Я за полезные абстракции.

Или возьми HTTP/3 — они отказались от TCP в пользу самописного протокола на базе UDP. Потому что TCP не бесплатно и не всем подходит.

Ты все так читаешь?

То есть, в прямом смысле «never», прямо как в ACID СУБД.

Я даже боюсь представить зачем нужна очередь из которой ничего не удаляется. Как ты это видишь? Ты каждый раз обращаешься к последнему (первому) элементу и все? Зачем такое надо?

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

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

Что мешает придумать с потолка мини-кейс, иллюстрирующий проблему? Потому что «состояние» в этом ITT-треде давно уже пора табуировать.

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

авторизация — потому что простая

Ахаха, ох вау.

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

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

То есть, у них уже имеется нагруженный сервис.

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

у амазона цены на сервера и трафик примерно в 10-100 раз выше себестоимости.

И опять вы фокусируетесь на EC2.

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

Можно ещё перед рестораном с плакатом стоять: «Посетители, вас обманывают, еду можно готовить дома!».

Мой домашний интернет за $5

А идите-ка вы в https://aws.servicelist.cloud/, посмотрите что вообще AWS умеет делать, прикиньте, сколько времени вам понадобится, чтобы всё это сделать самому, помножьте на 10, помножьте на свою зарплату. Вот с этой цифрой и надо сравнивать расходы на аренду амазоновых сервисов.

Если я скажу «не надо ничего переделывать, оставим на EC2» — ты скажешь «зачем вам амазон?»

Не, я скажу: «ладно-хорошо, нагрузку вы гоняете на EC2, а остальное?».

Если вы не гугл — тут вообще разговоров нет, вам микросервисы не нужны.

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

Большинство кодеров гугла — это довольно обычные галерные гребцы

Большинство кого угодно — это довольно обычные люди. Автомобили вот, тоже, на посредственных водителей расчитаны, а не на гонщиков F-1. И это хорошо!

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

Плак-плак.

Даже если задержка передачи между сервисами составляет десятки миллисекунд, то цепочка из десятка сервисов

Вы, кажется, слишком радикально принялись толковать слово «микро». В реалистичном сценарии у нас получается что-то типа цепочки api-scheduler-worker-db, а то и просто api-worker. Но в целом, соглашусь, подход чувствителен к грамотной архитектуре, нужно правильно выделить микросервисы иначе будет плохо.

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

Почему физики предпочитают оперировать сферическими конями в вакууме? NDA запрещает учёт атмосферы наладить? Да нет, детали уводят от сути и мешают разглядеть главное.

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

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

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

Пакеты от дебиана и редхата тоже бы неплохо проверять.

Некоторые БД применяют обход ФС и прямую работу с разделом на диске,

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

Что мешает придумать с потолка мини-кейс, иллюстрирующий проблему? Потому что «состояние» в этом ITT-треде давно уже пора табуировать

s/состояние/заказы ёжиков пользователями на сайте/

Уже лучше.