Отказоустойчивая избыточность
Это может привести к необъективным и основанным на мнении ответам, если так, я закрою вопрос, но...
У меня есть довольно основное требование улучшить время работы и скорость. В рамках этого я смотрю на два основных конкурирующих подхода: традиционный pub/sub и akka.net. У нас нет проблем в настоящее время или мы ожидаем, что нам понадобится контроль параллелизма.
У нас есть несколько основных рабочих процессов, которые представляют собой анализ данных, манипулирование и сохранение результата:
Шаг 1) Захват работы, которая должна быть сделана (т.е., какие объекты должны сделать некоторую работу)
Шаг 2) Выполните эту рабочую нагрузку и получите результат
Шаг 3) Сохранить результат
Использование традиционного паба / саба. Это кажется довольно простым. Для каждого шага подготовьте микроуслуги, в конце каждого шага отправьте сообщение с необходимыми данными (или более точными данными, которые могут быть полезны) для следующего шага. Использование любого программного обеспечения для самостоятельной очереди сообщений / тем / подписок обеспечивает хорошую возможность:
1) географически распределить нагрузки по всему миру, где расположены исходные данные
2) увеличить количество "работников", подписавшихся на увеличение через пут
3) подтолкнуть к чему-то центральному, что может поддержать идею соединения "работников" с минимальной кривой обучения
4) любой компонент (или набор рабочих для компонента), находящийся далее в рабочем потоке, имеет / имеет очередь, в которой очередь сообщений и ожидает возврата указанного компонента в оперативный режим (даже если весь компонент отключается)
5) Добавление новых компонентов, которые делают что-то новое и отличное, так же просто, как регистрация новой подписки на тему.
Это все в значительной степени из коробки легкая радость... при условии, что здесь соблюдаются разумные совокупные и ограниченные шаблоны контекста. Я не ищу совет о том, как написать хороший распределенный код, я ищу, как развернуть его, поддержать его, отладить румяна / пропавшие / поврежденные сообщения и т.д. Именно поэтому я хочу знать, что предлагает Akka.net.
Я видел, что есть кластеры Akka.net. Он может быть или не быть готовым к производству, но лучше всего я понимаю, что он может / может сделать для нас.
Итак, основные вопросы, которые у меня есть:
1) Где хранятся сообщения до прибытия? Пока издатель имеет доступ к конечной точке шины / программного обеспечения для обмена сообщениями, любое такое программное обеспечение будет хранить и удерживать сообщения в ожидании подключения абонента и получения его сообщений (очевидные предположения о подписке уже зарегистрированы, поэтому очередь сообщений для нее). Как кластер Akka.net обрабатывает все это?
2) Какие инструменты существуют для оперативной поддержки этих очередей и почтовых ящиков в кластере Akka.net? Какие инструменты позволяют оператору понять, что находится в полученном почтовом ящике, но ожидает обработки, и какие инструменты существуют для просмотра того, что было "опубликовано" и еще не "получено"? У большинства конкурирующих программ Pub/Sub есть операционные инструменты, поэтому я ищу некоторое сравнение здесь.
3) Как вы отлаживаете румяна, пропавшие или поврежденные сообщения. Мы все знаем, что должны доверять нашему программному обеспечению, но плохое сообщение может привести к выходу системы из-под контроля, так как бы я выбрал плохое сообщение из системы? Как я могу изменить сообщение, чтобы оно могло вести себя по-другому, потому что бизнесу нужно что-то исправить в 3:30? Как я могу ответить "где находится мое сообщение" с "оно есть в системе и оно ожидает получения" или "оно было получено и только в почтовом ящике"?
4) Если компонент выходит из строя HARD (перезапуск, сбой оборудования и т. Д.), Что восстановит почтовые ящики, очереди и т. Д.? Любое сообщение, которое фактически обрабатывается, имеет допустимую потерянную терпимость, но потеря 1000 сообщений в почтовом ящике не так терпима, что за стойкость и терпимость существуют?
5) Легкий обзор, который я сделал, по-видимому, защищает шаблон супервизора, который будет встроен в ваше программное обеспечение для сбора сообщений вокруг (я предполагаю управлять и снимать блокировки параллелизма?). Учитывая то, что параллелизм здесь не является проблемой, какой механизм "паб / суб" из коробки вы поддерживаете, который не является базовым удалением сообщений между двумя (или x внутренне определенными в коде) компонентами? Опять же, с подписками и темами в большинстве программ паб / саб, ваш первый объект отправляет сообщение (оно является центральным, так что это потенциальная единая точка отказа), но этот компонент (и ни один другой код) не должен знать, что будет потреблять это сообщение. Это расширение нирваны по сравнению со старым школьным способом, когда мы вручную помещали сообщение от одного объекта к другому (и к следующему), перестраивая или перекомпилируя для каждого нового класса, к которому должно было идти то же сообщение. Я стремлюсь не создавать свой собственный маршрутизатор сообщений.
6) Когда все экземпляры определенного компонента отключаются (скажем, шаг 3 выше), что помнит, что на самом деле есть что-то, что нужно поставить в очередь и запомнить эти сообщения (скажем, те, которые слепо оттолкнулись от шага 2 выше)? В другом программном обеспечении до тех пор, пока вы не удалите подписку, сообщения продолжают стоять в очереди на основе каких-либо правил, определенных для TTL и т. Д. Что предусмотрено для этого?