Разработка интеграционной шины предприятия для взаимодействия сервисов ІT-инфраструктуры Московского института электроники и математики

Размещено на http://www.allbest.ru/



Аннотация

В данной работе приведены основные принципы проектирования и разработки интеграционной шины предприятия. Исследованы разнообразные аспекты и детали её внедрения в IT-инфраструктуру МИЭМ. Отдельное внимание в разработке уделено обеспечению высокого уровня таких важных характеристик распределенной системы, как доступность, отказоустойчивость, масштабируемость и безопасность. Рассмотрен вопрос тестирования и документирования разработанного функционала. В качестве наглядного практического примера был произведен рефакторинг архитектуры и перевод части существующей системы на межсервисное взаимодействие через интеграционную шину. В результате работы была достигнута эффективная интеграция пары конечных микросервисов, для односторонней синхронизации участников Google-групп и каналов Zulip в домене института.

Данная работа состоит из оглавления, введения, 3 главы, заключения и приложений. В работе содержится 2 таблицы, 19 иллюстраций, список литературы и 1 приложение. Объем работы составляет 48 страниц без приложений.

This paper describes basic principles of design and development of an enterprise service bus. The various aspects and details of its implementation in the MIEM IT infrastructure are investigated. Special attention in the development is given to ensuring a high level of such important characteristics of a distributed system as availability, fault tolerance, scalability and security. The issue of testing and documenting the developed functionality is considered. As a clear practical example, the architecture was refactored and part of the existing system was transferred to interservice interaction via the integration bus. As a result of the work, effective integration of a pair of end microservices was achieved, for one-way synchronization of members of Google groups and Zulip channels in the institute's domain.

This work consists of a table of contents, an introduction, 3 chapters, a conclusion and an appendix. The work contains 2 tables, 19 images, literature list and 1 appendix. The total volume of this work is 48 pages without appendices.



Содержание

Введение

1. Анализ предметной области

1.1 Анализ проблем текущей схемы взаимодействия сервисов МИЭМ

1.2 Понятие интеграционной шины предприятия

1.3 Создание интеграционной шины и окружающей программной инфраструктуры

Заключение

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

Приложение



Введение

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

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

Объектом исследования является IT-инфраструктура МИЭМ как частный случай сервис-ориентированной архитектуры.

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

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

Для достижения цели необходимо решить следующие задачи:

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

спроектировать архитектуру интеграционной шины;

создать правила интеграции приложений через шину;

программно реализовать прототип системы ПО для осуществления синхронизации через интеграционную шину участников Google-групп и каналов в Zulip из домена miem.hse.ru;

провести тестирование разработок.

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

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



1. Анализ предметной области

1.1 Анализ проблем текущей схемы взаимодействия сервисов МИЭМ

IT-инфраструктура МИЭМ состоит из большого количества сервисов, логически связанных между собой, среди которых: Trello, Zulip, Google и другие. Взаимодействие двух произвольных сервисов представлено работой предварительно созданного программного скрипта, выполняющего некоторую логику. Текущая модель интеграции сервисов известна как «point-to-point» или «application-to-application» и подразумевает прямое и непосредственное взаимодействие с целевым сервисом с помощью вызова некоторого API-метода и выполнения соответствующего REST-запроса. Являясь самой простой в реализации, данная схема становится мало пригодной при усложнении программной инфраструктуры из-за трудоемкости в поддержке а также возрастающей сложности объема работ по внедрению нового элемента взаимодействия. Уже сейчас при практической реализации очередного программного компонента все недостатки, связанные с выбранным изначально архитектурным решением становятся очевидны и также оказывают негативное влияние на работу с системой, излишне усложняя ее эксплуатацию и развитие. Тем самым описанная выше модель взаимодействия оказывается неспособной обеспечить некоторые важные характеристики, которыми должна обладать система для производительной и качественной работы.

Концептуальная схема IT-инфраструктуры МИЭМ приведена на рис. 1.

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

Рис. 1. Схема взаимодействия приложений и сервисов в рамках IT-инфраструктуры МИЭМ

1.2 Понятие интеграционной шины предприятия

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

Характеристики распределенной системы

