Блог

Это может привести к предвзятым и основанным на мнениях ответам, если это так, я закрою вопрос, но…

У меня есть довольно основное требование по улучшению времени и скорости нашей работы. В рамках этого я рассматриваю два основных конкурирующих подхода: традиционный pub / sub и akka.net . В настоящее время у нас нет никаких проблем, и мы не ожидаем, что у нас возникнет необходимость в управлении параллелизмом.

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

Шаг 1) Захват работы, которую необходимо выполнить (Т. Е. Какие объекты должны выполнить некоторую работу)

Шаг 2) Выполните эту рабочую нагрузку и получите результат

Шаг 3) Сохранить результат

Используя традиционный pub / sub, это кажется довольно простым. Используйте микросервисы для каждого шага, отправляйте сообщение в конце каждого шага с требуемыми данными (или более точными данными, которые могут быть полезны) для следующего шага. Использование любого программного обеспечения вне очереди сообщений / темы / подписки обеспечивает хорошую возможность:

1) географически распределите нагрузки по всему миру туда, где находятся исходные данные

2) увеличьте количество «рабочих», которые подписываются на увеличение через put

3) переход к чему-то центральному, что может поддержать идею подключения «рабочих» с минимальной кривой обучения

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

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

Все это в значительной степени из коробки easy joy … при условии, что здесь соблюдаются разумные совокупные и ограниченные шаблоны контекста. Я не ищу советов о том, как написать хороший распределенный код, я ищу, как его развернуть, поддерживать, отлаживать сообщения rouge / missing / corrupt и т. Д. Именно поэтому я хочу знать, что такое Akka.сетевые предложения.

Я видел, что есть Akka.net кластеризация . Он может быть или не быть готовым к производству, но лучше всего я понимаю, что он может / может сделать для нас.

Итак, основные вопросы, которые у меня есть:

1) Где хранятся сообщения до их поступления? Пока издатель имеет доступ к конечной точке шины обмена сообщениями / программного обеспечения, любое такое программное обеспечение будет хранить и удерживать сообщения, ожидая, пока подписчик подключится и получит его сообщения (очевидные предположения о том, что подписка уже зарегистрирована, поэтому сообщения для нее стоят в очереди). Как Akka.net кластер справится со всем этим?

2) Какие инструменты существуют для оперативной поддержки этих очередей и почтовых ящиков в Akka.net кластер? Какие инструменты дают оператору представление о том, что находится в полученном почтовом ящике, но ожидает обработки, и какие существуют инструменты для просмотра того, что было «опубликовано» и еще не «получено»? Большинство конкурирующих программных продуктов Pub / Sub имеют операционные инструменты, поэтому я ищу здесь некоторое сравнение.

3) Как вы отлаживаете красные, отсутствующие или поврежденные сообщения. Мы все знаем, что должны доверять нашему программному обеспечению, но неверное сообщение может привести к выходу системы из-под контроля, так как же мне извлечь неверное сообщение из системы? Как я могу изменить сообщение, чтобы оно вело себя по-другому, потому что бизнесу нужно что-то исправить в 3:30 утра? Как я могу ответить на вопрос «где мое сообщение» словами «оно НАХОДИТСЯ в системе и ожидает получения» или «оно получено и только что в почтовом ящике»?

4) Если компонент выходит из строя (утилизация, сбой оборудования, что когда-либо), Что восстановит почтовые ящики, очереди и т. Д.? Любое сообщение, которое фактически обрабатывается, имеет приемлемый допуск потери, но 1000 сообщений в почтовом ящике, которые теряются, не так терпимы, какие существуют постоянство и допуск?

5) Легкий обзор, который я сделал, похоже, выступает за то, чтобы в ваше программное обеспечение был встроен шаблон супервизора для распределения сообщений (я предполагаю, для управления и снятия блокировок параллелизма?). Учитывая, что параллелизм здесь не является проблемой, какой готовый механизм pub / sub вы поддерживаете, который не является базовым удаленным обменом сообщениями между двумя (или x, внутренне определенными в коде) компонентами? Опять же, с подписками и разделами в большинстве программных продуктов pub / sub ваш первый объект отправляет сообщение (оно центральное, поэтому является потенциальной единственной точкой отказа), но этот компонент (и ни один другой код) должен знать, что будет использовать это сообщение. Это расширение nirvana сравнила со старым школьным способом, когда мы вручную передавали сообщение от одного объекта к следующему (и к следующему), перестраивая или перекомпилируя для каждого нового класса, в который должно было попасть одно и то же сообщение. Я стремлюсь не создавать наш собственный маршрутизатор сообщений.

6) Когда все экземпляры определенного компонента переходят в автономный режим (скажем, шаг 3 выше), что запоминает, что на самом деле есть что-то, что нужно поставить в очередь и запомнить эти сообщения (скажем, те, которые были отправлены вслепую с шага 2 выше)? В другом программном обеспечении, пока вы не удалите подписку, сообщения продолжают стоять в очереди на основе того, какие правила определены для TTL и т. Д. Что для этого предусмотрено?