Прочитана половина книжки по расту. Еще одни посиделки в кафе, может еще прочитаю сколько то. Какой же он классный. Это как джава здорового человека, без null и сборки мусора. Пока что все, что я увидел вызывает кайф.
Ну и то, что сразу есть карго+документирование и еще вагон того, что для джавы "привычно и удобно" и вообще много чего это отдельный кайф. Ничего такого я пока не нашел, чего бы не хватало. Так или иначе, пусть по своему, есть все, что надо.
@3draven про AST я уже говорил, concurrency есть только на бумаге, кластер на расте хуй соберешь… Немного же тебе надо :)
@mudasobwa да, меня кластер кубера всем устраивает. Не вижу смысла тащить это в язык когда он может содержать в себе код на десяти языках. Я тоже уже это говорил.
@3draven кластер кубера не умеет горизонтально масштабироваться же; ладно.
@mudasobwa Кажется ты написал странное. Автоскейлер кубера горизонтально масштабирует у нас поды прямо сейчас. И вертикально кубер управляет ресурсами сам тоже. Вероятно я не понял.
@3draven если у тебя не хватает ресурсов самой мощной машины на выполнение задачи (так бывает), то запуск еще хоть сотни подов тебе никак не поможет. Придется городить огород с брокерами, балансерами нагрузки, собирать результаты…
@mudasobwa Даже у меня дома поднятный кубер класстер состоит из двух нод (это не k8s, а обрезанный k3s) и поду мигрируют между нодами когда нет ресурсов. Что то ты странное пишешь. Да, это настраивать надо и там аффинити всякие, но ничего особенного в таких задачках для кубера нет, хотя я даже не девопс просто поделки дома делаю.
@mudasobwa Но что плохого в балансерах мне неясно. Вот так это работает, балансером можно командовать с кубера. Может быть по другому, ну, может, а может и еще десятью способами. В кубере горизонтальное скалирвоание есть.
@3draven какое конкретно слово тебе непонятно во фразе «одной задаче не хватает ресурсов ноды»? Не знаю, может тебе так будет понятнее: чтобы выполнить задачу надо 512G. Что ты куда собираешься мигрировать в такой ситуации?
Ладно, слепой глухого не уразумеет.
@mudasobwa так понятнее. Такие задачи обычно режут на куски. Действительно вероятно не разумеет.
@3draven да, в идеальном мире режут. А вокруг меня мир неидеален, и попадаются задачи, которые на куски не разрезать. Горячий кэш, например. OLAP. Да легион имя им.
Для CRUD — масштабирование, предлагаемое кубером подходит идеально, но я вон даже целый текст написал, почему называть запуск нового сервера, никак не связанного с остальными, масштабированием — абсолютно некорректно.
@mudasobwa не понимаю, есть задачи, которые в кубере распилить не выйдет, но есть волшебный резак, который распилит. При этом горячие кэши кластерные живут вроде в кубере, тот же ehcache или редис какой. Много я видать чего не понимаю. Есть не параллелизуемые алгоритмы, но на них нигде нет волшебного резака вроде.
> ehcache или редис
Я не говорил, что невозможно. Я говорил, что придется городить огород вокруг синхронизации, очередей, брокеров и диспетчеров — вместо того, чтобы получить это все бесплатно рпостым подключением еще одной ноды. Так, что код этого даже не заметит.
Если твой продукт — редис, то можно себе это позволить (и даже нужно, наверное). Но если нет — то тратить на вот это говно в 10 раз больше времени, чем на собственно код — не хочется. И да, редис не гарантирует FIFO.
@3draven вот смотри, очень простая задача.
Через сокет к тебе приходит 10К сообщений в секунду. Каждое следующее зависит от предыдущего (в пределах своей партиции). Потерять ничего нельзя, перепутать порядок — тоже.
Надо каждое перелопатить, на основе истории пересчитать и выплюнуть куда-нибудь. Одна физическая машина не справляется.
Можно, конечно, к ним цеплять таймстемпы, сохранять, а потом обрабатывать — но это, если подумать, очень нетривиально и там куча подводных камней.
@mudasobwa для этого и придумали кафку, логоподобное аддитивное хранилище. Народ просто режет архитектуру и каждый кусок имеет свое решение. Брокер сообщений вот в этом месте торчит. Да, с ним возни много, да, много да. Но компаниям пофиг потому, что теперь кафкой занимается отдельно взятый девопс, а код для нее не надо писать совсем. Меня подобный подход не напрягает, есть вещи, которые нужны ста компаниям сразу, их написали и отладили отдельно. Для маленьких коллективов это конечно боль.
@mudasobwa конкретно у нас девопса фамилия Никитин и я его гонял полгода пока он эту кафку освоил и все мои хотелки заработали.
@mudasobwa у нас на ней сидят сотни их, как сама логика, так и сливание логов туда идет (ради чего ее и выдумали собственно) из нее логи идут в эластик, в кибану. Там поток данных не слабый. В итоге ради одного микросервиса такое конечно жирно.
@3draven для этих целей вполне достаточно RabbitMQ (кафка нужна только, если надо что-то хранить в самом брокере, или если все остальное вокруг — джава), и RabbitMQ у нас тоже есть. Да и кафка есть, в команде джавы.
Что никак не отменяет того факта, что лишняя точка отказа, лишний провижининг, лишние девопсы в пайплайне — ради ничего — меня не устраивают. И, опять же, очередь, которая высыпается из брокера, надо правильно разгрести еще.
Запуск легковесного процесса — ну как-то естественней.
@3draven ну нашу контору назвать маленькой сложно, но во мне все восстаёт, когда вместо простого микросервиса, который я написал и отладил за две недели, мне говорят слово «кафка».
Я не езжу в булочную на Камазе.