Книга “Distributed Systems - Concepts and Design” [1] исследует множество важных аспектов построения распределенных систем, а также перечисляет некоторые важные характеристики, должная реализация которых необходима для эффективного функционирования системы. Наиболее важные среди них для проектируемой инфраструктуры - это доступность, отказоустойчивость, масштабируемость и безопасность.

Доступность

Высокая доступность системы выражается своевременной реакцией системы на действия и запросы пользователя.

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

Отказоустойчивость

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

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

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

Масштабируемость

Понятие масштабируемости распределенной системы связано с её способностью справляться с увеличением рабочей нагрузки (увеличивать свою производительность) при добавлении ресурсов. Как правило, увеличение производительности системы (или отдельного компонента, входящего в её состав) достигается посредством вертикального или горизонтального масштабирования вычислительных ресурсов.

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

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

В то время, как вертикальное масштабирование распределенной системы IT-инфраструктуры МИЭМ может быть совершено при необходимости без дополнительных приготовлений, горизонтальное масштабирование в текущих реалиях является неэффективным, из-за межсервисных взаимодействий типа “point-to-point”, предполагающих высокую связность компонентов системы. Мера связности программных модулей определяется количеством информации которой располагает один модуль о природе другого.

Безусловно, прямое и непосредственное взаимодействие двух логических элементов системы подразумевает наличие информации о субъектах взаимодействия внутри этих субъектов. Функционал данных программных элементов не декомпозирован в соответствии с принципом единственной ответственности [2], поэтому точечное горизонтальное масштабирование нужного функционала неизбежно влечет за собой масштабирование связанного функционала, что, как правило, нежелательно, так как налагает на сервер дополнительные нагрузки.

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

Безопасность

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

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



Рис. 2. Схема архитектуры интеграционного потока с использованием балансировщика нагрузки

Безопасность системы относительно внешнего несанкционированного вмешательства достигается посредством использования конфиденциальных учетных данных при подключению к брокеру сообщений: пары логин и пароль (использовано в работе) или SSL-сертификатов.

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

Анализ существующих технологических решений и обоснование выбора программных средств

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

Выбор технологий для разработки основы интеграционной шины

В качестве основы для построения интеграционной шины как правило выступает брокер сообщений - программное обеспечение служащее связующим звеном при основанном на обмене сообщениями взаимодействии двух систем. Крайне удобным для использования при реализации интеграционной шины является протокол «Advanced Message Queuing Protocol» (AMQP) [3], смысл которого заключается в возможности произвольных, независимых друг от друга компонентов единой системы или отдельных приложений обмена сообщениями через AMQP-брокер, осуществляющий маршрутизацию входящего трафика, подписку на нужные типы сообщений и прочее. Основными понятиями данного протокола являются:

сообщение (message) - единица передаваемых данных;

очередь (queue) - объект, хранящий поступающие сообщения до момента их вычитки системой - потребителем;

точка обмена (exchange) - объект, осуществляющий маршрутизацию (распределение по очередям в зависимости от заданных условий) входящих сообщений.

В качестве реализации данного протокола для разработки основания интеграционной шины был выбран брокер сообщений RabbitMQ, который имеет следующие преимущества:

программное обеспечение с открытым исходным кодом (open source);

возможность горизонтального масштабирования для построения кластерных решений;

наличие библиотек для работы с брокером сообщений на многих языках программирования;

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

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

Выбор программных средств для реализации системы - отправителя и системы - приемника

Идея, лежащая в основе использования брокера сообщений, как основы интеграционной шины предприятия, предполагает низкую связность программных модулей взаимодействующих систем отправителей и получателей сообщений, поэтому разработка обеих сторон интеграционного взаимодействия может вестись параллельно, при согласовании лишь непосредственно передаваемых в сообщениях данных. Таким образом, выбор программных средств, таких, как язык программирования, фреймворк, используемые библиотеки и т.д. полностью остается за разработчиком данного модуля. Тем не менее, для разработки программных модулей при реализации синхронизации участников Google-групп и каналов Zulip был выбран язык Python по следующим причинам:

популярность и синтаксическая простота языка, что позволит использовать разработанные в рамках ВКР программы как ориентир или шаблон для будущих разработок;

