XII Международная студенческая научная конференция Студенческий научный форум - 2020

Введение

В настоящее время существуют различные технологии, предоставляющие инструментарий для реализации распределённых систем. Однако разработчики таких систем часто сталкиваются с ограничениями того или иного инструментария, поэтому вынуждены прибегнуть к разработке системы «с нуля». Такие системы должны удовлетворять заранее подготовленному перечню требований, в основном ориентированному на отказоустойчивость, распределённость, масштабируемость и высоконагруженность [1-3]. Чаще всего такие системы решают проблемы чтения, записи и хранения больших объёмов данных, где необходимо сохранять целостность данных и иметь возможность быстрого доступа к ним. Информационная система учёта и анализа коммунальных ресурсов ЖКХ (ИС УАКР), проектируемая в данной статье, будет включать в себя несколько распределённых модулей, расположенных на веб-сервере, и взаимодействующих между собой через протокол http. Система должна сочетать в себе все качества высоконагруженной и отказоустойчивой системы, позволяющей обрабатывать большие объёмы неструктурированных данных, позволяющих организовывать передачу сообщений в сетях IoT, применяемых в сфере ЖКХ.

Модель организации распределённой системы

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

Одной из самых популярных моделей является модель веб-сервисов. Веб-сервисы – это архитектура, обеспечивающая новый уровень распределённости доступа к данным в отличии от RPC-взаимодействия, которое использует устаревшие интерфейсы взаимодействия.

С помощью веб-сервисов разрабатываются распределённые и легко масштабируемые ИС уровня предприятия. Сочетая прямой доступ к программным приложениям и коммерческим документам, технологии взаимодействия следующего поколения сети обеспечат полностью автоматическое взаимодействие, что позволит обращаться непосредственно к программам. Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в информационной системе компании, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них [4].

Рис. 1 – Модель организации распределённой системы, основанной на удалённом вызове процедур

Для взаимодействия с веб-сервисами используют протоколы взаимодействия, наиболее популярными на сегодняшний день являются протоколы SOAP и REST. SOAP (Simple Object Access Protocol) – протокол обмена структурированными сообщениями в распределённой вычислительной среде. SOAP – это целое семейство протоколов и стандартов, откуда напрямую вытекает, что это достаточно тяжеловесный и сложный вариант с точки зрения машинной обработки. Протокол прежде всего основан на XML документах, передаваемых поверх HTTP, но возможна также передача и через другие, такие как email и JMS. SOAP веб-сервисы в основном основываются на Web Services Description Language или WSDL, который является XML соглашением для описания всех данных и сервисов, предоставляемых веб-службой. Клиент и сервер используют это соглашение как основу для обмена информацией и выполнения удалённого вызова процедур [5].

REST (REpresentational State Transfer) — это архитектура, т.е. принципы построения распределенных гипермедиа систем, того что другими словами называется World Wide Web, включая универсальные способы обработки и передачи состояний ресурсов по HTTP. REST на сегодняшний день практически вытеснил все остальные подходы, в том числе дизайн основанный на SOAP и WSDL. REST позволяет масштабировать взаимодействия компонентов системы (приложения), даёт общность интерфейсов, позволяет проводить независимое внедрение компонентов, где промежуточные компоненты снижают задержку и усиливают безопасность [6]. На рисунке 2 представлена модель REST-ориентированного сервиса.

Рис. 2 – Модель REST-ориентированного веб-сервиса

Процесс передачи, обработки и хранения данных

В настоящее время инфраструктура ЖКХ развивается достаточно быстрыми темпами. Главным образом стоит задача быстрой и качественной обработки поступающих данных, анализируя которые можно принимать решения в областях, затрагивающих деятельность ЖКХ: обслуживание клиентов, быстрое реагирование на нарушения, балансировка тарифов и т.д.

Основная цель статьи – проектирование системы, позволяющей автоматически принимать, предобрабатывать, хранить и считывать данные с счётчиков электроэнергии, газопотребления и водоснабжения. Современный многоэтажный дом насчитывает порядка тысячи квартир, где суммарно может находится порядка 4 тысяч счётчиков. Если рассматривать небольшой город с количеством многоэтажных домов около 100, то проектируемая система должна принимать и обрабатывать около 500 тысяч наборов данных по всем счётчикам. Масштаб потока данных говорит сам за себя – здесь необходимы вычислительные мощности кластера серверов.

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

На рисунке 3 представлен стандартный формат поступающего сообщения.

Рис. 3 – Структура поступающего сообщения

Серийный номер и номер счётчика чаще всего совпадают и отвечают за уникальность устройства, с которого поступает сообщение. Это важно учитывать при разработке систем больших данных, т.к. он отвечает за целостность данных. Поля адрес, изготовитель параметры идентификации и измеренная среда не несут никакой смысловой нагрузки, поэтому их обрабатывать и хранить не будет. Наиболее ценной будет информация, полученная из полей объём и состояние. Состояние хранит тело приходящего сообщения, в ней может содержаться главная информация, которую необходимо обработать и записать в хранилище. Также в поле объём записывается информация о показаниях счётчика и единице измерения.

