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

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

Мокинг никто не запрещал как бы.

А ты типа всё это на проде собрался делать, что ли?

но добровольно идти на жирную НЕНАДЕЖНУЮ прослойку межмодульного взаимодействия ради какой-то абстрактной архитектуры

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

то то, что убило никсовое башеговно

Башеговно убил технический долг, а не что-то там.

Мокинг никто не запрещал как бы.

Ну сделай мокинг на работающем сервисе с какой-нибудь орм и ооп. Удачи восстановить стейт всего этого говна на момент ошибки.

А ты типа всё это на проде собрался делать, что ли?

Я и это делаю на проде, когда мне надо что-то пофиксить. Дада. В мелкоконотре в одно рыло с микросервиами.

Ну сделай мокинг на работающем сервисе с какой-нибудь орм и ооп. Удачи восстановить стейт всего этого говна на момент ошибки

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

В каком-то смысле микросервисная архитектору — это на самом деле психологический прием «зачем решать настоящую сложную проблему, если можно придумать решение выдуманной простой проблемы?». Отладив межсервисное взаимодействие ты на самом деле выполнил нулевую работу, потому что вся необходимость этой отладки возникла из-за микросервисности, которая была отрицательной работой, то есть, увеличением числа проблем при неизменной задаче. Примерно как если я скажу «будем оптимизировать решение задачи. Для этого задействуем DSL!» — и буду месяц писать hello world на этом DSL. Даже после блестящей отладки реализации hello world я не выполнил полезной работы.

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

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

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

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

Какой каталог? Там один бинарник rtorrent.

Што лишп?

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

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

Легко. Через ALTER PROCEDURE и ALTER TABLE всё на горячую меняется.

Я не вижу в данном случае разницы между микросервисами и монолитами.

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

Отладив межсервисное взаимодействие ты на самом деле выполнил нулевую работу

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

потому что зачастую баги размазаны по всей системе

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

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

Через ALTER PROCEDURE и ALTER TABLE всё на горячую меняется

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

Какой каталог? Там один бинарник rtorrent.

У меня нету rtorrent и всё работает. Получается, что не один. В случае микросервиса, там каждый инстанс тоже может быть отдельным бинарником. Претензия странная.

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

И что, лишп из коробки можно растащить по куче серверов?

Легко. Через ALTER PROCEDURE и ALTER TABLE всё на горячую меняется.

Ага. С блокировкой таблицы и постановкой всей бд раком.

У меня нету rtorrent и всё работает. Получается, что не один. В случае микросервиса, там каждый инстанс тоже может быть отдельным бинарником. Претензия странная.

Я в том смысле, что каждый узел торрента можно реализовать одним бинарником. Если торрент считать микросервисом, то мы сейчас дойдём до того, что микросервисы и сервера любого сетевого протокола (HTTP, SMTP, …). Микросервисной реализации узла торрента я не знаю (в отличие от SMTP, где примером можно взять qmail).

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

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

Кстати, как пример как раз тот самый qmail. Половину возможностей postfix сделать нельзя, так как для этого один сервис qmail должен принимать решение по обработке, которую должен выполнять другой сервис. А в протоколе нет места, куда информацию о решении передать.

И что, лишп из коробки можно растащить по куче серверов?

Не совсем из коробки, но можно. Если надо именно из коробки, то Racket (который тоже подвид лиспа) и Erlang.

Ага. С блокировкой таблицы и постановкой всей бд раком.

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

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

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

если тебе не надо раскидывать задачу на кучу тачек

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

Если тебе нужно раскидывать задачу на кучу тачек, то раскидывай — микросервисы тебе зачем?

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

Где вариант «низкая связанность и всё в говне»? Чтобы заставить систему с низкой связанность выполнять полезную работу, нужно быть мастером спорта по приседаниям. Говоря русскими языком: это О-ОЧЕНЬ ТЯЖЕЛО, менее процента рынка умеет это делать. Потому что комбинаторная сложность вариантов выполнения улетает туземун очень быстро, как я писал в начале статьи: https://habr.com/post/587750/

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

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

В этом есть рациональное зерно, но вывод неоднозначен. Раскидав сделанные «на отлюбись» сервисы по двум машинам ты можешь получить результат, обратный понятию «масштабирование», то есть, твоя система станет работать медленнее, чем до «масштабирования», менее стабильно, чем до «масштабирования», с большей задержкой ответа. Вертикальное масштабирование нынче весьма перспективно: единицы терабайт RAM, сотня ядер процессора, или какие-нибудь 500 ТБ дисков в 4U сервере. Людям обычно даже не абстрактное масштабирование в вакууме нужно, а простая репликация, чтобы после смерти одного сервера второй продолжал работать как ни в чем не бывало — но это централизация, а не распределенность.

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

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

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