поддержка асинхронности, что позволит поддерживать эффективную работу при больших нагрузках;

большое количество библиотек для удовлетворения разнообразных потребностей по разработке, в том числе, для работы с реализациями протокола AMQP. Данный факт позволит быстро разрабатывать прототипы программных модулей.

Вспомогательные инструменты для разработки

Среда разработки

Одним из важнейших вспомогательных инструментов в разработке приложений является среда разработки. Концептуально инструменты для разработки делятся на 2 типа:

текстовые редакторы;

интегрированные среды разработки (integrated development environment, IDE). программный интеграционный шина брокер

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

Наиболее известны следующие текстовые редакторы:

Nodepad++;

Visual Studio Code;

Atom;

Vim;

Sublime Text.

Среди интегрированных сред разработки для языка Python большое распространение имеют:

PyCharm;

Eric;

Pyzo;

Spider;

PyDev.

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

интегрированная возможность модульного тестирования кода;

автоматическая инспекция кода;

интеграция с системами контроля версий, такими, как Git, Mercurial, Subversion;

инструменты рефакторинга кода;

большое количество удобных инструментов для навигации по проекту;

множество плагинов для расширения функционала среды разработки;

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

Система контроля версий

Важным инструментом для более надежного за разработкой является система управления версиями (Version Control System, VCS) - программное обеспечение для облегчения работы с изменяющейся информацией. Система контроля версий позволяет пользователю хранить несколько версий одного и того же файла или документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое. Наиболее известны следующие системы управления версиями:

Git;

Subversion;

Mercurial.

При разработке программного обеспечения в рамках ВКР мной использовалась система управления версиями Git, которая в целом является более гибким инструментом по сравнению с другими проектами, решающими аналогичную задачу. Более того, следствием того, что Git является децентрализованной системой контроля версий, каждый разработчик имеет свою локальную копию репозитория, работа над которой возможна и при отсутствии интернет-соединения. По умолчанию взаимодействие пользователя с Git происходит через интерфейс командной строки, тем не менее, для Git существует множество визуальных графических клиентов, например:

GitHub Desktop;

TortoiseGit;

GitKraken;

CodeReview;

SourceTree.

В рамках работы над ВКР для работы с Git использовался интерфейс командной строки.

Для более удобного управления проектами а также автоматизации процессов интеграции и доставки приложений использовалась система управления репозиториями GitLab (рис. 3). Выбор данной технологии обусловлен наличием обширного DevOps - функционала, высокой доступностью сервиса а также возможностью к масштабированию, критически важной при высоких нагрузках.

Рис. 3. Интерфейс сервиса GitLab с репозиториями кода, созданными в рамках ВКР

1.3 Создание интеграционной шины и окружающей программной инфраструктуры

Описание общей архитектуры цифровой среды с учетом шины

IT-инфраструктура МИЭМ в части разработанного механизма синхронизации участников Google-групп и каналов Zulip понесла коренные изменения посредством интеграции шины в ее состав. В первую очередь, теперь соответствующий сегмент цифровой среды представляет совокупность отдельных, не связанных друг с другом программных модулей с четким разделением области действия по взаимодействию с внешними сервисами. Реализация принципа единственной ответственности для составляющих элементов архитектуры описываемой системы является залогом простоты в их разработке, поддержке и сопровождении, а также возможности их горизонтального масштабирования. Каждый из работающих программных модулей по существу выполняет два основных действия:

Мониторинг состояния собственного, приписанного ему сервиса (например, периодический просмотр участников групп Google на предмет выявления недавно добавленных пользователей) и отправка сообщения в шину при появления нового события;

Изменения состояния собственного сервиса посредством вызова API-метода при получения нового сообщения из шины (например, приглашение новых участников в каналы Zulip при обнаружении недавно добавленных пользователей в группах Google, чем достигается синхронизация содержания аналогичных ресурсов двух логически связанных сервисов).

Общий вид разработанной архитектуры интеграции для двух программных модулей через шину имеет вид, приведенный на рис. 4.

Рис. 4. Архитектура интеграционного взаимодействия двух произвольных программных модулей через шину

Предложенная архитектура имеет следующие составные части:

«Service A» и «Service B» - сервисы, интеграция которых является целью разработки данной системы (например, Google и Zulip);

«Sidecar A» и «Sidecar B» - программные модули, представляющие собой веб-приложения, приписанные к соответствующим сервисам. Каждая из данных программ взаимодействует с программным интерфейсом (API) лишь собственного сервиса.

«ESB» (Enterprise Service Bus) - сегмент интеграционной шины, участвующий в рассматриваемой интеграции. Включает в себя объекты: «Exchange A», «Exchange B», «Queue A» и «Queue B».

«Exchange A» и «Exchange B» - элементы интеграционной шины, входные точки для сообщений, исходящих из соответствующих программных модулей.

«Queue A» и «Queue B» - элементы интеграционной шины, очереди для сообщений, входящих в соответствующие программные модули. Подписка на Exchange происходит по условиям: «Condition X» и «Condition Y» - информации в заголовках сообщений, представляющей набор характеристик сообщения, так то: наименование системы-источника, тип произошедшего события, прочие параметры.

Описанная выше архитектура является оптимальной для организации интеграции несвязанных друг с другом программных модулей, так как, с одной стороны, позволяет минимизировать количество объектов MQ в интеграционной шине, а с другой - позволяет реализовать большинство стандартных стратегий “публикации - подписки” - одного из наиболее популярных шаблонов на брокере сообщений [4]. Подписка очередь не эксчендж по условию позволяет значительно снизить излишний трафик в шине, повышая процент её полезной нагрузки, так как в каждую конкретную очередь помещаются сообщения, интересующие систему - приемник.

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

Реализация интеграционной шины

Организация брокеров сообщений в кластер

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

скачки напряжения в электросети

внезапное отключение питания

конкуренция за ресурсы различных системных или пользовательских процессов операционной системы

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

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

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

Рис. 5. Графический интерфейс администрирования кластера RabbitMQ, состоящего из трех узлов

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

Также, для сохранения созданной конфигурации серверов брокеров сообщений все объекты RabbitMQ имеют настройку «durable» равной значению «True».

Создание общих правил подписок и публикации сообщений в интеграционную шину

Для наиболее эффективной работы программной инфраструктуры были разработаны следующие правила подписок и публикации сообщений в интеграционную шину:

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

Названия заголовков записываются латиницей.

Названия заголовков задаются заглавными буквами. Пример: «SOURCE=GOOGLE»; «EVENT=USER_CREATED».

Универсальные заголовки сообщений должны именоваться одинаково во всех разрабатываемых программных модулях. Например: «SOURCE» - «система-источник события»; «EVENT» - «тип события».

Создание прототипа системы ПО для осуществления синхронизации через интеграционную шину участников Google-групп и каналов Zulip из домена “miem.hse.ru”

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

Определение заголовков сообщений

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

Таблица 1 Заголовки сообщений интеграции Google-групп и Zulip-каналов

Заголовок	Комментарий	Примеры значений	Значение фиксировано
SOURCE	Сервис - источник события	GOOGLE	Да
EVENT	Описание события изменения групп	GROUP_USER_ADDED GROUP_USER_DELETED	Да
GROUP	Название группы Google	BIV162	Нет

Архитектура сегмента системы обеспечения интеграции сервисов

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

Программная реализация интеграционного потока

Понятие интеграционного потока предполагает завершенную функционирующую цепь из программных модулей, осуществляющих интеграцию двух конечных сторонних сервисов. Интеграционный поток, реализованный в рамках выполнения ВКР осуществляет интеграцию сервисов Google и Zulip, выполняя одностороннюю синхронизацию групп Google с каналами Zulip.

Далее будут рассмотрены детали и нюансы реализации вышеописанного интеграционного потока

Модуль Google

Общие сведения

Рис. 6. Архитектура интеграционного взаимодействия программных модулей Google и Zulip через шину