Теперь необходимо определиться с процессом снятия показаний с счётчиков и доставки сообщений на сервер. В каждом доме стоит модуль (базовая станция, шлюз), собирающий информацию со всех счётчиков. Он также отвечает за конвертацию радиочасти из внутреннего интерфейса взаимодействия в Ethernet/ LTE. Отметим, что в настоящее время на рынке имеется технология из сферы IoT, реализующая взаимодействие счётчиков и базовой станции, собирающей информацию по ним (и не только), называемая LoRaWAN. Расшифровывается как Long Range, технология для высокозащищенной передачи небольших объемов информации, разработанная французской компанией Semtech. На рисунке 4 представлена простейшая схема взаимодействия датчиков различного рода с базовой станцией и серверами приложений [7].

На рисунке можно увидеть, что сами модули и шлюз обмениваются информацией по внутреннему протоколу LoRa RF, а коммуникации с внешним миром происходят посредством обобщённых протоколов (TCP/IP). Технология LoRa имеет ряд плюсов по сравнению с аналогами: высокая помехозащищённость (не будет утерян сигнал при большом количестве точек доступа Wi-Fi в доме), низкое энергопотребление (на одном микроаккумуляторе устройство работает несколько лет), малое время нахождения в эфире (устройство активировалось, отправило данные, получило подтверждение, дезактивировалось). Стоит также отметить, что устройства в данной сети активируются по расписанию, их нельзя вызвать оперативно. Однако, если всё-таки в будущем будет нужна активация устройства по требованию, то придётся отказаться от аккумуляторного питания.

Рис. 4 – Схема взаимодействия различных модулей с сервером приложений

Архитектура системы ИС УАКР

Опишем процесс организации получения, обработки, хранения и чтения данных. Изначально базовая станция в каждом доме должна собрать информацию со всех счётчиков, расположенных в квартирах. После этого она компонует все наборы данных в один большой набор. После этого сообщение отправляется на сервер, реализуя RPC-вызов веб-сервиса. Количество одновременных подключений равно количеству вычислительных узлов (или количеству домов в городе). На этом действия со стороны клиентов завершены. Всё это реализовано на стороне разработчиков сети LoRaWAN, адрес же сервера приложений можно сконфигурировать уже на базовой станции.

Теперь рассмотрим процесс со стороны сервера. Изначально, при поступлении сообщения на сервер, срабатывает сервис, который, видя сообщение, должен его сохранить в очереди сообщений и отправить подтверждение о том, что сообщение было принято. В итоге в очереди должно единовременно находиться количество сообщений, равное количеству домов в городе – это будет являться критерием получения сообщений. После этого происходит поочерёдное получение данных из очереди, их обработка, разбор содержимого и запись в хранилище.

Также необходимо учесть, что помимо вычислительных узлов в домах, будут и другие пользователи системы, которым необходим инструментарий по анализу хранящихся данных. Здесь можно прибегнуть к клиентскому веб-приложению, показывающему аналитику по конкретному дому, району или всему городу в целом. На рисунке 5 приведено графическое представление архитектуры всей системы.

На рисунке можно увидеть два вида направленных процессов: черные линии отвечают за обработку запроса от счётчиков, а синие линии отвечают за запросы от пользователей веб-системы. Конечной точкой является хранилище данных, прикладные программы отвечают за доступ к данным, их обработку и представление в удобочитаемом виде, веб-сервис отвечает за обработку запросов от пользователей и их перенаправление к внутренним службам. В итоге получается классическая многослойная архитектура, где к обработчику данных подключается дополнительный слой очереди сообщений. Для клиентов веб-системы реализована классическая трёхслойная архитектура. На рисунке 5 представлена общая архитектура системы.

Теперь опишем каждый из модулей по отдельности. Сама модель взаимодействия счётчиков и базовой станции описана выше. Разберём устройство очереди сообщений. Очередь основана на асинхронной передаче сообщений. Очереди привносят в систему отказоустойчивость, масштабирование и эластичность. Устойчивость заключается в том, что очереди сообщений позволяют отделить процессы друг от друга, так что если процесс, который обрабатывает сообщения из очереди падает, то сообщения могут быть добавлены в очередь на обработку позднее, когда система восстановится. Также очередь гарантирует доставку сообщения и порядок доставки. Помимо этого, использование очереди позволяет выдерживать пиковые нагрузки (она выступает как буфер системы). На рисунке 6 представлено обобщённое устройство очереди.

Рис. 5 – Общая схема ИС УАКР ЖКХ

Схема базы данных будет зависеть от формата поступающих сообщений. В общем виде будут присутствовать 6 таблиц: перечень квартир, домов, улиц, счётчиков, базовых станций и таблица, хранящая тело сообщения. Также можно разделить последнюю таблицу на таблицу с типом сообщения и таблицу с показателями.

Рис. 6 – Устройство очереди сообщений, применяемой в ИС УАКР

