Разработка архитектуры информационного обеспечения информационной системы, выбор технологий и методов её реализации

3.3 Разработка архитектуры информационного обеспечения информационной системы, выбор технологий и методов её реализации

При разработке комплексных информационных систем, таких как системы электронного голосования, стало популярным применение микросервисной архитектуры. Понятие «микросервисная архитектура информационных систем» получило распространение в последние несколько лет, как описание способа проектирования информационной системы в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

Архитектурный стиль микросервисов — это подход, при котором единое приложение строится как набор небольших сервисов, каждый из которых работает в собственном процессе и коммуницирует с остальными, используя легковесные механизмы, как правило HTTP. Эти сервисы построены вокруг потребностей организации и развертываются независимо с использованием полностью автоматизированной среды. Существует абсолютный минимум централизованного управления этими сервисами. Сами по себе эти сервисы могут быть написаны на разных языках и использовать разные технологии хранения данных.

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

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

Так как сервисы могут отказать в любое время, очень важно иметь возможность быстро обнаружить неполадки и, если возможно, автоматически восстановить работоспособность сервиса. Микросервисная архитектура делает большой акцент на мониторинге приложения в режиме реального времени, проверке как технических элементов (например, как много запросов в секунду получает база данных), так и бизнес-метрик (например, как много регистраций и голосов в минуту получает приложение). Семантический мониторинг состояния системы электронного голосования может предоставить систему раннего предупреждения проблемных ситуаций, позволяя команде разработки подключиться к исследованию проблемы на самых ранних стадиях.

Архитектура микросервисов использует библиотеки, но их основной способ разбиения приложения — путем деления его на сервисы. Главная причина использования сервисов вместо библиотек — это независимое развертывание. Если разрабатывается приложение, состоящее из нескольких библиотек, работающих в одном процессе, любое изменение в этих библиотеках приводит к переразвертыванию всего приложения. Но если приложение разбито на несколько сервисов, то изменения, затрагивающие какой-либо из них, потребуют переразвертывания только изменившегося сервиса. Конечно, какие-то изменения будут затрагивать интерфейсы, что, в свою очередь, потребует некоторой координации между разными сервисами, но цель хорошей архитектуры микросервисов – минимизировать необходимость в такой координации путем установки правильных границ между микросервисами, а также механизма эволюции контрактов сервисов.

Управление данными серверами может выполняться с помощью платформы Docker [136]. Docker представляет собой специализированное программное обеспечение для автоматизации развёртывания и управления приложениями в среде виртуализации на уровне операционной системы.

Основываясь на представленной архитектуре системы голосования, выделим элементы архитектуры информационного обеспечения и их функционал в виде ключевых модулей: модули сбора информации об избирательном событии и списках избирателей, голосах; модуль хранения данных; модуль анализа данных; модуль визуализации.

Модуль сбора данных

Источником информации для модуля сбора данных, в зависимости от выполняемого функционала и типа пользователя, могут выступать клиентские персональные компьютеры, планшеты, смартфоны, терминалы для голосования и электронные урны. Модуль сбора данных отвечает за непосредственный сбор данных от таких источников, а также проведение первоначальной обработки данных, приведение данных к стандартному виду внутренней экосистемы платформы электронного голосования. Алгоритм его работы проиллюстрирован на рисунке 3.9.

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

Если микросервис одного из модулей перестает отвечать на запросы в результате аварии, его клиенты должны быть мгновенно перенаправлены на резервный. Для управления потоком запросов часто используют так называемые очереди сообщений.

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

Несмотря на свое сходство с Hadoop, Spark предназначен для решения определенных типов задач в вычислительном кластере, в котором рабочий набор данных повторно используется в параллельных операциях. Чтобы оптимизировать этот тип задач, Spark представляет концепцию кластерных вычислений в памяти, где наборы данных могут временно храниться в памяти для уменьшения времени доступа. Таким образом, Spark поддерживает идею стабильного распределенного набора данных (устойчивые распределенные наборы данных RDD). RDD представляет собой набор неизменных объектов, распределенных по нескольким узлам. Эти коллекции стабильны, потому что, если они потеряют часть набора данных, они могут быть восстановлены. Процесс восстановления части набора данных основывается на механизме отказоустойчивости, который поддерживает родословную (или информацию, которая позволяет восстановить часть набора данных, используя процесс, который приводит к извлечению данных). RDD - объект Scala и может быть создан из файла; в виде параллельного среза (распределенного вдоль узлов); как конвертировать другой RDD; и, наконец, путем изменения стойкости, существующего RDD, такого как запрос на кэширование в памяти.

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

С точки зрения объектно-ориентированного программирования каждое значение представляет собой объект. Аналогично, с точки зрения функционального программирования каждая функция является значением. В том числе, Scala статически типизируется с помощью выразительной и безопасной системы. Scala функционирует в различных Web частях приложений Twitter, LinkedIn и Foursquare, а также является объектом интересов для EDF Trading и др. финансовых учреждений.