Первичным элементом потока синхронизации Google-групп и каналов Zulip является программный модуль (сайдкар) Google, главным назначением которого является периодический мониторинг групп, принадлежащих к заданному домену, сохранение их состава на локальный диск, и реагировании на изменение в составах групп как в сторону увеличения числа их членов (при добавлении новых участников), так и в сторону его уменьшения (при исключении участников из состава группы). Домен, в котором находятся группы, которые требуется синхронизировать - miem.hse.ru. Однако он является лишь частным случаем использования интеграционного потока, так как данный параметр может быть изменен в файле конфигурации приложения Google в зависимости от конкретных нужд по использованию интеграционного потока. Группы в данном домене как правило создаются и используются в рамках работ по образовательной или проектной деятельности студентами и преподавательским составом МИЭМ НИУ ВШЭ.

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

Алгоритм работы приложения

Работа приложения Google сводится к циклическому выполнению следующего высокоуровнего алгоритма, целью которого является выявления изменения составов Google-групп и отправка сообщения в брокер сообщений RabbitMQ с содержанием, соответствующим характеру произошедших изменений:

1. Получить список групп для заданного домена от Google API.

2. Для каждой группы:

2.1. Получить список актуальных участников от Google API.

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

2.3. При обнаружении несоответствия списков выявить добавленных/исключенных из группы пользователей.

2.4. Актуализировать содержимое файла состава группы при его наличии, заменив его на список полученный на данной итерации цикла синхронизации. При отсутствии файла создать файл и заполнить его аналогичным образом.

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

2.6. Отправить сообщение в брокер сообщений.

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

Структура проекта

Проект Google представляет состоит из двух условных модулей (рис. 7):

“src” - в котором находится ряд программных файлов, исполняющих основную логику работы модуля, файлы конфигурации приложения и прочие файлы, необходимые для работы программы

“test” - в котором находится ряд программных файлов, выполняющих unit-тестирование функционала модуля “src”, состоящий из файлов с кодом, выполняющих основную логику тестирования, а также соответствующего файла конфигурации.

Рис. 7. Структура проекта Google

Модуль “src”

Далее рассмотрены основные классы модуля “src”.

GoogleManager (определен в файле “src/google_manager.py”) - класс, содержащий в себе логику взаимодействия с публичным программным интерфейсом приложения (API) Google. Функционал данного класса охватывает такие возможности, как:

Установление соединение в сервисом Google (происходит при создании экземпляра класса посредством использования файлов ”src/credentials.json”, содержащий учетные данные зарегистрированного в Google проекта, ассоциированного с приложением “esb-google-groups”)

Получение списка групп для заданного домена и информации по ним (интерфейс функции: “get_groups_for_domain(domain)”, где “domain” - название домена типа “строка” (str); возвращаемое значение: список из структур информации по группам). Данная функция выполняет корректный вызов API Google, после чего возвращает список групп, преобразовав соответствующим образом результат выполнения запроса.

Получение списка пользователей для конкретной группы по её уникальному идентификатору (интерфейс функции: “get_members_for_group(group)”, где “group” - уникальный идентификатор группы типа “строка” (str); возвращаемое значение: список из структур информации по пользователям). Данная функция выполняет корректный вызов API Google, после чего возвращает список пользователей заданной группы, преобразовав соответствующим образом результат выполнения запроса.

RmqManager (определен в файле “src/rmq_manager.py”) - класс, содержащий в себе логику взаимодействия с публичным программным интерфейсом приложения (API) сервера RabbitMQ. Функционал данного класса охватывает такие возможности, как:

Установление соединение в сервером RabbitMQ (интерфейс функции: “get_connection()”; возвращаемое значение: объект соединения с сервером RabbitMQ) на основании конфигурации приложения, определенного в текстовом файле “src/config.txt”.

Подготовка среды RabbitMQ для корректной работы приложения (“интерфейс функции: prepare_env(); возвращаемое значение отсутствует”). Данный пункт в рамках описываемого сценария работы создает эксчендж, куда приложение публикует сообщения при изменении состава групп Google (рис. 8).

