Таблица 3.2. Отправка сообщения
|
Действия акторов |
Отклик системы |
|
|
Клиент инициирует отправку сообщения |
Система проверяет есть ли у данного клиента права отправлять запрашиваемый тип сообщений. При положительном варианте, система конвертирует сообщение для передачи RabbitMQ и передает его |
Название: Прием сообщения
Акторы: Клиент
Краткое описание: Клиент получает сообщение из шины
Триггер: Шина получает новое сообщение
Основной поток представлен в табл. 3.3.
Таблица 3.3. Прием сообщения
|
Действия акторов |
Отклик системы |
|
|
Клиент отправляет сообщение |
Система проверяет наличие подписок на данных тип сообщения. При наличии подписки хотя бы у одного клиента, система получает от RabbitMQ сообщение, конвертирует его для передачи клиенту и передает |
|
|
Клиент получает сообщение |
Система получает подтверждение отправки. После получения сообщения всеми подписанными клиентами, сообщение удаляется из базы данных шины |
Название: Управление подписками клиентов
Акторы: Клиент
Краткое описание: Клиент подписывается или отписывается от типа сообщений
Триггер: Клиент подписывается или отписывается от типа сообщений
Основной поток представлен в табл. 3.4.
Таблица 3.4. Управление подписками клиентов
|
Действия акторов |
Отклик системы |
|
|
Клиент подписывается на тип сообщений, используя административное приложение шины |
Система добавляет соответствующую запись в базу данных шины |
|
|
Клиент отписывается от типа сообщений, используя административное приложение шины |
Система добавляет соответствующую запись в базу данных шины |
3.2 Диаграммы активностей
Функция отправки сообщения клиентом выглядит следующим образом (см. рис. 3.5):
Рисунок 3.5. Отправка сообщения
Как видно из рисунка, клиент инициирует отправку сообщения, после чего система проверяет есть ли у клиента-отправителя разрешение на отправку данного типа сообщений. В случае, если разрешение есть, система конвертирует сообщение в тип, принимаемый Rabbit MQ, и передает его. После чего Rabbit MQ принимает сообщение и добавляет запись об этом в лог.
Функция приема сообщений (см рис. 3.6):
Рисунок 3.6. Прием сообщения
Чтобы получить сообщение, клиент должен быть подписан на прием данного типа сообщений. При получении нового сообщения система проверяет, есть ли клиенты с действительной подпиской на полученный тип сообщения. Для найденных клиентов собирается информация о количестве сообщений, которые ожидают передачи клиенту, затем передаются сами сообщения. После получения подтверждения о том, что клиент получил сообщение, это сообщение удаляется из базы данных шины.
3.3 Результаты проектирования
В ходе текущей главы был спроектирован компонент интеграции Flexberry Service Bus и Rabbit MQ. На диаграмме компонентов показано его место в имеющейся системе. С помощью диаграммы прецедентов были определены функции и роли акторов в системе. Для моделирования бизнес-процессов были построены диаграммы активностей.
Глава 4. Реализация системы Flexberry Service Bus RMQ
4.1 Физическая реализация структуры данных
Система реализована в среде разработки Microsoft Visual Studio с поддержкой баз данных Microsoft SQL Server, PostgresSQL на языке программирования C#.
Для интеграции с RabbitMQ создан пакет NewPlatform.Flexberry.ServiceBus.RabbitMQ с реализацией следующих компонентов:
- ReceivingManager - позволяет получать сообщения хранящиеся в RabbitMQ привычным для клиентов Flexberry Service Bus способом
- SendingManager - позволяет отправлять сообщения в RabbitMQ привычным для клиентов Flexberry Service Bus способом
- StatisticsService - собирает статистику сообщений RabbitMQ и преобразует ее в статистику Flexberry Service Bus
- SubscriptionsManager - позволяет управлять маршрутизацией сообщений в RabbitMQ
- SubscriptionsSynchronizer - актуализирует настройки маршрутизации сообщений в RabbitMQ
- MessageConverter - преобразует сообщения в формат Flexberry Service Bus
- MessageManager - позволяет управлять сообщениями хранящимися в RabbitMQ
Полученную в результате реализации диаграмму классов (см. рис. 4.1):
Рисунок 4.1. Диаграмма классов
Классы IMessageConverter и RmqMessageConverter используются для конвертирования сообщения шины в формат, принимаемый RabbitMQ. IMessageManager и RmqMessageManager содержат методы для управления сообщениями в RabbitMQ (возвращение сообщений из RabbitMQ и их количества, конвертер сообщений из формата RabbitMQ в формат Flexberry Service Bus, удаление сообщений из очереди). Класс RmqReceivingManager служит для приема сообщений из сервисной шины в RabbitMQ. Класс RmqConsumer следит за подписками клиента и определяет, когда послать ему сообщение. RmqSendingManager - класс для доставки сообщений из RabbitMQ. RmqStatisticsCollector собирает статистику из RabbitMQ. RmqSubscriptionsManager - класс работы с объектами маршрутизации RMQ. Класс RmqSubscriptionSynchronizer - класс для синхронизации подписок в RabbitMQ и шине Flexberry Service Bus. AmqpNamingManager используется для перевода наименований объектов маршрутизации шины и наименований объектов в AMQP (Advanced Message Queuing Protocol). В классе Queue задается формат сообщения очереди.
4.2 Функциональное тестирование
В целях проверки реализуемости функциональных требований системы проведем функциональное тестирование (табл. 4.1) [17].
Таблица 4.1. Функциональное тестирование
|
№ теста |
Действие |
Ожидаемый результат |
Полученный результат |
-/+ |
|
|
1 |
Отправить сообщение, на тип которого никто не подписан |
Ни один из клиентов не получил сообщения |
Ни один из клиентов не получил сообщения |
+ |
|
|
2 |
Отправить сообщение, на тип которого подписан один клиент |
Подписанный клиент получил сообщение |
Подписанный клиент получил сообщение |
+ |
|
|
3 |
Отправить сообщение, на тип которого подписано несколько клиентов |
Подписанные клиенты получили сообщение |
Подписанные клиенты получили сообщение |
+ |
|
|
4 |
Отправить сообщение, на тип которого подписан один клиент с опцией callback |
Подписанный клиент получил сообщение |
Подписанный клиент получил сообщение |
+ |
|
|
5 |
Отправить сообщение, на тип которого подписано несколько клиентов с опцией callback |
Подписанные клиенты получили сообщение |
Подписанные клиенты получили сообщение |
+ |
|
|
6 |
Отправить сообщение, на тип которого подписано несколько клиентов с разными типами подписок |
Подписанные клиенты получили сообщение |
Подписанные клиенты получили сообщение |
+ |
|
|
7 |
Подписаться на тип сообщений |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
8 |
Подписаться на тип сообщений с опцией callback |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
9 |
Получить сообщение с просроченной подпиской |
Сообщение не доставлено |
Сообщение не доставлено |
+ |
|
|
10 |
Получить сообщение с просроченной подпиской с опцией callback |
Сообщение не доставлено |
Сообщение не доставлено |
+ |
|
|
11 |
Оформить подписку на тип сообщений с взаимодействием через WCF интерфейс |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
12 |
Получить сообщение для клиента с подпиской с взаимодействием через WCF интерфейс |
Подписанный клиент получил сообщение |
Подписанный клиент получил сообщение |
+ |
|
|
13 |
Оформить подписку на тип сообщений с взаимодействием через REST интерфейс |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
14 |
Получить сообщение для клиента с подпиской с взаимодействием через REST интерфейс |
Подписанный клиент получил сообщение |
Ошибка |
- |
|
|
15 |
Отправить сообщение. Запустить клиента с подпиской на данный тип сообщения |
Клиент получил все сообщения, которые были отправлены до запуска работы клиента |
Клиент получил все сообщения, которые были отправлены до запуска работы клиента |
+ |
|
|
16 |
Отправить сообщение. Запустить клиента с подпиской на данный тип сообщения с опцией callback |
Клиент не получил сообщений. При последующей отправке с запущенным клиентом сообщения приходят |
Клиент не получил сообщений. При последующей отправке с запущенным клиентом сообщения приходят |
+ |
|
|
17 |
Запустить клиента с действительной подпиской, не отправляя никаких сообщений в шину |
Клиент запущен, сообщений не получено |
Ошибка |
- |
|
|
18 |
Запустить клиента с действительной подпиской с функцией callback, не отправляя никаких сообщений в шину |
Клиент запущен, сообщений не получено |
Клиент запущен, сообщений не получено |
+ |
|
|
19 |
Отправить сообщение из приложения клиента-отправителя, отключить питание, включить, запустить приложение клиента-получателя |
Сообщение доставлено, несмотря на «сбой» |
Сообщение доставлено, несмотря на «сбой» |
+ |
Как видно из таблицы, два случая не прошли тестирование (тесты №14 и №17). Следовательно, предстоит отладить работу с REST интерфейсом и баг с запуском клиента без сообщений.
Тестирование проводилось с учетом того, что в конфигурации сервисной шины Flexberry Service Bus выбрана передача сообщений через RabbitMQ.
4.3 Нагрузочное тестирование
Для исследования времени отклика системы в зависимости от нагрузки проведем нагрузочное тестирование. Для проведения тестирования воспользуемся средствами тестирования среды Microsoft Visual Studio 2017, а именно шаблоном пошаговой нагрузки.
Зададим следующие настройки:
- начальное число пользователей: 100;
- максимальное число пользователей: 2000;
- длительность шага (секунд): 1800;
- время увеличения шага (секунд): 20;
- число пользователей на шаге: 100.
Для тестирования будем использовать одного клиента-отправителя и пошагово добавлять клиентов-получателей.
Результаты тестирования представлены на диаграмме (см. рис. 4.2):
Как видно из диаграммы, уровень отклика (уведомления о получении клиентом-получателем сообщения от клиента-отправителя) резко возрос по достижении семисот клиентов-получателей. Однако на протяжении всего тестирования время отклика не превышает одной секунды, что удовлетворяет требованиям к системе.
Рисунок 4.2. Нагрузочное тестирование Flexberry Service Bus RMQ
Если сравнивать время отклика полученной системы со старой версией Flexberry Service Bus (рис.4.3), т.е. без использования RabbitMQ, видно, что конфигурация RabbitMQ нагружает систему немного больше.
Рисунок 4.3. Нагрузочное тестирование Flexberry Service Bus
Дополнительная нагрузка на систему обусловлена тем, что использование RabbitMQ требует дополнительного времени, чтобы записывать данные в базу данных брокера сообщений, тогда как в варианте конфигурации без RabbitMQ данные записываются только в базу данных сервиса шины.
4.4 Результаты реализации, тестирования и внедрения
В ходе главы была реализована система Flexberry Service Bus RMQ. Изменения затронули один компонент, как и было заявлено требованиями. Было проведено функциональное и нагрузочное тестирование, которое показало улучшение отказоустойчивости системы.
Несмотря на то, что время отклика системы без использования конфигурации RabbitMQ ниже, использование этой конфигурации дает преимущества в плане надежности системы. Использование дополнительной базы данных RabbitMQ позволяет сохранить непереданные сообщения, и в случае непредвиденного сбоя (отключения любого из клиентов, либо отказа самой шины) передать сообщения после восстановление работоспособности компонента. Тестирование Flexberry Service Bus без конфигурации RabbitMQ показало, что в случае сбоя, непереданные сообщения теряются.
Система введена в эксплуатацию и доступна посредством docker-образа. После обновления Flexberry Service Bus можно запускать как с использованием RabbitMQ, так и без. Подробнее об этом в руководстве программиста (см. прил. Б).
Заключение
В ходе работы была проанализирована предметная область, а именно назначение и принцип работы сервисных шин. В процессе анализа теоретической части исследования было решено спроектировать и реализовать модуль Flexberry Service Bus RMQ для системы Flexberry Service Bus, входящей в состав Flexberry Platform. Следуя функциональным требованиям и учитывая структуру уже имеющейся системы, была построена модель TO-BE. Было написано техническое задание (см. прил. А) и технико-экономическое обоснование.
Был реализован модуль Flexberry Service Bus RMQ с помощью языка программирования C#. Работа функций системы была протестирована на тестовых приложениях: клиенте-отправителе и клиентах с разными видами подписок. Тестирование показало повышении надежности системы и, также, выявило наличие ошибки при использовании одного из типов подписок. Обновленная система доступна для использования в виде docker-образа.
Таким образом, все поставленные задачи были решены и цель работы была достигнута. В ходе работы было написано 17 классов и 20 наборов тестов. Были написаны руководства программиста (см. прил. Б) и пользователя (см. прил. В). Новая версия системы выпущена и используется на реальных проектах.
Впоследствии предстоит отладить систему с учетом ошибок функционального тестирования. Ведется разработка нового административного приложения и добавление нового функционала.
Библиографический список
1. Rosmansyah Y., Putro B. L.: Functionality Design of Enterprise Service Bus (ESB) as Middleware on the Smart Educational Service Computing System Platform. L: International Conference on Information Technology Systems and Innovations (ICITSI), 2017.
2. Junhus D, Yan G., Ning F.: A Service Composition Environment based on Enterprise Service Bus. L: 11th Conf on Ubiquitous Intelligence & Computing, 2014.
3. Ashari A., Kurniawan K..: Service Orchestration using Enterprise Service Bus for Real-time Government Executive Dashboard System. L: in International Conference on Data and Software Engineering, 2015.
4. Taufik Sulaeman A.: Design Architecture Enterprise Service Bus to Support Multi-Tenant Client and Resource Provider. L: International Conference on Information Technology and Electrical Engineering (ICITEE), 2015.
5. Bhadoria R. S., Prasad S., Chaudhari N.: Information Handling and Processing using Enterprise Service Bus in Service-Oriented Architecture System. L: International Conference on Computational Intelligence and Communacation Networks, 2016.
6. Grochla K., Seman A., Rostanski M.: Evaluation of highly available and fault-tolerant middleware clustered architectures using RabbitMQ. L: Federated Conference on Computer Science and Information Systems, 2014.
7. Ionescu V. M.: The analysis of the performance of RabbitMQ and ActiveMq. L: IEEE Computer Society, 2015.
8. Архитектура Flexberry Service Bus // Документация по платформе Flexberry. 2019. URL: https://flexberry.github.io/ru/fsb_architecture.html (дата обращения: 30.05.2019).