Придумываешь любой вариант тупого конвеера «действие один — действие два — действие три» придумываешь манагера, который прибегает с криками «ничего не работает» — дальше отвечаешь, что делать в этой ситуации. Или по-твоему бухгалтер будет приходить со словами «я тут строил отчеты, у меня шли нормальной REST-запросы по роутам /buh и /accounts, но потом внезапно роуты /accounts начали виснуть, а /buh иногда возвращали 500, это отразилось на актуальности отображаемых данных, которая критична для работоспособности аналитического модуля»? Нет, он будет прибегать с крикими «ничего не работает», причем, спустя две недели после того, как проблема вознила, когда она уже в глубоко запущенном состоянии с кучей безвозвратно потерянных данных. Или же наоборот, будет на каждый чих жаловаться про "website is down", когда ему нужно было просто перезагрузить свой глючный роутер.

Да, круто иметь совсем-совсем независимые сервисы, но это уже не система, а независимые программы.

JS, Python умеют из коробки перезагружаться,

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

Если тебе нужно раскидывать задачу на кучу тачек, то раскидывай — микросервисы тебе зачем?

Работать на этих тачках кто будет? Монолит? Или там задачи могут быть разные? И приложения разные? И как они будут работать друг с другом и координироваться?

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

А тебе она нужна? Или не нужна? Можно и с ней и без неё. Можно её распределять. Можно делать распределение одним куском? Можно. Только если вся система состоит из множества отдельных куском, этот твой «монолит» уже будет и не такой уж монолит. В чём проблемы?

Где вариант «низкая связанность и всё в говне»? Чтобы заставить систему с низкой связанность выполнять полезную работу, нужно быть мастером спорта по приседаниям.

А можно не быть и тупо не делать её там, где она не нужна. В чём проблемы опять?

Раскидав сделанные «на отлюбись»

Мы не сравниваем говно с алмазами. Говно сравнивается говном, алмазы с алмазами.

Вертикальное масштабирование нынче весьма перспективно

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

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

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

я тут строил отчеты, у меня шли нормальной REST-запросы по роутам /buh и /accounts, но потом внезапно роуты /accounts начали виснуть, а /buh иногда возвращали 500, это отразилось на актуальности отображаемых данных, которая критична для работоспособности аналитического модуля

Если ты размазал всё по куче бд и у тебя одна лягла, то у тебя и всё, что связанно с ней ляжет. Как и везде. Почему оно должно лечь тихо - не понятно. Почему твои бд, которые ты размазал, лежат и их никто не мониторит - не понятно. В случае монолита, когда, по совету выше, кто-то сделал в бд alter table и похерил всё, отличаться будет результат чем? По итогу, в чём сосут микросервисы - не понятно. Этот пример херовый давай еще пример.

Я тебе другой пример приведу, с нашей бд. Она тут прилягла на 15 минут, и что ты себе думаешь? Правильно, все платежи за эти 15 минут были просраны. Ладно, нам похер, нам реестр потом придёт, а если надо было бы принимать в онлайне, то что? Лаганул где-то роутер, с гейта не понятно дошло ли до бд, гейт не терпит отказов и что дальше? Трахаться с микросервисами, чтобы несколько писали всё, что приходит, а потом проверяли между собой и бд данные, пересылая всё, что не дошло. Других нет вариантов, всё. Монолит если где-то прилёг, то это gameover, потому что acid. Потому что надо поднимать и смотреть, какие транзакции просрались во время сбоя, а какие нет. Надо смотреть, не развалился ли кластер и прочие пляски. См. CAP теорему короче, acid с бд - это CA. Оно в принципе не устойчиво к разделению. Если тебе надо добавить этой устойчивости, будешь где-то крутить CP/AP со всякими доступность когда-то позже и согласованность когда-то там, как миленький и никуда не денешься.

Если торрент считать микросервисом, то мы сейчас дойдём до того, что микросервисы и сервера любого сетевого протокола (HTTP, SMTP, …)

Ну так их иногда так и делают, без брокера, как http сервера, которые друг в друга что-то там кидают. А ты как хотел?

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

Ну так тут тоже хрень с одной задачей реализуется одним сервисом. А что? На торрент надо минимум 3 бинарника? Почему и зачем? С сетью все равно будет один работать.

Вот примерно в этом и есть недостаток микросервиса. Иногда задача поневоле становится высокосвязной в процессе развития.

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

И тогда либо всё выкидывать и переписывать на монолит,

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

Кстати, как пример как раз тот самый qmail

Распилили то, что пилить не надо было. Ну и что?

Если надо именно из коробки, то Racket (который тоже подвид лиспа) и Erlang.

Ну так это по сути оно и есть. Со всеми проблемами микросервисов.

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

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

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

Речь про это:

https://stackoverflow.com/questions/3862871/hot-reloading-swapping-with-pytho...

You can use reload(module) for this, but beware of nasty side effects. For example, existing code will be based on the original code, it will not magically get new attributes or baseclasses added.

?

Но ведь .NET умеет в полноценный hot reload ?

https://www.c-sharpcorner.com/article/hot-reload-for-net-developers/

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

Прописать контракты досконально возможно, но этого никто не делает

у вас то? ну тогда понятно что к чему :)

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

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

В монолитах трассировка на любую ошибку.

и сколько она стоит?

Делаешь ещё один поток и в нём считаешь.

а рейтинг в профиле игрока тоже сервером рисуешь? На каждую фичу «еще один поток»? Вопросов больше не имею.

Ну так это по сути оно и есть. Со всеми проблемами микросервисов.

С половиной проблем. Нет дикого оверхеда на HTTP/JSON. Нет проблемы разных библиотек (а иногда и разных языков) в разных сервисах.

С другой стороны и половина преимуществ. Разные языки всё-таки часто помогают не писать свои велосипеды.

и сколько она стоит?

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

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

Да, я прекрасно помню, кто ты и чем занимаешься, даже несмотря на то, что ты у меня никак не помечен.

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

Вот конкретно это задача «рейтинг по снимку» находится как раз на той грани, когда она масштабируема до небес. Вплоть до того, что на отдельных серверах с логикой боев локальная стата пишется в произвольном собственном формате на локальный диск, но выдается наружу для snapshot-map-reduce по единому протоколу. Здесь некорректно говорить про «работать на какой-то базе», потому что ETL подразумевает минимум две БД, и сам map-reduce подразумевает некую распределенность БД. Я уверен, что при должной упертости и упоротости я бы сделал эту стату обновляемой в реальном времени — называнные цифры представляют собой 1000 человекосессий в секунду (ну пусть будет 5000 в пике), вряд ли там нужно больше килобайта байт статистики на человекосессию, а это значит, что статистика по всей системе влезет в один канал на несколько десятков мегабит/с — подсильно моему домашнему роутеру, если на него повесить SSD диск (конечно, у меня не самый слабый роутер, но всё же).

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

А потом приходит пм, тыкает в календарь и оставляет только один вариант

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

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

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

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

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

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

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

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

Если ты размазал всё по куче бд и у тебя одна лягла, то у тебя и всё, что связанно с ней ляжет. Как и везде. Почему оно должно лечь тихо - не понятно. Почему твои бд, которые ты размазал, лежат и их никто не мониторит - не понятно. В случае монолита, когда, по совету выше, кто-то сделал в бд alter table и похерил всё, отличаться будет результат чем? По итогу, в чём сосут микросервисы - не понятно.

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

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

Потому имхо без крайней необходимости и соответствующей команды микросервисы зло.

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

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

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

Можешь говорить «правильный ответ».

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

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

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

кстати, какую нагрузку у нас может выдержать ClickHouse в реплицированном варианте

Сейчас не юзаю, но в Я он выдерживал например метрику для которой его делали. Ну и выдерживал все логи нашего сервиса, что было овердохрена и сообщения немаленькие (жаба и ее толстые стектрейсы). Да и кстати бинлог базы туда же летел. Там правда были хитрости типа очередей, батчей и прочего, но просадка выше нескольких десятков секунд была редкостью. Я бы сказал несколько тысяч толстых рпс с батчами по 20-30 записей оно держит. Но ясен пень что нужны нормальные админы чтоб это настроить/поддержать

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

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

Ну как бы его обычно и ставят сзади какой mq, которая in-memory набивает пачку сообщений и потом разом их сливает в базу. Тот же sentry так и работает.

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

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

Шардирование — это и есть по сути map-reduce. Как ты собрался иначе в шардированном кластере запрашивать данные?

Запрашивать - да, mr, я и не спорю.

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

А кто решает проблему типа: «в истории сообщений я вижу чужое сообщение от моего имени»? Если такая проблема редка (менее 1% пользователей) и при прогоне тестов не воспроизводится. Как разработчику сообщают, что именно поправить надо? Особенно, если хранение сообщений, вывод сообщений и идентификация пользователей на разных сервисах.

Так сабтред о Power Shell.

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

Категорически поддерживаю!

А кто решает проблему типа: «в истории сообщений я вижу чужое сообщение от моего имени»? Если такая проблема редка (менее 1% пользователей) и при прогоне тестов не воспроизводится. Как разработчику сообщают, что именно поправить надо? Особенно, если хранение сообщений, вывод сообщений и идентификация пользователей на разных сервисах

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

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

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

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

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

Работать на этих тачках кто будет? Монолит? Или там задачи могут быть разные? И приложения разные? И как они будут работать друг с другом и координироваться?

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