Отправка сообщения об изменении состава группы (интерфейс функции: “send_message(group_name, members)”, где “group_name” - название группы с изменившимся составом типа строка (str); “members” - список из адресов электронных почт добавленных/удаленных пользователей для данной группы типа список строк (list<str>); возвращаемое значение отсутствует). В этой функции создается сообщение, в тело которого записывается список электронных почт пользователей в формате “email1;email2;email3;...”. Также, проставляются заголовки: “GROUP” - названием группы, “EVENT” - одним из строковых значений “GROUP_USER_ADDED” или “GROUP_USER_DELETED” в зависимости от характера изменений состава указанной группы. В случае успешной отправки сообщения в консоль приложения выводится соответствующее информационное сообщение.

SyncManager (определен в файле “src/sync_manager.py”) - класс, содержащий в себе логику синхронизации участников групп со стороны сервиса Google, в том числе, выявления добавленных и удаленных пользователей групп и использующий для данной цели экземпляры рассмотренных выше классов. Функционал данного класса охватывает такие возможности, как:



Рис. 8. Объекты RabbitMQ: страница “Exchanges”

Получение списка адресов электронной почты участников группы, недавно добавленных или исключенных из неё (интерфейс функции: “get_new_members(group_name, members_emails), где “group_name” - название группы типа строка (str), “members_emails” - список адресов электронной почты актуальных участников данной группы типа список строк (list<str>); возвращаемое значение: список адресов электронной почты новых/удаленных пользователей группы типа список строк (list<str>)). Данная функция осуществляет сопоставление полученного через API Google списка участников данной группы со списком участников данной группы из файла, сформированного на предыдущей итерации цикла синхронизации.

Часть синхронизации групп на стороне сервиса Google (интерфейс функции: “sync_groups()”; возвращаемое значение отсутствует). Содержит в себе полный функционал по получении актуального списка групп заданного домена и их участников, актуализации файлов составов групп на локальном диске, формировании сообщений об изменениях в составах групп. Данный функционал повторяется на каждой итерации главного цикла.

Файл конфигурации приложения “config.txt” содержит ряд опций, использующихся приложением в процессе работы. Файл содержит ряд логически разделенных секций со значениями конфигурации в формате “[название секции]” и “название опции=значение опции”. Пример файла конфигурации приведен на рис. 9.

Рис. 9. Файл конфигурации модуля “src”

Модуль “test”

Предназначение модуля “test” - это модульное тестирование основного функционала модуля “src”.

Далее рассмотрены основные классы модуля “test”.

GoogleManagerMock (описан в файле “test/google_manager_mock.py”) - класс, представляющий из себя заглушку для класса GoogleManager из модуля “src”. Задача данного класса - моделировать сетевое взаимодействие с Google API. Реализует программный интерфейс всех функций оригинального класса, однако, для нужд тестирования возвращает всегда фиксированное значение.

RmqManagerMock (описан в файле “test/rmq_manager_mock.py”) - класс, представляющий из себя заглушку для класса RmqManager из модуля “src”. Задача данного класса - моделировать сетевое взаимодействие с брокером сообщений RabbitMQ. Реализует программный интерфейс всех функций оригинального класса, однако, для нужд тестирования не выполняет никаких функциональных действий.

Модуль Zulip

Общие сведения

Второй логической составляющей синхронизационного потока является приложение (сайдкар) по работе с сервисом Zulip. Задачей данного приложения является реагирование на входящие в очередь сообщения по изменениям в составам групп и отражать их на соответствующие каналы Zulip посредством вызова методов публичного API сервиса.

Структура проекта

Проект Zulip состоит из нескольких файлов, логически связанных между собой (рис. 10):

Рис. 10. Структура проекта Zulip

Далее рассмотрены основные классы проекта.

ZulipManager (определен в файле “zulip_manager.py”) - класс, содержащий в себе логику взаимодействия с публичным программным интерфейсом приложения (API) Zulip. Класс решает следующие задачи:

Установление соединение в сервисом Zulip (происходит при создании экземпляра класса на основании учетных данных из файла ”zuliprc.txt”). Информация, содержащаяся в данном файле позволяет выполнять операции от лица специального, заранее созданного пользователя Zulip, который обладает необходимыми правами (правами администратора).

Создать новый канал Zulip (интерфейс функции: “create_stream(name, description, member_emails, invite_only)”, где “name” - название создаваемого канала, “description” - описание канала, “member_emails” - список адресов электронной почты начальных участников канала, “invite_only” - отослать приглашение вступления в канал или сразу добавить в канал, без приглашения; возвращаемое значение: статус выполнения операции (успешно/неуспешно)).

