А как же ruby?

Проблема в том, что в представленных языках я имею достаточно компетенции, чтобы заявлять, что на них хорошо ляжет ФОП, а на рубях я писал только используя рельсы и где-то лет 5 назад :(

С удовольствием добавлю Руби в ФОП, но мне нужна помощь более компетентного в Руби разработчика, чтобы убедиться, что они сочетаемы

Прошу прощения. Не уточнил.

Я к этому предложению спросил: "А еще, поразительно и крайне смешно то, что практически единственным языком, который на максимум использует ООП архитектуру – Erlang один из самых каноничных функциональных языков программирования…"


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

Понял

Как я описываю в статье, у нас есть 2 ООП: ООП синтаксис и ООП архитектура

Ruby полностью поддерживает синтаксис ООП

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

Каждая функция полностью инкапсулированна, функции общаются сериализуемыми сообщения (об это редко говорят, но этот маленький аспект является крайне важной частью ООП и ни одним ООП язык не накладывает запрет на несирализиуемые аргументы в методах класса, что уже нарушение архитектуры ООП; тема очень большая и я думаю напишу отдельную статью посвящённую именно «сериализованным сообщениям в ООП»), каждая функция связана с набором других, с которыми она общается, выстраивая граф

Поэтому Erlang с точки зрения своего внутреннего устройства полностью отвечает архитектуре ООП, а Ruby (как и Java, C#, etc.) лишь даёт возможность использовать синтаксические конструкции ООП и самостоятельно реализовать архитектуру уже на уровне кода

Здесь можно вспомнить и SmallTalk. Язык, в который Алан и заложил свои идеи ООП.

Основными идеями Smalltalk являются:

* Всё - объекты, и всё их взаимодействие — через посылку сообщений;
* Всё доступно для изменения;
* Динамическая типизация


———

Еще задолго до появления Smalltalk Алан Кей сформулировал три фундаментальных принципа объектно-ориентированного программирования (Simula-67):

* Объект - базовая единица объектно-ориентированной системы.
* Объекты могут обладать состоянием.
* Посылка сообщения - единственный способ обмена информацией между объектами.

Да, SmallTalk тоже отличный пример

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

Кстати, вопрос, а откуда именно строка \"все доступно для изменения\"? Звучит крайне противоречащей инкапсуляции, может, я не совсем правильно ее понимаю

Здесь без сюрпризов.
С вики (статья на русском) взял.

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

Аааа, понял, это про Live Coding, то есть возможность изменять приложение без перезапуска, а прям на лету, когда оно уже работает в интерпретаторе + возможность изменять правила компиляции и конструкции языка

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

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

Сколько я не капался в дип-нете на тему моей проблемы, я не находил ничего подходящего, поэтому решил пойти с другого конца: перечитать Getting started

В очередной раз я прохожу абзац, в котором написано: "вы не должны использовать auto-delete очереди, если сами задаете им название" – и пример: "если вы создадите очередь с auto-delete, отключитесь от одной ноды, а потом быстро переключитесь на другую, то RMQ не поймет что делать и у вас возникнут ошибки на стороне клиента"

А мы и создаем auto-delete именованные очереди (для чего расскажу в следующем посте) и это именно то, что нам было нужно от RMQ

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

И тут я подумал: "а что если эта гнида также ведет себя в момент выпадения одной из нод, но при поднятии просто не отправляет нам разрыв connection из-за рейсинга конфигурации?" – и я блять оказался прав

Когда нода на которой auto-delete очереди отрывается от кластера (даже на пару секунд) и при этом consumer-ы находятся на соседней ноде, то кластер не закрывает их соединения и не кидает ошибок, но при этом удаляет очередь...

И единственный сука адекватный способ решения проблемы – сделать все очереди реплицируемыми (quorum) и поразительно, но именно это моментально превращает RMQ просто в умственноотсталую версию Kafka

Но описание почему слишком больше, поэтому расскажу в следующем посте

У нас есть было 2 стула вида коммуникации

Event Driven Architecture (выкинули event и забыли, а с другой стороны кучей читателей прочитали) и RPC (отправили запрос, ждем ответ от 1 читателя) + ясен пень, это все должно работать в кластерном режиме хотябы из 3-х нод

EDA должен нам гарантировать: "если мы выкинули event и увидели, что он попал в очередь, то с другой стороны его рано или поздно смогут прочитать в правильной последовательности нужное кол-во инстансов"

RPC должен гарантировать: "если читателя нет, то мы должны об этом узнать, чтобы сделать retry, если его так и не появлось, то вернуть timeout, а если читатель есть, то в оптимальный промежуток времени получить ответ или вернем timeout"

Заходят в бар RMQ, NATS и Kafka

NATS – message broker, то есть его задача дать возможность подписаться и отправлять сообщения в топики в формате fire-and-forget, при этом он не гарантирует очередность.

Он отлично подходит для RPC (в нем даже есть вшитый модуль), но поскольку он не гарантирует последовательность и что сообщение дойдет до читателя, который еще не успел подняться, мы не можем использовать его для EDA (сразу скажу, JetStreams не рассматриваем)

Kafka – распределенный лог: записываем в конец и читаем с желанного момента (оффсета)

Прекрасно решает вопрос EDA (сложность только в рассчете партишенов и реализации внешних локов на очереди, но об этом ниже) и в целом можно реализовать RPC (он просто будет немного "жирным")

RMQ – это что-то среднее между двумя мирами: fire-and-forget, с гарантированной последовательностью, а распределение и уникальность достигаются параметрами очереди (exclusive, single-active-consumer, durabitlity, etc.) и жанглированием видами exchange + queue

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

На практике же это гавно работает нормально только при определенных настройках из-за которых он становится херовой альтернативой как NATS, так и Kafka

Мульти-тул = зеро-кволити

Так вот, RMQ очень любит разъебать кластер и не собрать его.

Во-первых, для RMQ абсолютная норма показывать вам, что все в порядке, все очереди и exchange есть, но на деле при попытке записи или потребления ничего происходить не будет ДАЖЕ ОШИБКИ. Почему? Потому что он неправильно синхронизировал свою конфигурацию. Как лечить? Или ручным удалением очередей, или перезагрузкой ноды, или сменой всего кластера (я не шучу, нам приходилось все 3 варианта делать)

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

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

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

Из преимуществ остается только его встроенная система управления читателями, НО смехуючек в том, что в итоге, если вы хотите не просто иметь "одного читателя в моменте на очередь", а "по одному читателю в моменте на набор очередей с балансировкой кол-ва очередей к читателям" (а это частый кейс), вам так и так придется самостоятельно реализовывать локи на очереди, как и на Kafka...

Для меня это очередной кейс "швейцарского ножа", который может, но херов во всем

Можно ли использовать RMQ? Если вы будете использовать quorum очереди без частого их создания, вам достаточно fire-and-forget и при этом не хотите разбираться с партишенами, курсорами и распределением в Kafka, то да RMQ будет делать свое дело.

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

Ах да, еще одно интересное умозаключение:

RMQ даст вам кучу возможностей, но они будут работать только пока он в 1 инстансе, встает вопрос: \"а зачем вообще их давать?\" – а потому что RMQ все-таки в первую очередь технология, которая предполагает работу в 1 инстансе и все дальнейшие навороты с кластером это фичи, которые пришли постфактум, потому что время и рынок диктовали условия

Но эта технология очень плоха в кластеризации

Поэтому второй вариант использования RMQ: если вам достаточно 1 инстанса, то вы тоже (наверное) спокойно можете использовать RMQ

И еще раз подытоживая я отметил бы 2 момента:

1. Вместо того, чтобы жестко ограничить какие-то свойства очередей в случае наличия кластера, они часто пишут \"рекомендации\" (не)использовать ту или иную фичу в кластере

Но если эта фича полностью ломает очереди при кластеризации, то это нехера не \"рекомендации\" это просто надо запрещать использовать и все

2. Если уж RMQ добавили возможность кластеризации, то сделайте синхронизацию конфигурации надежной, даже в ущерб скорости.

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

И если бы эти 2 пункта были, то моя претензия осталась бы на уровне: \"В итоге, RMQ это упрощенная, но более медленная альтернатива Kafka\" – и в такой формулировке я бы мог доверять технологии, а при текущей ситуации, когда она ломает кластер и вообще ничего об этом не сообщает доверия 0