Одной из ключевых концепций, которые следует учитывать при планировании и проектировании архитектуры системы ArcGIS GeoEvent Server, является разделение рабочей нагрузки; в терминологии GeoEvent Server это называется разделением событий. При разделении событий каждый поток событий должен быть помещен в корректный блок таблицы ниже, и идеальная архитектура производственной системы должна планировать обращение к каждой ячейке с помощью отдельной системы GeoEvent Server. Используя эту стратегию, оптимизированная система может быть развернута для решения определенных задач для различных потоков событий. Оптимальная архитектура системы должна учитывать сложности системного администрирования, лицензирования и затраты на оборудование.
В производственной среде вы должны стремиться разделить потоки событий, общие для каждого блока, на отдельную машину GeoEvent Server. В общей сложности существуют четыре возможных сценария, однако дополнительные стратегии разделения, обсуждаемые ниже, могут увеличить количество сценариев. Концепции, составляющие каждый из базовых сценариев, обобщены и более подробно рассмотрены ниже.
- Сценарий 1 – Push событий + Историческая зависимость
- Сценарий 2 – Pull событий + Историческая зависимость
- Сценарий 3 – Push событий + Историческая независимость
- Сценарий 4 – Pull событий + Историческая независимость
Доставка события
GeoEvent Server получает потоки событий с помощью процессов push (выталкивание) или pull (вытягивание).
Push событий
При использовании Получать текст из TCP-сокета или Получать JSON на конечной точке REST, например, входных коннекторов, данные выталкиваются на GeoEvent Server. Как только вход создан, он ожидает поступления данных. Источник данных генерирует данные и выталкивает каждое событие (или набор событий) на GeoEvent Server. Это особенность важна, потому что позволяет системному архитектору спроектировать систему, которая перехватывает входящие сообщения и направляет их в соответствии с выбранной стратегией.
Pull событий
При использовании Опроса внешнего веб-сайта на наличие XML или Опроса ArcGIS Server на наличие объектов, например, входных коннекторов, GeoEvent Server вытягивает (или опрашивает) данные событий. Периодически в источник данных отправляется запрос, и ответ включает одно или несколько событий, подлежащих обработке. При опросе данных нет возможности перехватить сообщения до их поступления на GeoEvent Server. В этом случае важно рассмотреть архитектурные стратегии для разделения данных и обработки дублирования событий.
Историческая зависимость события
На выбор высокодоступной архитектуры может повлиять тип исторической зависимости ваших данных событий.
Исторически независимые события
Большая часть обработки и анализа в режиме реального времени, выполняемых в GeoEvent Server, исторически независима. Каждое событие обрабатывается индивидуально, без какого-либо знания предыдущих событий. Каждое событие рассматривается как независимая единица и может быть обработано на любом экземпляре GeoEvent Server с идентичной конфигурацией. В таких ситуациях хорошо работают традиционные стратегии балансировки рабочей нагрузки событий на нескольких компьютерах.
Исторически зависимые события
Некоторые операции обработки и анализа в режиме реального времени, выполняемые в GeoEvent Server, требуют такой информации о предыдущих событиях, как вход и выход из пространственных операций. В обоих случаях требуется информация о местоположении предыдущего события, прежде чем можно будет определить точный результат для текущего события. Поскольку GeoEvent Server не предоставляет средств для обмена исторической информации о событиях между компьютерами, крайне важно, чтобы событие направлялось на компьютер, который ранее знал об этом событии (на основе его Track ID). Что касается архитектуры системы, то высокодоступная система должна быть спроектирована таким образом, чтобы события могли маршрутизироваться на основе их Track ID.
Дополнительная информация по разделению рабочей нагрузки
В дополнение к вышеприведенным стратегиям разделения событий между различными системами важно также рассмотреть природу самих данных. Часто различные команды, проекты или географическое расположение данных событий могут предоставить дополнительную информацию о том, как разделить данные. Например, разные команды или проекты могут иметь разные требования к обработке данных или, если данные географически расположены на большой площади, данные могут быть разделены на регионы.
Загрузка событий
При разделении потоков событий первое понятие, которое необходимо принять во внимание, - это загрузка событий. Загрузка потока событий определяется не только методом и скоростью, с которой данные поступают во входной коннектор, но и количеством событий, поступающих в течение определенного периода времени. Рекомендуется разбивать потоки событий на отдельные системы GeoEvent Server в зависимости от типа загрузки событий; равномерные загрузки против неравномерных загрузок. Во время обработки событий неравномерная загрузка может потребовать больше системных ресурсов, а при равномерной загрузке потока может идти конкуренция ресурсов. По этой причине рекомендуется разделить потоки событий равномерной и неравномерной загрузки на две разные системы.
Равномерная загрузки событий
При равномерной загрузке событий на вход GeoEvent Server события доставляются в постоянном, равномерном темпе. Равномерная загрузка событий обычно передается от систем, создающих данные с постоянной скоростью. Например:
- Поток событий системы автоматизированного определения местонахождения транспортного средства, в котором каждое транспортное средство сообщает о своем местоположении каждые 30 секунд.
- Сеть измерений течения, где каждый датчик измерений сообщает данные о течении каждые 60 минут.
При обработке равномерных загрузок событий ожидайте, что GeoEvent Server будет работать на постоянном уровне. В этом случае не ожидается пиковых значений загрузки процессора или памяти, поэтому система должна быть рассчитана на равномерную нагрузку.
Неравномерные загрузки событий
При неравномерной загрузке событий события поступают на вход GeoEvent Server в неравномерном темпе. Этот тип загрузки событий с колебаниями может привести к тому, что большое количество событий будет помещено в очередь сообщений входных данных, ожидающих обработки. Например:
- Система слежения за молниями, которая сообщает о ударах молнии по всему региону.
- Система проката скутеров, которая передает статус каждого взятого в прокат скутера.
При обработке неравномерных загрузок событий ожидайте, что системные ресурсы будут интенсивно использоваться при поступлении каждого всплеска набора событий. В течение этого времени загрузка центрального процессора может увеличиться до 100%, может временно увеличиться утилизация памяти , а темы Kafka (очереди сообщений) потребуют значительно больше дискового пространства (в 3-4 раза больше, чем по умолчанию). Во время этого процесса другие потоки событий в системе могут испытывать нехватку ресурсов, поскольку GeoEvent Server работает с большим количеством событий. В зависимости от ваших задач по обработке данных, система может быть спроектирована так, чтобы обрабатывать всплеск событий за достаточно короткое время до начала следующего всплеска (минимальные системные требования; оперативная обработка). Или системе могут быть выделены дополнительные ресурсы, позволяющие обрабатывать события с некоторой желаемой максимальной скоростью (максимальные системные требования; критическая обработка событий).