Вертикальное масштабирование нынче весьма перспективно

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

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

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

А тебе она нужна? Или не нужна? Можно и с ней и без неё. Можно её распределять. Можно делать распределение одним куском?

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

Где вариант «низкая связанность и всё в говне»? Чтобы заставить систему с низкой связанность выполнять полезную работу, нужно быть мастером спорта по приседаниям.

А можно не быть и тупо не делать её там, где она не нужна. В чём проблемы опять?

Ну да, и пусть система не работает — я ж не спорю, такой вариант много кого устраивает.

Раскидав сделанные «на отлюбись»

Мы не сравниваем говно с алмазами. Говно сравнивается говном, алмазы с алмазами

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

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

Если у тебя acid во все поля - то да, другого тебе никто и не придумает

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

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

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

Я тебе другой пример приведу, с нашей бд. Она тут прилягла на 15 минут, и что ты себе думаешь? Правильно, все платежи за эти 15 минут были просраны... Лаганул где-то роутер, с гейта не понятно дошло ли до бд, гейт не терпит отказов и что дальше?

Гейт отвечает подтверждением после двух подтверждений от конечных БД - вот и всё решение. Как раз мне было бы интересно узнать, как вы собрались подтверждение (именно настоящее подтверждение объ успешном завершении) присылать с микросервисами. Безусловная постановка в реплицируемую предварительную очередь не значит ничего — поставленный запрос может никогда не выполниться из-за какой-то логической ошибки. Аналогично backpressure для микросервиснутых является каким-то космосом, хотя у меня на это постоянно возникает реакция «как вы вообще начинали что-то реализовывать без оглядки на backpressure?». Чем больше звеньев в транзакции, тем более сложно реализовать обратное распространение и тем менее надежной оказывается система. Я ugoday задавал аналогичный вопрос, для него это тоже новость.

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

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

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

Логовая база в mysql federated (все старше месяца уходит на архивные серваки на медленных и дешевых хранилках).

Включается на N времени сквозная трассировка на проде

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

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

P.S. типичный программист in the wild в продакшене это натурально обезьяна с гранатой. Единичные исключения не в счет.

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

поэтому Я сделали тарантул? ;)

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

Как по мне — чрезмерно сложно и медленно. Я уже отвечал, что умолчательный питоний пикл — это жутко неэффективно, как по объему, так и по скорости. С тех пор я даже свое подобие пикла сделал. Вся функциональность map-reduce могла быть реализована в сервисе на C/C++ с SQLite (учитывая, что поддержке WAL и фонового бэкапа там уже больше 10 лет) и бегать на игровых серверах в фоне с <1% загрузки ЦП. Пусть даже жава, Go, или что угодно со сборкой мусора, но я вообще против питона на пути данных в любой нагруженной логике — как человек, который довольно много читал сорцы CPython, и не просто читал, а «дорисовывал», который видел, как там всё плохо несмотря на десятилетия «оптимизацией». Аналогично, центральные сервера статистики могут сидеть на 100 Мб/с каналах и скидывать агрегированную стату на НДМЖ — даже если это 100 ГБ в день, сервера на сотни ТБ накопителей в стандартную стойку нынче не редкость (получается порядка $800-1000 за 10 Тб RAID 1).

Логовая база в mysql federated (все старше месяца уходит на архивные серваки на медленных и дешевых хранилках)

Честно говоря, не понимаю, зачем оно. У меня мало веры в MySQL, смысл в федеративном хранилище я вижу только если у меня уже есть готовое решение строго под MySQL, но тут мне внезапно захотелось поиграть в распределенную БД. Именно «поиграть», потому что настоящей распределенной БД оно не заменит (чо там по распределенным снимкам?).

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

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

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

Вообще не понимаю, про какой «правильный подход ты пишешь. Я вообще-то имел в виду универсальные инструменты для построения распределенных-отказоустойчивых систем, который именно что упрощают реализацию каждой новой задачи, а не просто вылизывать ad-hoc костыли под единственную задачу.

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

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

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

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

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

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

А зачем и куда ее развивать? В мире нет потребностей для переваривания таких объемов информации, да и самих объемов нет. Все, кто пилит чрезмерно сложный софт - монополисты

При чем тут «чрезмерно сложный софт»? Вся кодовая база гугла на сегодня больше, чем геном человека. Он не сложный, он ПЕРЕУСЛОЖНЕННЫЙ, это всё ещё уровень каменных топоров, только вытёсывает вручную из кремня их целая фабрика людей. Моя теория проста — на то волья Божья, рано мартыхам иметь развитые технологии, они того и гляди поубивают друг друга ядерным оружием. Потому миром правят не экспериментаторы-художники, а барыги-мошенники, которые продавали бы каменные топоры покрашенные под золото ещё две тысячи лет.