не помню, может даже по исчерпанию памяти

это на каком количестве эндпоинтов такое?

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

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

не думаю, что они там суффиксное дерево на типах написали или типа того

хотя вдруг и написали, конечно

префиксное

написали

круто

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

https://github.com/haskell-servant/servant-benchmarks/blob/master/benchmarks/Routes.hs

как раз сто ендпоинтов

не падает наверное

https://github.com/haskell-servant/servant-benchmarks/blob/master/benchmarks/Routes.hs

от типов вытекли глаза

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

хотя вырожденный случай

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

это да...

а как решать задачу с апдейтами "по узлам" в таких микросервисах? если у меня есть 10 микросервисов, какие-то из общаются сервантом по http друг с другом, то понятно, мне удобнее type Api = ... держать общим для каждой пары клиент/сервер. Но как тогда апдейтить клиента/сервера и не ломать API? В обычной ситуации спасает как раз нестрогость и то, что это json, а как быть с сервантом?

"то, что это json" = "любой текстовый формат, позволяющий пропускать поля"

фиг знает, поставить перед ними nginx, сет нод поднять на других портах ,передернуть nginx, старые ноды загасить

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

immutable infrastructure, да

можно еще более наркомански

все эти ноды форкаются одним жирным процессом

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

впрочем, не исключено что systemd предлагает что уже готовое для этой задачи

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

а надо-то чтоб без даунтайма

иначе нафига микросервисы городить

что бы ghc не валился и не тормозил слишком сильно на компиляции серванта же

хм

ну разве что

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

и для её решения есть же какие-то стратегии в зависимости от требований

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

то почему бы не поднять сразу и старые и новые, если у нас есть LB

и старые постепенно отстреливать?

угу, как-то так

и возможно две версии type Api = ... на какой-то время дердать

держать

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

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

еще LB может быть умным, и запросы направлять бэкендам в зависимости от версии API

мидлварь это в данном случае nginx или типа того?

wai

нормализую запросы перед тем как их в сервант скормить

о как

что бы в нем не плодить лишних веток

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

звучит страшно, но видимо это как раз способ убрать железную compile-time привязку

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

не, это же в том же процессе, где и api

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

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

может это и решит вопрос. но надо исследовать

да, но это решает задачу апдейта по частям

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

так-то надо смотреть конечно

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

ну зависит. но мне сейчас кажется, что при помощи wai можно растащить разные версии API по разным типам и решить проблему падения ghc, но не решить проблему медленной компиляции

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

смысл что эти куски можно по разным машинам растащить

если понадобится

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

зависит от того все ли подконтрольно

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

в итоге на разных нодах могут быть слегка разные версии haskell софта и сишного

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

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

а самая задница в том, что там cloud-haskell и он использует Fingerprint для роутинга сообщений

кстати да, а как вы это делаете вообще? особенно если с бинарной сериализацией

у нас есть тип StablePrint

который дает стабильный Fingerprint данным

и есть таблица StablePrint->Fingerprint

+SafeCopy

но это в одну сторону

там есть ещё от "мозга" процесс, который на какой-то их нод, на которх consensus protocol работает

к сервисам, и в эту сторону сейчас решаем

пока непонятно

там какой-то ад наворотить хотят

переусложнёный но с похожим принципом

да есть плюс, network-transport и binary пофиг на версии там все стабильно

а что у вас за кнсенсус?

paxos

который посложнее или который попроще? черт, забыл

посложнее

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

raft

да

у нас paxos с парой усложнений

там есть pipelining и ещё какая-то оптимизации

в paxos made live описаны

у нас что-то таки сделали

страшно даже представить, что вы там такое делаете

что вам это всё нужно

кластером управляем

на самом деле не вижу причин почему бы тут рафт не взлетел

а кластер что делает? )

Управляется!:)

данные сохраняет и отдает