Добавить пользователей в существующий канал (интерфейс функции: “add_subscriptions(name, users)”, где “name” - название целевого канала, “users” - список адресов электронной почты новых участников канала; возвращаемое значение: статус выполнения операции (успешно/неуспешно)).

Исключить пользователей из канала (интерфейс функции: “remove_subscriptions(name, users)”, где “name” - название целевого канала, “users” - список адресов электронной почты исключаемых участников канала; возвращаемое значение: статус выполнения операции (успешно/неуспешно)).

Получить список всех каналов (интерфейс функции: “get_all_streams()”; возвращаемое значение: список структур данных по всем каналам).

Получить список всех пользователей (интерфейс функции: “get_all_users()”; возвращаемое значение: список структур данных по всем пользователям).

RmqManager (определен в файле “rmq_manager.py”) - класс, содержащий в себе логику взаимодействия с публичным программным интерфейсом приложения (API) сервера RabbitMQ. Функционал данного класса охватывает такие возможности, как:

Установление соединение в сервером RabbitMQ (интерфейс функции: “get_connection()”; возвращаемое значение: объект соединения с сервером RabbitMQ) на основании конфигурации приложения, определенного в текстовом файле “config.txt”.

Подготовка среды RabbitMQ для корректной работы приложения (“интерфейс функции: prepare_env(); возвращаемое значение отсутствует”). Данный пункт в рамках описываемого сценария работы создает очередь (рис. 11), подписывается на сообщения по группам исходящие из эксченджа сайдкара Google.

Реакция на пришедшее сообщение (функция “callback” вызывается неявно при обнаружении в очереди нового сообщения). Работа данной функции сводится к взаимодействии с сервисом API Zulip к контексте добавления новых пользователей в каналы или исключения пользователей из каналов в зависимости от содержания обрабатываемого сообщения.

Рис. 11. Объекты RabbitMQ: страница «Queues»

Использование балансировщика нагрузки

Для обеспечения лучшей отказоустойчивости системы, балансировки нагрузки по сообщениям за единицу времени и предоставления пользователям унифицированного интерфейса обращения к интеграционной шине была использован программный продукт HAProxy (рис. 12), выступающий в роли посредника между системой - клиентом и самой интеграционной шиной предприятия. Данный программный модуль, будучи размещенным на отдельной физической машине, не зависит от серверов интеграционной шины, чем достигается его высокая доступность для пользователей. Главная концепция использования данной технологии заключается в осуществлении маршрутизации входящих сообщений по узлам RabbitMQ - кластера, при этом являясь пользователю в виде единой точки входа в интеграционную шину.

Рис. 12. Графический интерфейс администрирования HAProxy, при соединении с трехузловым кластером RabbitMQ

Создание механизма CI/CD для модулей, интегрируемых в шину

Механизм CI/CD (Continuous integration/Continuous delivery) широко используется в разработке программного обеспечения любого типа и выражается в автоматизированной проверке корректности интеграции реализованных программных модулей при их включении в единую систему а также успешность развертывания программных модулей на специально выделенных средах.

Разработанный мной механизм реализуется посредством выполнения задачи в GitLab, состоящей из двух этапов:

«Build», где проверяется код на возможность сборки архива, в последствии разворачиваемого на сервере;

«Deploy», где собранный архив по сети передается в хранилище программных артефактов, из которого далее может быть установлен на любой из узлов программной инфраструктуры.

Тестирование

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

Тесты классифицируются по ряду признаков:

по объекту тестирования;

по знанию внутреннего строения системы;

по степени автоматизации;

по степени изолированности.

В следующих разделах приведены три типа тестирования разработанного интеграционного потока.

Модульное тестирование

Общая информация

По определению модульное тестирование (unit-тестирование) - это процесс в программировании, позволяющий проверить корректность работы отдельных модулей исходного кода программы (например, функций).

Используемый подход состоит в том, чтобы писать unit-тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже протестированных местах программы, а также облегчает обнаружение и устранение таких ошибок. Для оценки степени полноты отладки программы часто вводится показатель процента покрытия unit-тестами функционала программы. В идеальном случае данная характеристика равна 100%.

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