Веб-сервисы представляют из себя REST-сервисы, выполняющие функции обработки запроса и передачи управления внутренним модулям системы, выполняющие запрос к базе, обработку результата и т.д. На рисунке 7 представлено 5 обязательных сервисов, необходимых для работы системы.

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

Если говорить о гибкости сервисов, то стоит упомянуть такой вид архитектуры системы, как микросервисная архитектура, где под каждую микрозадачу создаётся отдельный сервис, выполняющий действие. Суть такого подхода в том, что система достаточно гибка к изменениям: присутствует возможность удалять, создавать, изменять сервисы, не останавливая работу системы и не принуждая пользователей системы что-либо менять на клиентской стороне. Так и в проектируемой системе: разработчики могут добавлять сервисы, потребляемые графическими клиентами, менять их, также присутствует возможность создания сервисов для интеграции с другими сервисами.

Рис. 7 – Минимальный набор сервисов, необходимых для работы ИС УАКР

Модуль прикладных программ может получиться достаточно объёмным, всё зависит от используемых инструментов и языка программирования. Для парсинга json-сообщения, взаимодействия с базой, агрегации, подсчёта показателей и аналитики существует масса готовых библиотек для таких языков как Java, C# и других. Поэтому можно обозначить только основные функции данного модуля, к таковым относятся:

парсинг сообщений

взаимодействие с хранилищем (ORM, ODBC, Driver)

наукоёмкиевычисления (ML.NET, Accord.NET, Spark MLlib, Apache Mahout)

параллелизация вычислений (TPL, Hadoop)

Если говорить о нагрузке на систему по мере роста количества подключаемых базовых станций, то стоит рассмотреть возможность подключения балансировщика нагрузок с созданием дубликатов серверов. Здесь необходимо учесть, что балансировщик может также обладать логикой и направлять на соответствующий сервер запросы от базовых станций из определённой части или района города – это позволит разделить нагрузки на сервера в равных долях, так, чтобы разгрузить слабые по технических характеристикам сервера и загрузить более мощные. В части вертикального масштабирования всегда есть возможность подключить несколько очередей сообщений, работающих на разных потоках безопасно, после чего поочерёдно обрабатывать каждое сообщение по методу FIFO [8]. На рисунке 8 изображена архитектура системы, где серверы реплицируемы, а балансировщик нагрузки распределяет нагрузку в зависимости от количества задач и запросов.

Рис. 8 – Балансировщик нагрузки и реплицируемые сервера

Выводы

В статье была спроектирована распределённая система, обрабатывающая большие данные в сфере ЖКХ, в том числе её архитектура и структура, сервисная модель взаимодействия IoT и сервера приложений, разработаны модели трансферных объектов. Все модули системы масштабируются, благодаря очередям сообщений повысилась отказоустойчивость. Нагрузку можно регулировать по мере увеличения количества домов в городе благодаря балансировщику нагрузок. Сервисы для сторонних пользователей подразумевают под собой дальнейшее развитие системы, добавление UI-клиента, предоставляющего учётно-аналитическую информацию по показаниям, либо интеграцию как стороннего сервиса в другие системы. В итоге была получена универсальная многослойная архитектура, позволяющая гибко добавлять модули и изменять уже имеющиеся, а также коммуницировать со сторонними сервисами и интегрироваться в уже имеющиеся системы.

Список литературы

Пилипчак П.Е., Воронова Л.И., Трунов А.С. Модель балансировки нагрузки для параллельного расчета системы n-частиц на гетерогенной кластерной системе // Современные наукоемкие технологии. 2014. № 5-2. С. 218-219.

Voronova L.I., Trunov A.S., Voronov V.I. The distributed calculators model for molecular-dynamic simulation of strong interaction systems // Международныйжурналэкспериментальногообразования. 2013. № 12. С. 82-88.

Trunov A.S., Voronova L.I., Voronov V.I., Airapetov D.P. Container Cluster Model Development for Legacy Applications Integration in Scientific Software System // 2018 IEEE International Conference "Quality Management, Transport and Information Security, Information Technologies" (IT&QM&IS)

Э. Таненбаум, М. ван Стеен. Распределенные системы. Принципы и парадигмы /— СПб.: Питер, 2003. — 877 с: ил.

Богданов А.В. , Корхов В.В. , Мареев В.В. , Станкова Е.Н. Архитектуры и топологии многопроцессорных вычислительных систем.

Чеглаков А.Л. Композиция web-сервисов на основе архитектуры REST. Международныйнаучныйжурнал «Инновационнаянаука» № 12-2/2016.

Wixted A.J., Kinnaird P., Larijani H., Tait A., Ahmadinia A., Strachan N. Evaluation of LoRa and LoRaWAN for wireless sensor networks; Proceedings of the 2016 IEEE SENSORS; Orlando, FL, USA. 30 October–3 November 2016; pp. 1–3.

Douglas K. Barry. Web Services, Service-Oriented Architectures, and Cloud Computing: The Savvy Manager's Guide (The Savvy Manager's Guides) 2nd Edition, Kindle Edition by Douglas K. Barry.