Мне нужен шаблон проектирования, чтобы получить состояние подсистем
У меня есть распределенная система, которая имеет 13 подсистем. одна из подсистем должна контролировать состояние других. Мне нужен шаблон проектирования, чтобы получить состояние подсистем, когда мне это нужно? Другими словами, я хочу опросить мои подсистемы.
Я решил использовать наблюдателя для моей проблемы. Но я думаю, что может быть несколько раз, мои подсистемы потерпели крах, и тогда я не могу использовать шаблон наблюдателя. потому что они не могут отправить свое состояние для мониторинга подсистем, поэтому я должен пойти и получить состояние подсистем, что они не могли отправить свое состояние для мониторинга подсистем! Здесь моя проблема. и я не знаю, какой шаблон может мне помочь.
Я использую формулу (время ожидания). если подсистемы за это время меняют свое состояние наблюдателем, я получаю состояние, иначе я должен пойти и посетить их! могут быть разбиты или что они не изменили свое состояние (и они в безопасности). Наблюдая за ними и узнавая их состояние, я хочу узнать о состоянии моих подсистем. С помощью Memento, Как я могу решить свою проблему
2 ответа
Ваш вопрос, к сожалению, требует больше, чем "шаблон дизайна". Потому что вы просите что-то, что выходит за рамки концепции дизайна ООП.
Поэтому моя рекомендация будет (чтобы получить данные от узлов к 1 узлу)
1) системный журнал всех дампов на ваш сервер мониторинга.
2) что-то похожее на procmon для опроса каждой системы
3) использовать встроенную функциональность промежуточного программного обеспечения / платформы распределенной системы как ACE-TOA/ DDS/ и т. Д. что вы используете. для автоматического распространения данных от узлов к предполагаемому узлу.
Затем вам нужно спроектировать систему для сбора / чтения всех этих данных.
Кроме того, у нас есть данные... В этой системе вы можете использовать шаблоны проектирования, такие как Reactor/Proactor (из POSA2 http://www.cs.wustl.edu/~schmidt/POSA/POSA2/)
Но "трудной" частью проблемы на самом деле является механизм опроса / распространения данных. И это будет сильно зависеть от других базовых механизмов, которые вы уже используете.
Вам понадобится комбинация Observer и State Patterns.
Шаблон наблюдателя
Основная цель: мониторинг состояния 12 подсистем.
Реализация: 1 Подсистема, которая контролирует состояние других, будет Субъектом (давайте назовем это Подсистема Мониторинга), а все остальные 12 Подсистем будут наблюдателями. Когда состояние подсистемы-наблюдателя изменяется, он уведомляет монитор, который, в свою очередь, поддерживает состояние подсистемы в своем локальном реестре информации о состоянии (возможно, хэш-карту). Он также может распространить эту информацию на все 12 подсистем наблюдателей в случае необходимости обновления с точки зрения монитора.
Тем не менее, переходы на основе состояния будут учитываться реализацией шаблона состояния, как я объясню далее. (Примечание: если вам нужна дополнительная информация о шаблоне наблюдателя, вы можете обратиться к нему в моем блоге - http://www.javabrahman.com/design-patterns/observer-design-pattern-in-java/)
Государственный Образец
Основная цель: обрабатывать изменения состояния и переходы состояний для 12 подсистем.
Реализация: определите диаграмму состояний (аналогично конечному автомату) для ваших состояний и их переходов. Вам нужно будет определить базовый набор действий / методов на основе этих переходов. Это будут методы в вашем базовом состоянии. Каждое возможное для подсистем состояние будет отдельным ConcreteState, расширяющим базовое состояние.
Все конкретные состояния обеспечивают соответствующие реализации для действий - на основе 2 факторов - какой подсистеме назначено это конкретное состояние и какие возможные действия на основе перехода возможны. В случае, если действие неприменимо к состоянию, оно должно привести к сообщению об исключении / журнале, в котором говорится, что действие не применимо к этому состоянию для данной подсистемы.
Подсистема монитора также будет дублироваться в качестве контекста в шаблоне состояния, поддерживающего реестр (Hashmap - ключ в качестве идентификатора подсистемы и значение в качестве идентификатора текущего состояния или текущей конкретной ссылки на состояние), а каждой подсистемы viz-a-viz - их текущее состояние.
Методы в конкретных состояниях, реализующие переход состояния для каждого состояния, будут отвечать за изменение состояния этой подсистемы в реестре контекста с текущего состояния на следующее. (Примечание. Если вам нужна дополнительная информация о структуре состояний, вы можете обратиться к ней в моем блоге - http://www.javabrahman.com/design-patterns/state-design-pattern-in-java/).