Сценарий теста

Разработанный unit-тест определен в файле “test.py”. Тесту подлежит функция “sync_groups()”, определенная в классе SyncManager. В тесте используется экземпляр оригинального класса SyncManager, но вместо компонентов, выполняющих взаимодействие с Google API и RabbitMQ используется заглушки: GoogleManagerMock и RmqManagerMock. Функционально тест проверяет корректность создания и заполнения файла с составом группы на основании которого далее формируется сообщение для брокера. Код теста приведен на рис. 13.

Рис. 13. Код unit-теста

Результат теста положительный (рис. 14).

Рис. 14. Результат запуска unit-теста



Тестирование отказоустойчивости

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

Кластер RabbitMQ в моделируемом примере состоит из трёх аналогичных узлов (рис. Х). Каждый из узлов системы представляет собой автономный физический сервер, на котором установлено всё необходимое программное обеспечение. В целях обеспечения отказоустойчивости было принято решение использовать балансировщик нагрузки HAProxy, размещенный на отдельном сервере, и непосредственно через который происходят все взаимодействия приложений (сайдкаров) с кластером RabbitMQ. Выбор узла кластера производится балансировщиком в автоматическом режиме: по умолчанию всегда выбирается “мастер-узел” - узел кластера, специально определенный на момент его создания.

Для симуляции работы RabbitMQ в распределенном контексте было использовано несколько параллельно запущенных виртуальных образов операционной системы Ubuntu Server 18.04 с предустановленным программным обеспечением для реализации функционирования автономного сервера брокера сообщений. Виртуализация достигалась посредством использования программного продукта VirtualBox 5. При безотказной работе всех узлов кластера каждая из ячеек таблицы “Nodes” в графическом интерфейсе администратора RabbitMQ подсвечена зеленым цветом (рис. 15).



Рис. 15. Интерфейс администратора RabbitMQ при трех работающих узлах, объединенных в кластер

На данном этапе мастер-узлом является “rabbitmq1” (первая строка) таблицы. Вышеописанный сценарий синхронизации групп Google и каналов Zulip выполняется корректно.

Теперь, для симуляции отказа мастер-узла кластера работа узла “rabbitmq1” была завершена стандартным способом.

В конфигурации кластера автоматически произошли изменения: мастер-узлом был назначен узел “rabbitmq3”. Изменения также отражаются в интерфейсе (рис. 16).

Рис. 16. Интерфейс администратора RabbitMQ при одном узле, вышедшем из строя в в трехузловом кластере

Конфигурация выключенного узла были скопированы на новый мастер-узел, поэтому работа по синхронизации групп Google и каналов Zulip продолжается в штатном режиме.

Далее, был выключен узел “rabbitmq3”. Аналогично предыдущему шагу объекты RabbitMQ и зависимости между ними были скопированы на единственный оставшейся активным сервер. Работа сайдкаров продолжается без изменений. Изменения отражаются в интерфейсах (рис. 17-18).

Рис. 17. Интерфейс администратора RabbitMQ при двух узлах, вышедших из строя в в трехузловом кластере

Рис. 18. Интерфейс администратора HAProxy при двух узлах, вышедших из строя в в трехузловом кластере

Тестирование производительности

Одним из критически важных параметров работы интеграционной шины является ее пропускная способность, измеряемая в количестве сообщений в единицу времени. Одной из задачей ВКР было обеспечение пропускной способности, равной 10000 сообщений в секунду.

Для проверки удовлетворения пропускной способности интеграционной шины вышеуказанному условию в рамках интеграционного потока по синхронизации групп Google и каналов Zulip были произведены интеграционные тесты с помощью инструмента Apache Jmeter (рис. 19).



Рис. 19. Интерфейс Apache Jmeter

Построение интеграционного теста с помощью Apache Jmeter разобрано в статье “Using JMeter to Performance Test Web Services” [5]. Тест предполагает написание и запуск тестового сценария, в ходе которого выполняется логика по подключению к серверу RabbitMQ, отправке сообщения и фиксирование времени его прибытия в место назначения.

...