МИНОБРНАУКИРОССИИ
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«МИРЭА - Российский технологический университет»
РТУМИРЭА
Институт информационных технологий
Кафедра математического обеспечения и стандартизации информационных технологий
РАБОТА ДОПУ�ПА К ЗАЩИТЕ
Заведующий
кафедрой
FIЯ"'---- 2023
«_Ql_» ------'ИЮ==
Г.
ВЬШУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
по направлению подготовки магистров 09.04.04 Программная инженерия
На тему: Метод проектирования интероперабельных интерфейсов программных сервисов
при построении единого информационного пространства организации
Обучающийся
Фамwшя, имя, отчество
шифр
группа
Руководитель работы
к.т.н., доцент
Москва 2023 г.
Аннотация
Ключевые слова: интеграционный адаптер, интеграция, межсервисное
взаимодействие, архитектура, проектирование, REST, Kafka.
Данная
дипломная
работа
посвящена
методу
проектирования
интероперабельных интерфейсов программных сервисов при создании
единого информационного пространства организации. Актуальность темы
обусловлена необходимостью интеграции различных информационных
систем для повышения их эффективности и сокращения затрат на разработку
новых приложений.
В работе проведен анализ существующих методов интеграции
информационных систем и интероперабельных инструментов. Результатом и
целью исследования является разработанный метод, который позволяет
проектировать
интероперабельные
интерфейсы
между
различными
информационными системами с помощью универсального языка описания
интерфейсов.
Дипломная работа содержит описание этапов метода проектирования
интероперабельных интерфейсов программных сервисов, а также примеры
его применения в реальных проектах, состоит из 62 страниц, 4 рисунков и 11
таблиц. Результаты работы могут быть использованы компаниями и
организациями при разработке единого информационного пространства, что
позволит повысить эффективность работы систем и сократить затраты на
разработку новых сервисов.
Annotation
Keywords: integration adapter, integration, inter-service interaction,
architecture, design, REST, Kafka.
This thesis is devoted to the method of designing interoperable interfaces of
software services when creating a single information space of the organization.
The relevance of the topic is due to the need to integrate various information
systems to increase their efficiency and reduce the cost of developing new
applications.
The paper analyzes the existing methods of integration of information
systems and interoperable tools. The result and purpose of the study is the
developed method that allows you to design interoperable interfaces between
different information systems using a universal interface description language.
The thesis contains a description of the stages of the method of designing
interoperable interfaces of software services, as well as examples of its application
in real projects, consists of 61 pages, 4 figures and 11 tables. The results of the
work can be used by companies and organizations in the development of a unified
information space, which will increase the efficiency of systems and reduce the
cost of developing new services.
Содержание
Список используемых сокращений ....................................................................... 6
Введение ................................................................................................................... 7
ГЛАВА 1. Объект, предмет, проблема и цель исследования ............................. 9
1.1. Модели архитектуры организации ........................................................... 9
1.2. Сравнение архитектурных моделей........................................................ 14
1.3. Техническое задание ................................................................................ 16
1.4. Выводы к первой главе ............................................................................ 23
Глава 2. Реализация проекта ................................................................................ 24
2.1. Инфраструктура информационных систем организации ..................... 24
2.2. Системное и прикладное программное обеспечение ........................... 29
2.3. Техническое обеспечение ........................................................................ 34
2.4. Организационное обеспечение................................................................ 35
ГЛАВА 3. Разработка метода проектирование интероперабельных
интерфейсов и его оценка .................................................................................... 40
3.1. Формирование метода проектирования ................................................. 40
3.2. Качественная оценка метода ................................................................... 49
3.3. Оценка экономической эффективности от внедрения метода ............ 51
Заключение ............................................................................................................ 57
Список используемых источников ...................................................................... 59
Приложения ........................................................................................................... 64
Приложение А ....................................................................................................... 65
5
Список используемых сокращений
БД - База данных
ИС – информационная система
ПО - программное обеспечение
ПП - программный продукт
СУБД - система управления базами данных
ТЗ - техническое задание
ER - Entity-Relationship (сущность-связь)
SQL - Structured Query Language (язык структурированных запросов)
ИС- Информационная система
СУБО – система устойчивых бизнес - операций
6
Введение
В настоящее время ключевым фактором для успешного развития
бизнеса является способность быстро реагировать на изменения в
окружающем мире. Пандемия коронавируса наглядно продемонстрировала,
что
зачастую
компании,
чья
внутренняя
инфраструктура
не
была
подготовлена к значительным изменениям в их операционной деятельности
попросту не могут выживать на рынке в условиях современной конкуренции.
Эта парадигма относится как к сегменту малого бизнеса, так и крупным
компаниям – лидерам в отрасли. Финансовые учреждения, являясь одними из
главных игроков в современной экономической системе мира вынуждены не
отставать от мировых тенденций внедрения новых технологий для того,
чтобы оставаться конкурентоспособными, гибкими и адаптируемыми к
изменениям, происходящих в мире. На текущий момент банки являются
одними из главных представителей индустрии Финтеха – индустрии,
находящейся на пересечении финансовых услуг и секторов информационных
технологий. Данная тенденция не обошла стороной и российский банковский
сегмент. Согласно исследованию, проведенному компании «Ланит Би Пи
Эм»
посвященному анализу уровня автоматизации российских банков
1
0F
бюджеты на автоматизацию за последние пару лет увеличились на 44%. У
крупных банков, таких как Сбербанк, ВТБ, Альфа банк и Тинькофф бюджеты
на автоматизацию составляют более 500 млн руб. Связано это прежде всего с
необходимостью полного перевода банковских услуг в онлайн, а также с
желанием быстро выводить новые кредитные продукты на рынок. Главным
показателем для банков является time-to-market, представляющий собой
время за которое рабочий продукт будет разработан и ценность будет
поставлена потенциальному клиенту.
Целью данной магистерской выпускной квалификационной работы
1
Автоматизация банков РФ 2021
URL
https://lanitbpm.ru/banksautomationresearch2021?utm_source=mailgklanit&utm_medium=emai
l&utm_campaign=tadvizerresearch2021 ( дата обращения 11.04.2022)
7
является разработка методики, позволяющей упростить аналитикам и
архитекторам проектирование интеграционных микросервисов в сложных
корпоративных системах на примере банка ВТБ.
Для достижения поставленной цели необходимо выполнить следующие
задачи:
• провести сравнительный анализ подходов к построению архитектуры
программного обеспечения;
• изучить основные подходы к проектированию сервисов;
• сформировать архитектуру интеграционного сервиса;
• разработать методику проектирования интеграционных микросервисов
• количественно оценить эффект от внедрения метода
Объектом исследования выступает интеграционных микросервис,
спроектированный в соответствии с разработанным методом. Предметная
область представляет собой наиболее часто используемые архитектурные
паттерны проектирования сервисов в распределенной архитектуре.
Актуальность данной работы обусловлена необходимостью построения
постоянных интеграций в сложных корпоративных системах. Практическая
значимость работы заключается в дальнейшем использовании данной
методики другими аналитиками компании при проектировании сервисов,
позволяющей сэкономить время на написание аналитики.
8
ГЛАВА
1.
Объект,
предмет,
проблема
и
цель
исследования
1.1. Модели архитектуры организации
Для более углубленного понимания предметной области опишем
понятия предприятия и архитектуры.
Предприятие является бизнес-ассоциацией, состоящей из признанной
совокупности взаимодействующих бизнес-функций. Это может быть и
государственная организация, и общественное, в том числе неформальное,
объединение участников, связанных общей целью. Предприятие может
функционировать как самостоятельная, отдельная организация. Следуя
вышеописанному определению, могут существовать предприятия в пределах
предприятий. Например, организационный элемент внутри глобальной
корпоративной структуры может быть представлена как предприятие при
наличии возможности автономного функционирования. Предприятие можно
также описать как «Расширенное предприятие (Extended Enterprise)»: это
означает,
что
масштаб
архитектуры
предприятия
может
включать
взаимосвязи с внешними компаниями, такими как поставщики, бизнеспартнеры и клиенты.
Архитектура
предприятия
обеспечивает
базовую
концепцию.
описывает, как организация выполняет свою работу, используя такие
ресурсы, как люди, бизнес-процессы, данные и технологии. Архитектуру
предприятия можно представить, как процесс изменения новых бизнесстратегий в основанные на информационных технологиях и реализуемые в
масштабах всей организации решения, которые подкреплены принятыми
принципами управления.
Как правило, к построению архитектуры предприятия прибегают в
следующих случаях:
− для отчетности инвесторам или учредителям, для того чтобы
показать
результат
до
оптимизации
9
или
устаревшую
архитектуру
предприятия. Это позволяет показать процесс «как было». К тому же это
необходимо для приобретения сертификата ISO 9000. ISO 9000 — серия
международных
стандартов,
определяющих
требования
к
системе управления организаций и предприятий. Следует отметить, что
сертификация по ISO 9000 не является обязательной для каждого
предприятия.
Основной
причиной
сертификации
является
то,
что
большинство иностранных компаний указывают необходимость получения
сертификата от своих партнеров. И, кроме того, наличие сертификата может
стать
основным
условием
для
участия
предприятия
в
крупных
интернациональных конкурсах, государственных заказах, а также получения
льготных страховок и кредитов;
− реорганизация текущих процессов. В некоторых случаях в уже
налаженной работе организации происходит снижение эффективности
бизнес-процессов. Причинами могут быть устаревание текущей модели
процессов предприятия или, например, процессы конкурента оказалась
намного эффективнее. В таких случаях прибегают к построению архитектуры
предприятия, что позволяет выявить проблемные места, из-за которых
происходит спад. Это позволяет своевременно реорганизовать бизнеспроцессы и вернуться или превзойти предыдущие результаты;
− запуск нового продукта или услуги вдет к пересмотру архитектуры
предприятия. Ввод нового продукта значительно может сказаться на
организации как в положительном смысле (продут стал приносить прибыль),
так и в отрицательном (продукт имеет стратегическое назначение и требует
инвестиций). Необходимо оптимизировать предприятия под текущие реалии
и при необходимости внести изменения для улучшения бизнес-процессов;
− создание
информационной
системы.
Автоматизация
бизнес-
процессов компании может привести к значительным изменениям внутри
компании. Для этого необходимо как можно лучше оптимизировать большую
часть процессов и понимать, что можно оптимизировать и какую выгоду
компания получит от этого. Построение модели с использованием
10
информационных систем на предприятии как правило пересекается с
системной
инженерией.
Системная
инженерия —
основной
подход,
определяющий необходимые технические и управленческие действия,
которые
требуются
для
того,
чтобы
трансформировать
множество
потребностей, пожелания заказчика и имеющиеся рамки в эффективные
решения и сопровождать эти решения в течение их жизненного цикла [3].
Необходимость исследования построения архитектуры предприятия
обусловлена, в первую очередь, изучением влияния на итоговый результат
различных подходов и моделей. Различные методы были разработаны для
различных целей, в разных странах и в разное время. Из-за большого
разнообразия на сегодняшний день нет единого подхода, который мог бы
подойти всем организациям. Так, до девяностых годов прошлого века
архитектура
предприятия
строго
ассоциировалась
с
технической
архитектурой предприятия, в девяностые годы техническая архитектура
преобразовалась в информационно-техническую. На сегодняшний день
модели построения архитектуры предприятия основывается на бизнес-целях
и
миссии
компании,
организационную
которые
структуру,
а
определяют
те
в
свою
бизнес-процессы
очередь
и
определяют
информационно-техническую архитектуру.
Так как среди различных современных методологий нет единственного
правильной, то на сегодняшний день актуален вопрос о выборе наиболее
оптимального подхода к построению архитектуры предприятия для ITкомпании. Для решения этого вопроса было рассмотрено несколько
архитектурных подходов.
Архитектурный подход – методика описания архитектуры системы.
Исследование
различных
архитектурных
подходов
позволит
понять
положительные и отрицательные стороны той или иной методики и сделать
выводы о том какие из них более подходят для текущей задачи.
Интероперабельность информационных систем — это возможность
различных систем обмениваться данными и взаимодействовать между собой,
11
не
зависимо
от
того,
как
они
были
разработаны,
какой
язык
программирования использовался и где они находятся.
В
соответствии
с
этим
существуют
несколько
моделей
интероперабельности систем:
1.
Enterprise
Application
Integration
(EAI)
-
модель
интероперабельности, которая позволяет объединить разные приложения и
системы в единую интегрированную среду. это методология архитектуры,
которая используется для объединения различных приложений, систем и
процессов внутри предприятия, создавая единую интегрированную систему,
которая может
общаться и передавать данные между различными
приложениями.
EAI
является
ключевым
элементом
в
разработке
корпоративных информационных систем (CIS), которые обычно состоят из
множества приложений, использующихся в различных бизнес-процессах.
Эти приложения обычно разработаны на разных платформах, используют
различные технологии и форматы данных, что затрудняет их интеграцию.
EAI предназначен для облегчения интеграции приложений и упрощения
системных архитектур. Это достигается путем создания слоя интеграции,
который подключается к приложениям и предоставляет единый интерфейс
для взаимодействия между приложениями. В этом слое используются
различные технологии и протоколы, такие как SOAP, REST, JMS, JDBC и
многие другие.EAI также позволяет решать проблемы, связанные с
распределенными
системами,
такими
как
синхронизация
данных,
маршрутизация сообщений, обработка запросов и управление ошибками. Он
предоставляет инструменты для создания комплексных бизнес-логик и
возможности для автоматизации бизнес-процессов.
2.
Service-Oriented
Architecture
(SOA)
-
модель
интероперабельности, основанная на использовании веб-сервисов. SOA
позволяет создавать гибкие архитектуры, которые могут адаптироваться к
изменению требований организации. SOA может быть использована в
организациях, которые хотят упростить процессы интеграции между
12
приложениями и системами. В SOA каждая служба представляет собой
самодостаточное приложение, которое выполняет определенную функцию и
устанавливает контракт с другими службами. Службы обмениваются
информацией через стандартные протоколы и интерфейсы, что позволяет им
работать вместе независимо от того, на каком языке программирования и на
какой платформе они были созданы. Основные преимущества SOA
заключаются в возможности повторного использования служб, улучшении
масштабируемости
приложений,
упрощении
интеграции
приложений,
повышении доступности и надежности приложений и уменьшении расходов
на разработку и сопровождение приложений.SOA может быть реализована с
помощью различных технологий, таких как SOAP (Simple Object Access
Protocol), REST (Representational State Transfer), XML (Extensible Markup
Language), JSON (JavaScript Object Notation) и другие. Однако, необходимо
учитывать некоторые ограничения SOA, такие как повышенная сложность
разработки и поддержки служб, наличие проблем с безопасностью и
вопросы, связанные с согласованием интерфейсов между службами. В целом,
SOA является эффективным подходом для создания гибких и расширяемых
приложений, которые могут легко интегрироваться с другими приложениями
и службами.
3.
Open
Application Programming Interfaces
интероперабельности,
которая
позволяет
(APIs) -
разработчикам
модель
создавать
стандартные интерфейсы для программирования приложений. Open APIs
позволяют разным приложениям и системам обмениваться данными без
необходимости знать подробности реализации. Open APIs могут быть
использованы
в
организациях,
которые
хотят
создать
стандартные
интерфейсы для программирования приложений. Одним из примеров API
является Google Maps API, который позволяет разработчикам использовать
картографические данные Google Maps в своих приложениях. Другим
примером может быть API Facebook, которое позволяет интегрировать
функции Facebook в другие приложения, такие как вход с использованием
13
учетных
данных
Facebook.
Чтобы
обеспечить
стандартизацию
и
совместимость, Open APIs часто основаны на открытых стандартах, таких
как REST (Representational State Transfer) и JSON (JavaScript Object Notation).
Это
упрощает
использование
API
различными
приложениями
и
платформами. Open APIs позволяют упростить взаимодействие между
приложениями, предоставляют готовые решения для разработчиков, а также
повышают качество и функциональность приложений. Они также могут быть
использованы для создания новых платформ и сервисов.
Каждая из этих моделей интероперабельности информационных
систем может быть применена в зависимости от задач и требований
организации. EAI и SOA могут быть использованы для интеграции
приложений и систем, которые работают на разных платформах и языках
программирования.
OSI
может
быть
использована
для
обеспечения
совместимости с разными системами, работающими на разных уровнях. Open
APIs могут быть использованы для создания стандартных интерфейсов для
программирования приложений. Каждая из этих моделей может быть
применена в соответствии с требованиями конкретной организации. В
организации, которую мы рассматриваем принят по большей части SOA
подход
1.2.
Сравнение архитектурных моделей
SOA – это архитектура, которая позволяет различным приложениям
взаимодействовать друг с другом, используя веб-сервисы. SOA описывает
сервисы и связи между ними, а также используемые протоколы и стандарты.
Это позволяет создавать интероперабельные решения для различных бизнесприложений.
Open APIs - это интерфейсы программирования приложений, которые
позволяют программистам создавать приложения, используя функционал
внешнего приложения. Open APIs позволяют интегрировать различные
приложения
и
сервисы
вместе,
обеспечивая
14
более
эффективное
использование ресурсов и улучшая пользовательский опыт.
Одна из ключевых разниц между SOA и Open APIs заключается в том,
что SOA является более расширенной и сложной моделью, которая
охватывает не только API, но и другие службы и индивидуальные
компоненты. Open API, напротив, представляет только один аспект
взаимодействия между системами.
EAI - это подход к интеграции приложений, который основывается на
использовании
специализированных
инструментов
и
технологий
для
связывания отдельных приложений, баз данных и систем. Цель EAI
заключается в обеспечении бесперебойной передачи данных между
системами,
сокращении
времени
на
разработку
и
обновление
интеграционных решений. EAI интегрирует приложения на уровне данных и
позволяет существующим системам обмениваться данными. SOA, с другой
стороны, это концепция построения архитектуры приложений, которая
ориентирована на использование сервисов в качестве единицы общей
функциональности, которую могут использовать различные приложения. В
такой архитектуре каждый сервис выполняет определенные функции,
которые могут быть использованы другими приложениями в качестве общей
службы. Цель SOA состоит в создании более гибкой и модульной
архитектуры, которая позволяет быстро менять сервисы для удовлетворения
меняющихся бизнес-потребностей.
Основные различия между EAI и SOA заключаются в следующем:
- Ориентация: EAI ориентирован на интеграцию приложений на уровне
данных, тогда как SOA - на использование сервисов в качестве общей
функциональности.
- Гибкость: SOA гибче, чем EAI, поскольку позволяет быстро изменять
и обновлять функциональность сервисов, в то время как при использовании
EAI приходится менять интеграционные решения и проводить перебоя!
- Подход к разработке: EAI основан на использовании инструментов
интеграции, тогда как SOA базируется на работе с сервисами и их
15
функциональностью.
- Результат: EAI разработан в качестве средства позволяющего
системам общаться друг с другом, тогда как SOA разработан обеспечения
гибкости и удобства использования сервисов.
Несмотря на значительные отличия, EAI и SOA во многих случаях
использования могут быть комбинированы друг с другом, получая
наилучшую функциональность обеих архитектур, однако в текущей ситуации
с учетом упора на гибкость и функциональность в дальнейшем мы будем
рассматривать концепцию сервиса с точки зрения именно модели SOA.
1.3.
Техническое задание
Далее представлено техническое задание к методу на основании ГОСТ
34.
Облик предлагаемой системы. Техническое задание на разработку вебприложения
1.1.1 Основные требования ТЗ. Общие положения
1.1.1.1
Полное наименование системы и ее условное обозначение
1.1.1.2
Наименование организации-заказчика и организаций-участников
работ
Разработчик:
Старший
системный
аналитик
Кузнецов
Никита
Романович
1.1.1.5
Плановые сроки начала и окончания работы по созданию
системы
Плановый срок начала работ по созданию сервис адаптера– 5 ноября
2022 года
Плановый срок окончания работ по внедрению сервис адаптера в
промышленную среду – 1 апреля 2022 года.
16
1.1.1.6
Источники и порядок финансирования работ
Источником финансирования является банк ВТБ
Порядок финансирования определяется банковским регламентом
распределения бюджета
1.1.1.8
Перечень
нормативно-технических
документов,
методических
материалов, использованных при разработке ТЗ (технического задания)
При разработке сервис-адаптера поиска недвижимости и создании
проектно-эксплуатационной
документации
Исполнитель
должен
руководствоваться требованиями следующих стандартов:
− ГОСТ 34.201-2020. Информационная технология. Комплекс стандартов
на автоматизированные системы. Виды, комплексность и обозначение
документов при создании автоматизированных систем;
− ГОСТ
34.601-90.
Комплекс
стандартов
на
автоматизированные
системы. Автоматизированные системы. Стадии создания
− ГОСТ
19.201-78.
Единая
система
программной
документации.
Техническое задание. Требования к содержанию и оформлению.
1.1.1.9 Определения, обозначения и сокращения
БД - База данных
ИС – Информационная система
ПО - программное обеспечение
ПП - программный продукт
СУБД - система управления базами данных
ТЗ - техническое задание
17
ER - Entity-Relationship (сущность-связь)
SQL - Structured Query Language (язык структурированных запросов)
API – Application Programming Interface (программный интерфейс
приложения, интерфейс прикладного программирования)
REST – архитектурный стиль взаимодействия между приложениями
внутри сети
Стрим – подразделение банка отвечающее за одно из направлений
развития банковских
1.1.2 Назначение и цели создания системы
1.1.2.1 Назначение системы
Назначение системы: Сервис призван обеспечить снижение нагрузки
на мастер систему-источник данных, а также удовлетворить новым
требованиям заказчиков в лице продуктовых команд
1.1.2.2 Цели создания системы
Разработка сервис адаптера со стороны бизнес заказчика преследует
следующие цели:
1. Повышение отказоустойчивости мастер-системы
2. Увеличение
скорости
получения
продуктовыми
сервисами
информации о бизнес объекте
1.1.3 Характеристика объекта автоматизации
Объектом автоматизации является процессы работы с данными
организаций-клиентов банка.
Процессы сервиса включают в себя:
18
− Внедрение
в
существующие
системы
заказчика
нового
API,
являющуюся сервисом, выполняющим функции кэширования текущих
ответов мастер системы
1.1.4 Требования к системе
Сервис должен предоставлять возможность потребителям сервиса
получать актуальную информацию из мастер системы, кэшировать ответы в
локальную БД сервиса, получать обновления карточки посредством Kafka и
записывать обновления в локальную БД сервиса, оповещать продуктовые
сервисы посредством REST сообщений.
Также система должна обеспечивать своевременный отклик в
соответствии со сценариями вероятностных условий.
1.1.4.1.4 Требования к надежности
К надежности предпринимаются следующие критерии и требования:
− Все технические средства должны удовлетворять классу решаемых
задач;
− В качестве аппаратных средств должны использоваться устройства с
повышенными показателями надежности
− Система должна иметь возможность восстановления БД при сбоях
− Должно
поддерживаться
постоянное
электропитание
сетевого
оборудования
− Процессы администрирования по исправлению сбоев должны быть
своевременными и четкими
− Ведение журнала с сетевыми логами
1.1.4.1.5 Требования к безопасности
19
К эксплуатации системы может допускаться любой пользователь,
имеющий достаточную теоретическую и практическую подготовку.
1.1.4.1.6 Требования к эргономике и технической эстетике
Система должна обеспечивать удобный интерфейс взаимодействия с
основными функциями системы, отвечающий требованиям заказчика. При
возникновении ошибок должна выводиться поясняющая информации, четко
и ясно отражающая суть проблемы. Информация должна быть предоставлена
в удобном, читаемом виде.
1.1.4.2 Требования к функциям (задачам) системы, выполняемым системой
Программный продукт должен выполнять следующие функции:
− Администрирование (разграничение прав доступа к данным и
функциям
системы;
обеспечение
целостности
базы
данных;
резервирование БД; возможность производить настройку приложений,
производить настройку базы данных; ввод, просмотр, изменение,
сохранение пользовательских данных);
− Должна обеспечивать структурированное хранение и отображение
имеющейся в системе информации;
− Должна логировать события происходящие в системе
− При запросе потребителями сервиса формировать json сообщение с
актуальными данными ЮЛ и отправлять его потребителям
− Оповещать потребителей об изменении данных ЮЛ
− Хранить в локальной БД данные об организации
− Считывать из внешнего брокера сообщений изменения мастер
системы
1.1.4.3 Требования к видам обеспечения
20
1.1.4.3.1 Требования к информационному обеспечению системы
Состав, структура и способы организации данных в системе должны
быть опеределены на этапе технического проектирования.
Уровень хранения данных в системе должен быть построен на основе
современных
реляционных
или
объектно-реляционных
СУБД.
Для
обеспечения целостности данных должны использоваться встроенные
механизмы СУБД. В качестве СУБД будет использоваться PostgreSQL
1.1.4.3.2 Требования к программному обеспечению системы
При проектировании и разработке системы необходимо максимально
эффективным образом использовать ранее
закупленное программное
обеспечение, как серверное, так и для рабочих станций.
Используемое при разработке программное обеспечение и библиотеки
программных кодов должны иметь широкое распространение, быть
общедоступными и использоваться в промышленных масштабах. Базовой
программной платформой должна являться операционная система Ubuntu.
Для одинаковой конфигурации системы Сервиса при разработке и
эксплуатации требуется использовать открытую платформу для разработки,
доставки и эксплуатации приложений Red Hat Openshift.
1.1.4.3.5 Требования к техническому обеспечению
Система должна быть реализована с использованием специально
выделенных серверов Заказчика, по умолчанию система развернута на
OpenShift Kubernetes.
1.1.4.3.6 Требования к организационному обеспечению
К организационному обеспечению можно отнести взаимодействие
пользователей с системой. Со стороны системы пользователю должны быть
21
представлена полная информация об ответах и коды ответов.
К защите от неверных действий пользователей должны предъявляться
следующие требования:
− Для пользователей должна отсутствовать возможно по редактированию
страниц проектов, не принадлежащих им
− Для пользователей должна отсутствовать возможно по удалению
страниц проектов, не принадлежащих им
− Для уменьшения процента ошибочных действия должна быть
разработана
полная
инструкция
пользователя
и
инструкция
администратора
1.4.4.3.7 Требования к методическому обеспечению
Все требования к методическому обеспечению описаны в нормативных
документах, указанных в ТЗ пункта 1.4.1.4.
1.4.5 Состав и содержание работ по созданию (развитию) системы
Работы по созданию системы выполняются в следующие этапы:
Таблица 1.1.Этапы работы системы.
Этап
Содержание работ
Результаты работ
1
Формирование требований к системе
Сформированные требования системы
2
Разработка технического задания
Готовое техническое задание
3
Разработка эскизного проекта
Эскизный проект
4
Разработка технического проекта и Технический
рабочая документация
документация
5
Тестирование системы
Итоги тестирования
6
Реализация рабочего проекта
Рабочий проект
22
проект
и
рабочая
Конкретные сроки выполнения стадий и этапов разработки и создания
системы
определяются
планом
выполнения
работ
по
настоящему
техническому заданию.
1.4.6 Порядок контроля и приемки системы
Система пройдет через следующие этапы приемки:
− Предварительное тестирование;
− Опытная эксплуатация;
− Приемные испытания.
1.4.7 Требования к составу и содержанию работ по подготовке объекта
автоматизации к вводу системы в действие
Для
создания
условий
полного
функционирования
необходимо
провести ряд мероприятий:
− Организация и установка необходимого сетевого оборудования;
− Регламентирование основных правил по взаимодействию с системой;
− Выделение ответственных лиц, отвечающих за администрирование
веб-приложения (выдачи прав доступа врачам и медсестрам).
1.4.8 Требования к документированию
Документы обязательно должны быть представлены в двух видах: в
бумажном виде и на электронном носителе информации (или в облаке).
Исходные тексты программ предоставляются только в облаке. Также
возможно предоставление комплекта документации и текстов программ на
флеш носителях. Также все документы должны быть написаны и оформлены
на русском языке.
1.4.
Выводы к первой главе
23
По результатам работы в первой главе были рассмотрены основные
архитектурные модели интероперабельности информационных систем,
выбрана модель SOA на базе которой было сформировано техническое
задание на проектирование интеграционного микросервиса, на основе
которого будет разработан методика по проектированию подобного рода
микросервисов, позволяющая сократить время аналитикам проекта на
проектирование похожих микросервисов
Глава 2. Реализация проекта
2.1.
Для
разработки
Инфраструктура информационных систем организации
формирования
метода
интеграционных
необходимо
адаптеров.
Под
понимать
специфику
интеграционным
сервис
адаптером понимается микросервис, который выполняет роль прокси сервиса
между продуктовыми бизнес сервисами и мастер системой хранения бизнес
данных, необходимый для обеспечения прозрачности и функционирования
бизнес-процессов, улучшения качества и актуальности корпоративных
данных, а также повышения надежности и безопасности системы, так как по
сути данный адаптер является единой точкой получения корпоративных
данных внутри системы. Сложные корпоративные системы, такие как
банковские чаще всего представляют собой сервисы устойчивых бизнес
операций (СУБО) - различные информационные системы реализующие один
или несколько бизнес-процессов (подпроцессов), объединенных одной
функциональной
областью,
предоставляющая
потребителям
пользовательский интерфейс (UI) или программный интерфейс (API),
который может быть встроен в различные канальные приложения, и
взаимодействующие с другими системами по определенным шаблонам. Они
существуют зачастую внутри банковского контура, однако находятся на
разных кластерах с целью отказоустойчивости всей корпоративной системы,
так как выведение из строя кластера одной информационной системы не
повлечет за собой отключение другой. СУБО зачастую объединены в
24
стримы. Стрим это функциональная единица в корпоративной структуре,
ответственная за один или несколько технологических продукта и
включающих несколько СУБО. Исходя из этого следует, что первоочередной
задачей для бизнеса является максимально быстрая реализация бизнес
потребностей
для
клиентов,
соответственно
при
проектировании
взаимодействия между СУБО и мастер системами хранения данных
недопустимо прямое взаимодействие, так как синхронное взаимодействие
между огромным количеством различных продуктовых сервисов и мастер
системой хранения данных значительно снижает отказоустойчивость и
надежность всей корпоративной системы в связи с большой нагрузкой,
которую могут генерировать эти продуктовые сервисы, также создается
нагрузка на платформу межсервисной авторизации, которая призвана
контролировать
авторизацию
внутренних
пользователей
сервисов
и
предотвращать несанкционированный доступ, а также очевидной проблемой
с
дальнейшем
масштабированием
в
связи
с
расширением
бизнес
функционала и появлением новых СУБО. Архитектурно данный антипаттерн
выглядит следующим образом:
Рисунок 2.1. Антипаттерн интеграционного взаимодействия в корпоративных системах
Данная схема является схематичным представлением того, как может
быть спроектировано неверное интеграционное взаимодействие.
25
Существует альтернативный вариант, при котором данные в БД
продуктовых сервисов будут консистентны по отношению к мастер системе.
Данный вариант предполагает полную загрузку всех данных в локальные БД
продуктовых
микросервисов
и
дальнейшем
распределенный брокер сообщений Kafka.
их
обновлений
через
Схематично данный подход
выглядит следующим образом:
Рисунок 2.2. Антипаттерн интеграционного взаимодействия через Kafka
Несмотря на то, что при подобной реализации мы обеспечиваем
консистентность и постоянное обновление всех данных, не нагружая мастер
систему, при таком подходе присутствуют очевидные недостатки:
1. Вынужденное хранение в БД продуктовых сервисов большого
количества информации, которая может не понадобиться данному
сервису
2. Значительное увеличение объемов памяти для БД внутри СУБО (в
случае если в мастер системе хранятся миллионы строчек)
3. В случае если мастер система содержит большие объемы данных –
увеличивается скорость обработки запросов и усложняется индексация
Но самый главный минус этих двух подходов состоит в том, что
команды ответственные за различные продуктовые сервисы внутри
26
одного и того же стрима должны тратить время на аналитику, разработку,
тестирование и вывод в эксплуатацию одних и тех же интеграций. Для
решения данной проблемы необходим интеграционный адаптер, который
будет иметь единую кодовую базу, а также который будет разнесен
одинаковыми экземплярами внутри каждого из СУБО внутри одного
стрима. В данном адаптере будут собраны только те данные, которые
необходимы продуктовым сервисам внутри одного СУБО, они будут
обновляться и данный адаптер станет единой точкой входа для получение
корпоративных данных в рамках той или иной бизнес сущности.
В процессе построения архитектуры было предложено целевое
архитектурное решение. Данное архитектурное решение можно сравнить с
паттерном проектирования API Gateway. API Gateway это распространённый
шаблон проектирования, используемый в архитектуре микросервисов,
который включает API gateway, который действует как точка входа для всех
входящих запросов API. Он обеспечивает единую точку входа для всех
микросервисов и действует как прокси-сервер между клиентами и
микросервисами, направляя запросы в соответствующую службу. Данный
паттерн крайне часто применяется в корпоративных структурах так как
обеспечивает масштабируемый, гибкий и безопасный способ управления
микросервисами в сложной системе, упрощая разработку, развёртывание и
обслуживание приложений на основе микросервисов. Среди прочих
преимуществ такого подхода является возможность мониторинга трафика,
кэширования запросов, единообразный интерфейс для взаимодействия
В предложенной концепции в качестве api gateway выступает
интеграционный сервис как единая точка входа для других клиентских
микросервисов.
Обычно для решения подобных ситуаций при проектировании
интеграционных решений выделяется отдельный интеграционный слой - в
текущей ситуации это было бы выделение отдельного СУБО внутри стрима,
27
в котором существовали бы интеграционные сервисы и к которым
обращались
бы
другие
СУБО,
однако
по
требованиям
заказчика
отказоустойчивость отдельных СУБО внутри стрима должна была быть 99%,
а выведение из строя интеграционного СУБО могло привести к отказу всех
систем стрима, поэтому от от выделения отдельного интеграционного слоя
пришлось отказаться в пользу отдельных экземпляров по сути одного и того
же интеграционного сервис адаптера внутри отдельных СУБО. Архитектурно
это выглядит следующим образом:
Рисунок 2.3. Целевое архитектурное решение
Таким образом данная реализация позволяет забирать из мастер
системы посредством REST запросов только необходимые для бизнеса
данные, сохранять их в локальную БД интеграционного адаптера, а также
поддерживать актуальность данных путем обновления через Kafka. В
долгосрочной перспективе такая реализация позволит наполнить локальный
кэш
только
всеми
данными,
которыми
действительно
пользуются
продуктовые сервисы и в дальнейшем позволит выполять вызовы мастер
системы в редких случаях, а также позволит в случае появления новых СУБО
в стриме масштабироваться, путем установки экземпляра микросервиса в
28
новое СУБО.
2.2.
Системное и прикладное программное обеспечение
В связи с выработанной архитектурной концепцией было принято
решение спроектировать и разработать отдельный экземпляр сервис адаптера
внутри одного из СУБО для того, чтобы в дальнейшем встраивать
разворачивать данный адаптер внутри других стримов и других СУБО.
Межсервисное взаимодействие между различными программными
интерфейсами происходит посредством REST взаимодействия между
системами. REST представляет собой архитектурный стиль проектирования
API, основанный на четком разделении клиентской и серверной части. REST
сервисы
используют
для
передачи
и
получения
информации
предопределенный набор методов, таких как GET (для получения данных с
сервера), PUT (для обновления/замены ресурсов сервера), POST (для
создания нового ресурса на сервере), DELETE (удаление ресурса с сервера) и
PATCH (для частичного изменения ресурса). REST проектирование
предполагает собой синхронное взаимодействие между сервисами зачастую
посредством https протокола и соблюдение основных принципов REST стиля
таких как:
• Клиент - серверная архитектура (разделение клиентской и
серверной части, клиентская сторона не знает, что происходит на
серверной, так как серверная часть является единой точкой
обработки запросов)
• Stateless (сервер не хранит у себя информацию о клиентской
сессии)
• Кэширование (сервер должен иметь пометку о необходимости
кэширования данных. Реализация локального кэша позволяет
ускорить ответ клиенту, так как ответ будет сгенерирован на
основании ранее записанных вкэш данных)
29
• Единообразие интерфейса (сервер возвращает не только ресурс,
но и его связи с другими ресурсами и действия, которые можно с
ним совершить)
• Слоистая архитектура (ни клиент ни сервер не должны знать как
происходят вызовы дальше систем с которыми они связаны
прямыми вызовами)
Большинство
современных
корпоративных
систем
написаны
с
использованием именно REST микросервисов, так как это надежно и
позволят легко масштабировать систему, соответственно при межсервисном
взаимодействии выбор падает в сторону REST сервисов.
Далее необходимо определиться с СУБД, посредством которой будет
осуществляться хранение локального кэша внутри микросервиса. В текущей
реализации в качестве СУБД было принято решение использовать
PostgreSQL. Дело в том, что современные тенденции зачастую предполагают
миграцию с MySQL на PostgreSQL. Связано это с определенными
преимуществами PostgreSQL:
1. PostgreSQL поддерживает более широкий спектр типов данных, в
нем можно хранить как массивы, JSON объекты и прочее. Помимо
хранения в PostgreSQL значительно проще работать с такими
типами данных
2. PostgreSQL на 2023 год имеет более совершенный оптимизатор
запросов, по сравнению с MySQL – он позволяет работать с
большими наборами параметров, что позволит уменьшить скорость
обработки запросов в БД
3. PostgreSQL имеет более совершенную систему индексирования, что
также позволяет лучше оптимизировать запросы к БД
4. Опции управления транзакциями в MySQL более ограничены по
сравнению с PostgreSQL
30
5. Согласно последним исследованиям DB engines Ranking все больше
новых проектов делаются с использованием PostgreSQL(рис. 2.4)
Рисунок 2.4. Оценка использования PostgreSQL относительно MySQL
Более того общая тенденция в компании предполагает использование
PostgreSQL в качестве СУБД. В самой базе данных хранятся JSON объекты,
так как намного проще их обновлять из Kafka просто добавляя новый JSON
поверх существующего, а также такое хранение позволит разработать
универсальные методы POST при которых потребитель в запросах сможет
указывать набор атрибутов, которые ему нужны на выходе.
В качестве программного средства для обновления данных в локальной
БД выступает распределенный брокер сообщений Kafka. Брокеры сообщений
преобразуют сообщения от разных формальных протоколов обмена
сообщениями, позволяя взаимозависимым службам напрямую «общаться»
друг с другом, даже если они написаны на разных языках или работают на
других платформах. Брокеры сообщений валидируют, маршрутизируют,
хранят и доставляют сообщения назначенным получателям, именуемым
консьюмерами. Брокеры действуют как посредники между приложениями,
позволяя продюсерам отправлять сообщения, не зная о количестве,
активности и местонахождении консьюмеров.
31
Pub/Sub или Publish/Subscribe – это схема распространения сообщений,
которая позволяет продюсерам публиковать любое необходимое сообщение,
а потребитель в свою очередь слушая топик, в который публикуется .
Зачастую когда речь идет о модели Pub/Sub встает выбор между двумя
решениями, а именно Kafka и RabbitMQ. В данной модели в качестве брокера
выступает Kafka, так как данная платформа позволяет работать с большими
объемами данных, которые хранятся в мастер системе, также позволяет легко
подключать новых потребителей путем подключения их к консьюмер
группам.
Также необходимо осуществлять балансировку запросов, путем
подключения сетевого балансировщика. Балансировка внешних запросов на
кластер Openshift производится внешним кластерным балансировщиком
запросов на базе F5 BIG-IP. Алгоритм балансировки – round robin, маршруты
с равной стоимостью. Балансировка входящей нагрузки на микросервис
осуществляется маршрутизатором HAProxy, балансировка внутри проектов
(NameSpace) кластера Openshift стандартными средствами Istio (Ingress
GateWay). Маршрутизатор HAProxy распределяет входящую нагрузку по
стратегии roundrobin – равномерное распределение запросов между
экземплярами микросервисов.
Service Mesh выступает в роли выделенного слоя инфраструктуры,
который используется для описания сети микросервисов и взаимодействия
между ними. Service Mesh платформенный компонент, устанавливаемый в
кластер OpenShift и дополняющий предоставляемый платформой OpenShift
функционал
или
в
кластер
Kubernetes
соотвественно.
Service Mesh позволяет решить задачи, возникающие в микросервисной
архитектуре приложения, такие как:
• Управление
трафиком:
(ROUND_ROBIN - алгоритм
циклу, LEAST_CONN
балансировка
распределения
- алгоритм,
по
нагрузки
круговому
который выбирает
хост
с
меньшим количеством активных запросов, RANDOM - алгоритм,
32
который
выбирает случайный
работоспособный
хост, PASSTHROUGH - переадресует соединение на исходный IPадрес,
запрошенный
вызывающим
абонентом), таймауты,
повторные попытки;
• Безопасность: автоматизированное безопасное соединение в
рамках межсервисного взаимодействия, при помощи mTLSсоединения, не требующее дополнительного конфигурирования
от микросервиса;
• Наблюдаемость: трассировка межсервисных взаимодействий,
агрегирование
показателей
успешности,
построение
топологических карт, мониторинг;
• Тестирование: канареечные релизы, зеркалирование запросов,
A/B-тестирование и другое.
В Service Mesh запросы маршрутизируются между микросервисами
через специальные прокси-серверы Envoy-proxy (istio-proxy), которые
перехватывают
и
работают
со
всем
входящим
и
исходящим
траффиком. Envoy-proxy (istio-proxy) добавляются к каждому определению
сервиса и развертываются в одном Pod с самим сервисом. Такой подход
позволяет динамически настраивать конфигурацию сети сервисов, не
затрагивая при этом код приложения. Всю логику по регулированию
взаимодействия между сервисами берет на себя Service Mesh, позволяя
разработчикам сосредоточиться на своих бизнес-задачах.
Для мониторинга проблем быстродействия сервисов, их возможной
неправильной
настройки,
используется
инструмент
распределенного
трейсинга Jaeger, который позволяет централизованно отслеживать весь граф
взаимодействия сервисов внутри Service mesh.
Для мониторинга и сбора метрик в Service Mesh используется
Prometheus, который собирает метрики с системных компонентов Service
Mesh и прикладных подов, развернутых в Service Mesh.
Для проверки работоспособности приложений используется механизм
33
health check. Компонент Openshift под названием kubelet, отвечающий за
запуск и управление контейнерами, проверяет состояние приложений через
специальные liveness и readiness проверки.
ReadinessProbe используются для того, чтобы узнать, готов ли
контейнер. Они позволяют убедиться, что приложение произвело все
необходимые для запуска действия и готово принимать трафик, или
выполнять другую работу. После того, как ReadinessProbe начинают
выполняться успешно, приложение считается готовым и на него начинает
поступать трафик. Если Pod не готов, он удаляется и создается новый.
Liveness probes помогают Kubernetes понять, когда пришло время
перезапустить контейнер (если приложение внутри контейнера не может
корректно работать). Перезапуск контейнера в таком состоянии помогает
сдвинуть приложение с мертвой точки, несмотря на ошибки.
Важный атрибут в проектировании интероперабельных интерфейсов
является
журналирование.
В
таблице
2.1
приведены
данные
о
журналировании.
Таблица 2.1. Журналирование сервиса.
№
1
Объект
протоколиро
вания
Протоколиру
емые
события
Формат
протокол
а
Средство
место
хранения
Интеграцион
ный
микросевис
Контрольны
е
точки
методов
JSON
Elasticsearch
СС
Журналиро
вание
Ошибки
Отладочная
информация
СУБД
PostgreSQL
2.3.
Определяетс
я
настройками
СУБД
Доступ к
журналу
Глубина
хранения
(Роли)
Прикладно
й
администр
атор
Не менее
5 лет
DevOps
инженер
ИС
Запросы
2
/
Определя
ется
настройк
ами
СУБД
Определяет
ся
настройкам
и СУБД
Администр
атор СУБД
Определя
ется
настройк
ами
СУБД
Техническое обеспечение
В качестве контейнерных служб внутри СУБО используется платформа
34
управления контейнерами на базе RedHat Openshift v4. В контейнерах
запускаются и работают сервисы приложения, реализующие бизнес-логику, а
также вспомогательные службы подсистемы логирования и трассировки
запросов и адаптеры интеграционных сервисов.
Приложение
разворачиваются
в
контейнер
openshift.
Внутри
контейнера создаются экземпляры приложения с необходимым сайзингом.
Таблица 2.2. Параметры обеспечения работы СУБО для контейнера
Openshift.
Квота на СУБО
CPU, ядер
RAM, GB
HDD, Gb
20
128
240
Используемые серверы и их параметры также приведены в таблице 2.3
Таблица 2.3. Используемые серверы и их параметры
Тип сервера
CPU
RAM, Gb
Назначение
1
Виртуальный
VMWare
8
32
Сервер БД PostgreSQL. Master DB
2
Виртуальный
VMWare
8
32
Сервер
БД
Slave DB (sync)
4
VM
2
8
Kafka, версия 2.13-2.4.1
PostgreSQL.
vsphere
2.4.
Организационное обеспечение
Для разработки микросервиса помимо технического и программного
обеспечения – необходимо организационное обеспечение информационной
системы,
которое
является
частью
технологического
обеспечения.
Организационное обеспечение представляет собой совокупность методов и
средств, регламентирующих взаимодействие работников с техническими
средствами в процессе разработки информационной системы.
Основная сложность данного метода состоит в поддержании единой
кодовой базы внутри всех экземпляров сервиса, так как зачастую бизнес
35
потребности могут меняться в зависимости от системы, в которой развернут
данный сервис – в связи с этим необходимо закрепить внутри организации
определенный регламент при котором будет четка определена зона
ответственности за интеграционный микросервис и формат взаимодействия
между командами, разрабатывающими бизнес функционал и командой,
поддерживающий и дорабатывающий в случае необходимости данный
интеграционный микросервис. Необходимо разработать регламент при
котором будет четко определена зона ответственности внутри команды
разработки
интероперабельного
программного
интерфейса.
Данный
регламент можно отобразить в виде матрицы ответственности RACI,
представленной в таблице 4. В данной таблице представлены несколько
ролей, которые присутствуют в команде разработки для выполнения задач.
Руководитель проекта – менеджер, занимает руководящую роль,
отвечает за сроки, бэклог и приоритезацию задач. Также отчитывается перед
руководством и принимает решения о том, берется ли та или иная доработка
или нет.
Аналитик – член команды, отвечающий за сбор и агрегацию
требований заказчика. Аналитик пишет техническое задание разработчикам
по итогу сбора требований, проектную документацию, а также контролирует
соответствие техническому заданию. Выступает в роли связующего звена
между заказчиками и ИТ командой
Разработчик – член команды, отвечающий за написание кода и
конечную реализацию микросервиса, разработчик покрывает тестами
большую часть функционала, а также является техническим центром
компетенции команды
Тестировщик
–
член
команды,
осуществляющий
тестирование
написанного кода, контроль за конечным качеством программного продукта,
а также тестовую документацию.
Архитектор – является независимым консультантом команды по
вопросам проектирования и соблюдения архитектурного стиля, принятого в
36
компании.
Таблица 2.4. Роли в матрице ответственности RACI
Обозначение
(R)
(A)
Расшифровка
Исполнитель
Описание
Непосредственно
(Responsible)
исполнение задачи.
Утверждающий
Ответственный за конечный результат. Член
(Accountable)
команды
ответственный
отчитывающийся
за
перед
руководством
(C)
Консультирующий
Консультирующий. Эксперт, занимающийся
(Consulted)
вопросами,
которые
входят
в его
компетенцию, дает советы команде.
(I)
Наблюдатель
Участник проекта, который должен быть
(Informed)
в курсе выполнения задачи.
37
Таблица 2.5. Распределение ответственности по RACI
Функциональные
Руководител
Аналити
Разработчи
Тестировщи
Архитекто
обязанности
ь
к
к
к
р
Построение плана AR
разработки сервисов
и
приоритезация
задач
Согласование плана A
C
I
I
C
I
I
I
I
Оценка задач на I
разработку
Постановка задач
A
R
C
C
-
R
I
I
-
R
I
I
C
C
C
-
AR
R
I
I
-
R
I
I
I
I
I
I
-
C
AR
I
-
проекта
Модуль планирования
Модуль реализации проекта
Сбор требований с I
заказчиков
Проектирование
I
решения
Написание
I
технического
задания/согласовани
е
технического
задания
Обеспечение
I
команды
проекта
необходимыми
информационными
материалами
(проектная
документация,
описание
конфигурационных
параметров,
описание основных
методов
сервиса,
моделей данных и
тд.)
Организация
R
коммуникации
между
членами
смежных команд
Разработка
информационного
решения
38
Продолжение таблицы 2.5
Контроль
I
соответствия
результатов проекта
Техническому
заданию
на
разработку ИС
Выявление
потенциальных
багов/тестирование
функционала
Написание тестовой I
документации
Организация
и A
проведение
программносдаточных
испытаний(ПСИ)
Модуль сопровождения
C
-
R
I
C
I
AR
-
C
-
AR
-
I
-
R
-
Передача заказчику
разработанного
программного
решения(проектная
документация)
Написание
инструкции
для
сотрудников
сопровождения
перед релизом
Релиз
программного
продукта
в
продакшн среду
Разбор аварийных
ситуаций
с
продакшн среды с
сотрудниками
сопровождения
A
R
-
I
-
-
R
C
I
-
A
C
R
-
-
A
R
R
C
-
матрица
позволит
Таким
образом
данная
разграничить
зону
ответственности каждого члена команды, что в дальнейшем позволит
избежать конфликтных ситуаций как между членами самой команды, так и
между командой и сторонними заказчиками в виде продуктовых бизнес
команд.
39
ГЛАВА
3.
Разработка
метода
проектирование
интероперабельных интерфейсов и его оценка
3.1.
Формирование метода проектирования
На основе ТЗ удалось спроектировать интеграционный микросервис,
удовлетворяющий требованиям заказчика, однако для решения научной
задачи
необходимо
сформировать
единую
методику
проектирования
интеграционных сервисов решающих задачи хранения корпоративных
данных, а также проксирования запросов внутри отдельного экземпляра
микросервиса. Данная методика позволит быстрее аналитикам проектировать
подобные микросервисы, путем следования по зафиксированному чек-листу.
Целью данной методики является снижение время проведения аналитики и
проектирования похожих микросервисах в других стримах и других
корпоративных
системах.
Количественно
оценивать
показатель
эффективности можно по целевой функции
T= min F(α1/α2), где T - показатель эффективности,
−
α1 - время, затраченное на проектирование интерфейса с
использованием методики;
−
α2 - время, затраченное на проектирование микросервиса без
методики.
Следуя чеклисту в таблице 3.1. аналитик сможет сократить время
проектирования микросервиса
Таблица 3.1. Метод проектирование интероперабельных интерфейсов
Цель стандарта
Организация
взаимодействия
внутри
одного
сервиса
Стандарт
Критичность Обяз-ть
Синхронное взаимодействие в одном Низкая
Обязательно
сервисе. При реализации синхронного
HTTP взаимодействия, включая one-way,
между микросервисами одного сервиса
Сервисной
платформы,
используется
ServiceMesh
40
Продолжение таблицы 3.1.
Синхронное взаимодействие в рамках одного Высокая Обязательно
namespace
Cинхронный HTTP вызов микросервиса в рамках
одного namespace осуществляется по локальной
ссылке – адресация осуществляется с помощью
полностью
квалифицированного
адреса
микросервиса внутри кластера, с указанием
локального имени кластера и порта.
Организация
взаимодействия
между сервисами
Унификация
протоколов
взаимодействия
my-service.ps1-rozb01Например
proj.svc.cluster.local:6666
Синхронное взаимодействие между разными
сервисами. При реализации синхронного HTTP
взаимодействия,
включая
one-way,
между
сервисами
Сервисной
платформы
используется.ServiceMesh.
Публикация-подписка. При реализации шаблона
публикации-подписки используется Kafka
Асинхронное взаимодействие. При реализации
шаблона
асинхронного
взаимодействия
используется
сегмент
асинхронных
взаимодействий приведенный в рисунке 5
Публикация-подписка, потоковая обработка.
Владение Инфраструктурным компонентом
(ИК). При реализации шаблона публикацииподписки владельцем брокера-сообщений является
владелец событий (публикатор).
Средняя
Обязательно
Средняя
Обязательно
Средняя
Обязательно
Средняя
Обязательно
При реализации шаблона потоковой обработки
владельцем брокера сообщений является системаобработчик событий (читатель)
Протокол взаимодействия для внутренних и Средняя
внешних API. Основной протокол взаимодействия
- https.
Для обмена файлами используются протоколы ftps,
sftp и fasp
41
Обязательно
Продолжение таблицы 3.1.
Унификация
протоколов
взаимодействия
Архитектурный стиль HTTP взаимодействия. Средняя Обязательно
Стиль синхронной HTTP интеграции выбран
владельцем прикладного сервиса в соответствии с
критериями:
•
Целевой основной архитектурный стиль
синхронных взаимодействий – REST
Формат данных должен быть структурирован. Средняя Обязательно
Формат данных JSON, YAML, XML.
Управление
изменениями API
Для обмена файлами – бинарный (base64 не
используется)
Несовместимые изменения API. Изменения Средняя Обязательно
спецификации, нарушающие принцип обратной
совместимости вынесены в отдельную новую
спецификацию с увеличенной «мажорной» версией
(с увеличенным старшим разрядом в номере версии
новой спецификации).
Совместимые изменения API. Изменения. Средняя Обязательно
вносимые поставщиком API, в минорной версии,
версии патча и/или сборки не должны нарушать
обратную совместимость API
Уведомление об изменении или подключении к Средняя Обязательно
API.
При изменениях API (как совместимых, так и
несовместимых) потребители API уведомлены.
При подключении потребителя к API поставщик
API уведомлен.
(Процедура уведомления определяется владельцем
Реестра API.)
42
Продолжение таблицы 3.1.
Унификация
интеграций
посредством API
Формат взаимодействия
внутренних и внешних API.
платформ Высокая Обязательно
При синхронном взаимодействии по REST
учитываются ограничения:
•
•
Унификация
файлового обмена
для
передача не более 1 Мб
время получения ответа на запрос, для
вызывающей стороны не превышает 40
секунд, с учетом всех участников
взаимодействия (таймаут - 40 секунд)
Правила файлового обмена
Высокая Future
Определение что такое файл - любая бинарная
информация, отличающаяся от форматов json,
xml, yaml, передающаяся через любой транспорт.
Примеры того, что часто маскируют не под
файл:
•
•
•
Межсервисная
аутентификация
Выбор СУБД
любое поле контракта или заголовка в
кодировке base64
цифровая подпись в одной из строк
контракта, заголовка или отдельным
файлом
разделение файла на части (chunk), чтобы
уложиться в ограничения по объему
сообщения (пример 1мб)
Для синхронных взаимодействий на основе Высокая Желательно
протокола HTTP внешние или внутренние
сервисы необходимо реализовать механизм
межсервисной аутентификации на основе JWT
токена
Для реализации кэша – использовать СУБД Средняя Обязательно
PostgreSQL
43
Продолжение таблицы 3.1.
Кэширование
Для принятия решения о необходимости Средняя
кэширования
данных,
поступающих
в
интеграционный сервис от мастер системы –
необходимо посчитать количество запросов в
секунду (RPS), поступающих от всех
продуктовых сервисов.
•
•
Обязательно
RPS >10 – реализовать кэширование
RPS<10 – проксировать все запросы в
мастер систему
Конфигурирование
Необходимо
предусмотреть
механизм
конфигурации при котором в зависимости от
значений
конфигурационных
параметров
сервис будет работать как прокси без кэша,
так и с созданием локальной БД для
кэширования запросов
Преимущественно хранить целый JSON,
полученный от мастер систем.
Унификация
Для поиска всех полей записи по
проектирования
определенному
классификатору
(id)
методов
использовать GET методы
Для реализации потребности бизнес заказчика
в выводе конкретных полей из хранимой
сущности – реализовывать POST запросы с
возможностью передачи внутри тела запроса
необходимых полей
В случае, когда в методе предполагается
фильтрация – реализовывать POST методы
Разделение бизнес - Вся бизнес - логика реализуется на стороне
логики
и продуктовых
сервисов,
интеграционный
интеграционной
адаптер не реализует бизнес - логику, а
функции
является лишь прокси системой хранения
актуальных данных. В интеграционном
адаптере не реализуются методы, содержащие
какую - либо бизнес - логику.
Единая
зона Разработку и сопровождение сервиса ведет
ответственности
определенная команда, ответственная за ИС.
Не допускать размытия ответственности.
44
Низкая
Желательно
Низкая
Желательно
Низкая
Желательно
Низкая
Желательно
Низкая
Желательно
Высокая Обязательно
Высокая Обязательно
Продолжение таблицы 3.1.
Разделение
Каждый интеграционный адаптер относится к Высокая Обязательно
адаптеров по бизнес конкретной бизнес - сущности. В случае, если
- сущностям
бизнес -сущность не соотносится с данными
хранимыми в адаптере – принимается решение о
создании нового адаптера
Пример:
Для работы с данными организаций – адаптер int
org, хранящий данные только относящиеся к
организациям,
для
работы
с
данными
физических лиц – адаптер int person, для работы
со справочниками – адаптер int dictionary
Для систем любого класса реализовано Высокая Обязательно
журналирование основных событий
Каждая запись логов содержит следующую Высокая Обязательно
информацию:
Обеспечение логов
полнотой
информации
для
анализа обращений
и разбора аварий
•
•
•
•
•
•
•
•
•
•
дата и время события
идентификатор (имя) сервиса
уровень логирования
название исполняемого метода
текст сообщения
идентификатор выполняемого запроса
идентификатор клиента, по которому
выполняется операция (при наличии)
идентификатор клиентской сессии (при
наличии)
информацию
по
системе,
инициировавшей выполнение метода
хост, на котором обрабатывается запрос
45
Продолжение таблицы 3.1.
При вызове сервиса системы вызывающая Высокая Обязательно
сторона передаёт в вызываемую систему:
•
•
•
идентификатор
вызывающей
системы/компоненты
индентификатор запроса
идентификатор клиента, для которого
выполняется бизнес операция (при
наличии)
идентификатор сессии клиента (при
наличии)
Обеспечение
логов
•
полнотой
информации
для
анализа обращений и
разбора аварий
Указанная информация отражается в логах.
В
журналах
логов
ИС
присутствует Высокая Обязательно
идентификатор, позволяющий отфильтровать
все логи по выполняемому запросу. Этот же
идентификатор может быть использован для
поиска логов других ИС, вызываемых в рамках
запроса
Определены и передаются в систему Высокая Обязательно
мониторинга метрики диагностики состояния
компонентов/модулей
Информационной
системы:
•
Использование
мониторинга
для
своевременного
выявления
и
локализации
аварийных ситуаций
•
•
Ошибки
во
время
работы
компонентов/модулей
ИС
(факт
возникновения ошибки, с указанием
времени, типа / уровня критичности и
описания ошибки).
Доступность компонентов/модулей ИС.
(проверка
статуса
службы/сервиса/компонента)
Обработка операций/данных внутри ИС
(факт
обработки;
количественные
показатели
работы
компонентов/модулей
в
единицу
времени, если применимо).
46
Продолжение таблицы 3.1.
Определены и передаются в систему Высокая Обязательно
мониторинга метрики по доступности
смежных систем, от которых зависит
предоставляемый сервис ИС и с которыми
происходит взаимодействие (для каждой
смежной системы):
•
Количественные
показатели
успешных или неуспешных вызовов
смежных ИС в единицу времени
Определены и передаются в систему Высокая Обязательно
мониторинга метрики на основании которых
можно сделать вывод о выполнении системой
своих функций:
Использование
мониторинга
для
своевременного
выявления
и
локализации
аварийных ситуаций
•
Наличие ошибок при выполнении
функций ИС (факт возникновения
ошибки, с указанием времени, типа /
уровня критичности и описания
ошибки)
По каждому серверному и клиентскому Высокая Обязательно
SSL/TLS сертификату, который используется
в ИС для установки безопасного соединения,
настроен мониторинг времени до истечения
срока действия сертификата
По каждому сертификату ИС передает в
систему мониторинга:
•
•
•
название компоненты (например, имя
сервиса), использующей сертификат
имя сертификата
время до истечения срока сертификата
(в секундах)
47
Продолжение таблицы 3.1.
Стабильность работы При
развертывании
сервиса
сервисов
в OpenShift/Kubernetes
реализованы
OpenShift/Kubernetes
настроены Liveness & Readiness probe
в Высокая Обязательно
и
liveness отвечает за "здоровье" внутреннего
состояния приложения. Если эта проверка
провалена - значит приложение само по себе
в некорректном состоянии и не может из него
восстановиться. В таком случае, обычно,
предполагается перезапуск приложения.
readiness отвечает за готовность принимать
клиентские запросы. Если эта проверка
провалена - kubernetes не будет направлять
трафик на этот экземпляр. Если экземпляр
слишком сильно нагружен - этой проверкой
можно временно отключить подачу трафика
на него.
Управление
Для сервисов, развертываемых в OpenShift, Высокая Обязательно
конфигурацией сервиса следующие конфигурационные параметры:
сопровождением
• уровень логирования
• параметры подключения к внешним
ресурсам и сервисам
• таймауты на установку соединения и
чтения ответа
• параметры работы батчей
вынесены в ConfigMaps, а информация по
учетным записям, паролям и сертификатам
вынесена в Secrets.
Отдельные экземпляры В различных системах разворачиваются Высокая Обязательно
сервиса
в
разных отдельные экземпляры сервиса с единой
системах
кодовой базой
Организация процедур Раз в календарный год необходимо Средняя Желательно
хаоскиппинга
организовать
процедуру
хаоскиппинга,
призванного увеличить производительность
запросов в локальной базе данных, путем
удаления исторических данных, которые не
используются в системе
Таким образом была решена научная задача – формирование методики
при проектировании интеграционных адаптеров, имея под рукой данную
методику – аналитик, совместно с разработчиком и DevOps инженером
способен значительно быстрее подготовить среду и спроектировать
интеграционный микросервис.
48
3.2.
Качественная оценка метода
Далее проведем качественную оценку метода выявив потенциальные
положительные и отрицательные характеристики предложенного метода. К
положительным сторонам предложенного метода можно отнести следующие
аспекты:
•
Единая кодовая база. Единая кодовая база позволяет упростить
дальнейшую
разработку
и
позволит
новым
разработчикам
быстрее
погрузиться в процесс в случае аварии на сторонней системе, также единую
кодовую базу проще поддерживать.
•
Отказоустойчивость.
Отказоустойчивость
всей
системы
повышается за счет того, что интеграционные адаптеры развернуты в разных
системах отдельными экземплярами сервиса, а не интеграционным слоем,
что позволяет:
o
в случае отказа мастер системы работать с кэшем накопленным в
этой системе.
o
В случае отказа одного из сервисов в одной системе – в другой
системе другой экземпляр данного сервиса будет работать исправно. Такого
уровня отказоустойчивости нельзя добиться, в случае проектирования
отдельного интеграционного слоя.
•
Единый
подход
к
проектированию
интеграционных
микросервисов. Наличие единой методики проектирования позволяет
сократить время аналитика и архитектора на проектирование нового
интеграционного микросервиса. Также в случае появления нового члена
команды, занимающейся интеграциями, данная методика позволит ему
быстрее освоится и влиться в устоявшийся рабочий процесс.
•
Масштабируемость.
В
случае
появления
новой
системы
контейнер с интеграционным сервисом просто разворачивается в этой
системе и путем минимальной настройки конфигурационных параметров
начинает полноценно функционировать
49
•
Единая зона ответственности. Нет размытия ответственности –
все доработки ведет одна команда и она отвечает за весь код и документацию
в едином стиле, что позволяет намного проще планировать дальнейшую
разработку и снизит нагрузку на продуктовые команды, которые занимаются
непосредственно доставкой бизнес-ценности до клиента
•
Снижение количества запросов в мастер систему. Основной
идеей данного подхода является накопление внутри каждого экземпляра
сервиса каждой системе достаточного объема бизнес-данных, которое
позволит минимизировать количество запросов в мастер систему, что
значительно повышает отказоустойчивость и скорость запросов внутри
системы, в которой развернут интеграционный адаптер. В дальнейшем
внутри
систем
будет
накоплен
кэш,
позволяющий
минимизировать
количество запросов в мастер систему.
•
Отсутствие избыточности данных. Каждая система накапливает
внутри экземпляра сервиса только те данные, с которыми работает, избегая
лишних и ненужных данных.
К отрицательным аспектам данного метода, по мнению автора можно
отнести:
•
Организация работ команды. При одновременном релизе в
нескольких системах требуется много времени команды на разборы боевых
аварий. В дальнейшем это время значительно сократится, путем отладки всех
аварийных ситуаций и накопления в локальной БД значительного объема
кэша, однако на первоначальном этапе команда может не успевать
одновременно
разрабатывать
новые
адаптеры
и
поддерживать
уже
разработанные. Также команда разрабатывающая микросервис является
единой точкой ответственности за кодовую базу – все доработки связанные с
расширением атрибутивного состава или появления новых методов ложатся
полностью на команду, соответственно команда будет выполнять большой
объем работ, что может привести к сдвигу сроков у бизнеса (так как появится
определенная очередь из работ, которые необходимо провести). Такой риск
50
является
основным,
для
его
решения
необходимо
привлекать
административный ресурс и либо временно расширить состав команды, либо
путем долгосрочного планирования дальнейших доработок выстроить
очередь из бизнес потребностей и приоритезировать запросы бизнеса.
•
Версионирование. Необходимо предусмотреть регламент при
котором при изменении версии сервиса в одной системе – необходимо
публиковать изменения в других системах, что ведет к необходимости
проведения регресс тестирования в других системах у продуктовых команд.
Таким образом была произведена качественная оценка предложенного
автором метода, так как данный метод был разработан путем практического
применения
и
положительных
аспектов
значительно
больше
чем
отрицательных, можно с уверенностью заявить о его жизнеспособности и
актуальности при применении в современной разработки в больших
корпоративных системах.
3.3.
Оценка экономической эффективности от внедрения метода
Организация и планирование работ по теме начинается с определения
участников реализации проекта.
Как было описано ранее для реализации микросервиса необходимо
привлечение команды с различными ролями в ней. Список ролей описан в
подглаве 2.3.
Для наглядной демонстрации продолжительности этапов разработки,
также участвующих в разработке исполнителей представлена Таблица 3.2.
51
Таблица 3.2. Этапы проектирования микросервиса
Этап
Количество
рабочих
Исполнитель
дней
Начало работ над ИС
1.1. Построение
плана
по
проектированию,
2
разработке, тестированию и
внедрению ИС
1.2 Формирование требований
3
бизнес заказчиков к ИС
1.3 Постановка задач
Реализация проекта
2.1
Сбор
требований
с
заказчиков
2.2
Заведение
заявок
на
получение доступа к мастер
системе
2.3 Проектирование решения
2.4 Написание технического
задания,
разработка
технической документации и её
согласование
2.5 Обеспечение
команды
необходимой документацией
3.1. Разработка ИС
2.7. Контроль
соответствия
разработки и технического
задания
2.8.
Выявление
багов
и
тестирование функционала
2.9. Исправление багов
2.10.
Написание
тестовой
документации
2.11. Организация и проведение
программно-сдаточных
испытаний (ПСИ)
Модуль сопровождения
3.1.
Передача
заказчику
разработанного программного
решения
3.2. Написание инструкции для
сотрудников
сопровождения
перед релизом
Руководитель
проекта
Сторонние
заказчики
Руководитель
проекта
1
2
Аналитик
1
Аналитик
10
Аналитик
10
Аналитик
1
Аналитик
12
Разработчик
1
Аналитик
10
Тестировщик
6
Разработчик
3
Тестировщик
4
Тестировщик
1
Аналитик
2
Аналитик,
Разработчик
3.3.
Релиз
программного
1
продукта в продакшн среду
Разработчик
52
Данный расчет был произведен в команде до введения полноценной
методики, описанной выше – при отсутствии полноценного метода каждый
член команды тратил на разработку и внедрение одного адаптера время,
представленное на таблице 3.3. Для полноценной оценки необходимо
рассчитать примерное количество средств затраченных на разработку одного
адаптера при помощи формулы дневной тарифной ставки. Дневная тарифная
ставка (ТС) для месячного оклада (ОК) может быть рассчитана следующим
образом:
ТС =
где
ОК × 12
руб./д,
НРВ
ОК — месячный оклад в компании
12 — число месяц в году;
НРВ — годовой фонд рабочего времени при сорокачасовой рабочей
неделе в 2023 г. В 2023 году он составил 247 рабочих дней
Таким образом расчитаем тарифную ставку для всех членов команды,
чтобы в дальнейшем высчитать стоимость разработки интероперабельного
интерфейса.
Таким образом тарифная ставка аналитика, при средней зарплате в
организации равной 250000 руб. будет равна:
ТС =
250000 × 12
247
= 12145 руб./д
Тарифная ставка руководителя проекта при средней зарплате в
организации равной 350000 руб. будет равна:
ТС =
250000 × 12
247
= 17004 руб./д
Тарифная ставка разработчика проекта при средней зарплате в
организации равной 300000 руб. будет равна:
53
ТС =
300000 × 12
247
= 14574 руб./д
Тарифная ставка тестировщика проекта при средней зарплате в
организации равной 230000 руб. будет равна
ТС =
230000 × 12
247
= 11174 руб./д
Таблица 3.3. Сумма затраченных средств на разработку адаптера до
появления методики
Член команды
Затраченное время(ч/д)
Затраты
на
оплату
труда
Руководитель проекта
3
51 012 руб.
Аналитик
26
315 770 руб.
Разработчик
20
291 480 руб.
Тестировщик
17
189 958 руб.
Итого
66
848 220 руб.
В итоге сумма затраченная на разработку одного адаптера без учета
технических средств составила около 848 220 руб. Далее построим такую же
таблицу уже с учетом внедрения метода, для проведения сравнительного
анализа по затратам. Время затраченное на разработку представлено в
таблице 3.4.
Таблица 3.4. Время, затраченное на разработку интероперабельного
интерфейса после введения методики
Этап
Количество
рабочих дней
Начало работ над ИС
1.2. Построение
плана
по
проектированию,
разработке, 2
тестированию и внедрению ИС
1.2 Формирование требований бизнес
3
заказчиков к ИС
1.3 Постановка задач
1
Исполнитель
Руководитель проекта
Сторонние заказчики
Руководитель проекта
Реализация проекта
2.1 Сбор требований с заказчиков
2
2.2 Заведение заявок на получение
1
доступа к мастер системе
Аналитик
Аналитик
54
Продолжение таблицы 3.4
2.3 Проектирование решения
2.4 Написание технического задания,
разработка технической документации
и её согласование
2.5 Обеспечение
команды
необходимой документацией
3.1. Разработка ИС
2.7. Контроль соответствия разработки
и технического задания
2.8. Выявление багов и тестирование
функционала
2.9. Исправление багов
2.10.
Написание
тестовой
документации
2.11. Организация и проведение
программно-сдаточных
испытаний
(ПСИ)
Модуль сопровождения
3.1.
Передача
заказчику
разработанного
программного
решения
3.2. Написание инструкции для
сотрудников сопровождения перед
релизом
4
Аналитик
6
Аналитик
1
Аналитик
8
Разработчик
1
Аналитик
7
Тестировщик
4
Разработчик
3
Тестировщик
4
Тестировщик
1
Аналитик
2
Аналитик,
Разработчик
3.3. Релиз программного продукта в
1
продакшн среду
Разработчик
Далее произведем похожу оценку стоимости разработки с учетом
расчитанных ранее тарифных ставок
Таблица 3.5. Сумма затраченных средств на разработку адаптера после
появления методики
Член команды
Затраченное время(ч/д)
Затраты
на
труда
Руководитель проекта
3
51 012 руб.
Аналитик
17
206 465 руб.
Разработчик
14
204 036 руб.
Тестировщик
14
156 436 руб.
Итого
48
617 949 руб.
55
оплату
Из
расчетов
мы
видим
снижение
времени
разработки
интероперабельного интерфейсе на 28 %, таким образом можно сказать о
том, что данная методика позволит при ее применении в процессе
проектирования сократить стоимость разработки и увеличить скорость
доставки бизнес-ценности для потребителя.
56
Заключение
В рамках магистерской работы были изучены существующие методы и
подходы
в
области
программных
проектирования
сервисов,
а
также
архитектуры
проведено
интероперабельных
исследование
проблем,
возникающих при построении единого информационного пространства
организации. На основе этих знаний был разработан метод проектирования
интероперабельных
функционирования
интерфейсов,
и
взаимодействия
учитывающий
сервисов
в
особенности
условиях
единого
информационного пространства. Предложенный метод был протестирован на
реальном
проекте
и
продемонстрировал
свою
эффективность
и
применимость.
В процессе ислледования были решены следующие задачи:
• Проведен сравнительный анализ архитектурных подходов к
проектированию интероперабельных интерфейсов;
• Была
сформирована
архитектура
интеграционного
сервис
адаптера и адаптер был спроектирован с использованием
современных технологий;
• Была
разработана
универсальная
методика,
позволяющая
упростить процесс аналитики и проектирования интеграционных
сервис адаптеров;
• Был оценен экономический эффект от внедрения метода.
Таким образом, на основании полученных результатов можно сделать
вывод о том, что разработанный метод проектирования интероперабельных
интерфейсов является актуальным и востребованным в современной
информационной
среде.
Работа
открывает
перспективы
дальнейшего
исследования в данной области и может быть использована в качестве
основы для создания новых эффективных систем в будущем.
57
Сonclusion
Within the framework of the master's work, existing methods and
approaches in the field of architecture design of interoperable software services
were studied, as well as a study of the problems arising in the construction of a
unified information space of the organization. Based on this knowledge, a method
for designing interoperable interfaces was developed, taking into account the
peculiarities of the functioning and interaction of services in a single information
space. The proposed method was tested on a real project and demonstrated its
effectiveness and applicability.
In the process of the investigation , the following tasks were solved:
• A comparative analysis of architectural approaches to the design of
interoperable interfaces has been carried out;
• The architecture of the integration service adapter was formed and the
adapter was designed using modern technologies;
• A universal methodology has been developed to simplify the process of
analytics and design of integration service adapters;
• The economic effect of the introduction of the method was evaluated.
Thus, based on the results obtained, it can be concluded that the developed
method of designing interoperable interfaces is relevant and in demand in the
modern information environment. The work opens up prospects for further
research in this area and can be used as a basis for creating new effective systems
in the future
58
Список используемых источников
1.
Головин С. А., Андрианова Е. Г., Гудкова О. К., Лаптев А. Н.
Методика формирования профилей стандартов информационных технологий
в интересах обеспечения интероперабельности сложных распределенных
систем // Журнал радиоэлектроники. 2014. № 12. С. 25. - URL:
http://jre.cplire.ru/jre/dec14/16/text.html (дата доступа: 21.10.2019).
2.
Макаренко Сергей Иванович, Олейников Александр Яковлевич,
Черницкая
Татьяна
Евгеньевна
Модели
интероперабельности
информационных систем // Системы управления, связи и безопасности. 2019.
№4.
URL:
https://cyberleninka.ru/article/n/modeli-interoperabelnosti-
informatsionnyh-sistem (дата обращения: 25.05.2023).
3.
Яковлевич,
Каменщиков Андрей Александрович, Олейников Александр
Широбокова
Тамара
Дмитриевна
Стандарты
интероперабельности в высокопроизводительной среде // Программные
системы:
теория
и
приложения.
2018.
№4
(39).
URL:
https://cyberleninka.ru/article/n/standarty-interoperabelnosti-vvysokoproizvoditelnoy-srede (дата обращения: 25.05.2023).
4.
условиях
Трубникова Е. И. Стратегии интероперабельности продукции в
интеграции
производителей
//
Вестник
Самарского
государственного экономического университета. 2010. № 12 (74). С. 84-89.
5.
Гришенцев А. Ю., Коробейников А. Г., Дукельский К. В. Метод
численной оценки технической интероперабельности // Кибернетика и
программирование.
2017.
№
3.
С.
4196.2017.3.23540.
59
23-38.
DOI:
10.25136/2306-
6.
Куприянов
А.
А.
Аспекты
интероперабельности
автоматизированных систем // Автоматизация процессов управления. 2009.
№ 4. С. 40-49.
7.
Кашевник
А.
М.
Подход
к
обеспечению
семантической
интероперабельности мобильных роботов при формировании коалиций //
Информационные технологии и вычислительные системы. 2017. № 1. С. 90100.
8.
Аристов
А.
В.
Обеспечение
интероперабельности
систем
формирования стандартизированных профилей // Вестник Воронежского
государственного технического университета. 2015. Т. 11. № 4. С. 40-43.
9.
Аникин
Д.
В.
Критерии
оценки
применения
интероперабельности, заданные условиями принятия решения // Вестник
МГСУ. 2013. № 10. С. 249257.
10.
Илюшин Г. Я., Соколов И. А. Организация управляемого доступа
пользователей к разнородным ведомственным информационным ресурсам //
Информатика и её применение. 2010. Том 4. № 1. С. 24-40. - URL: http :
//www. mathnet.ru/php/archive. phtml?wshow=paper&j rnid=ia&paperid=15&opti
on_lang=rus (дата доступа: 21.10.2019).
11.
ISO/IEC/IEEE 24765:2017. Systems and software engineering -
Vocabulary. - ISO, 2017. - 522 с.
12.
New European Interoperability Framework. Promoting seamless
services and data flows for European public administrations. - Luxembourg:
Publications Office of the European Union, 2017. - 48 с. - URL:
https://ec.europa.eu/isa2/sites/isa/files/eif_brochure_final.pdf
(дата
доступа:
21.10.2019).
13.
Программа фундаментальных исследований государственных
академий наук на 2013-2020 гг. Распоряжение Правительства РФ от 3 декабря
2012
г.
№2237-р
-
М.:
60
РАН,
2012.
-
URL:
http://www.ras.ru/FStorage/Download.aspx?id=62d335ba-2aea-4803-85eefd0cd37aba4b (дата обращения 19.10.2019).
14.
Steel J., Drogemuller R., Toth B. Model interoperability in building
information modelling // Software & Systems Modeling. 2012. Т. 11. № 1. С.
99109.
15.
Xu L. D., Li L., Xu E. L. Industry 4.0: State of the art and future
trends // International Journal of Production Research. 2018. Т. 56. № 8. С. 29412962.
16.
Aloi G., Caliciuri G., Fortino G., Gravina R., Pace P., Russo W.,
Savaglio C. Enabling IoT interoperability through opportunistic smartphone-based
mobile gateways // Journal of Network and Computer Applications. 2017. Т. 81.
С. 74-84.
17.
Rogers D., Harvey I., Evans K., Taylor I., Jones A., Huu T. T.,
Montagnat J., Glatard T., Kallel I., Harrison A. Bundle and pool architecture for
multi-language, robust, scalable workflow executions // Journal of Grid
Computing. 2013. Т. 11. № 3. С. 457-480.
18.
Jin Z., Chen Y. Telemedicine in the cloud era: prospects and
challenges // IEEE Pervasive Computing. 2015. Т. 14. № 1. С. 54-61.
19.
Системы управления,связи и безопасности №4. 2019
20.
Systems of Control, Communication and Security ISSN 2410-9916
21.
Lupçe O S., Vida M. M., Tivadar L. Cloud computing and
interoperability in healthcare information systems // The First International
Conference on Intelligent Systems and Applications. 2012. С. 81-85.
22.
Scholl H. J., Kubicek H., Cimander R., Klischewski R. Process
integration, information sharing, and system interoperation in government: A
comparative case analysis // Government Information Quarterly. 2012. Т. 29. № 3.
С. 313-323.
61
23.
Dai W., Guan X., Dubinin V. N., Christensen J. H., Vyatkin V.
Toward self-manageable and adaptive industrial cyber-physical systems with
knowledge-driven autonomic service management // IEEE Transactions on
Industrial Informatics. 2017. Т. 13. № 2. С. 725-736.
24.
Франгулова Е. В. Классификация подходов к интеграции и
интероперабельности информационных систем // Вестник Астраханского
государственного
технического
университета.
Серия:
Управление,
вычислительная техника и информатика. 2010. № 2. С. 176-180.
25.
Лукин И.В. Информационный менеджмент. Учебник-практикум.
- М.: Финансы и статистика, 2006.
26.
Гончаров А.А., Лысак Ю.Г. Интероперабельность программных
систем: основы и технологии. - М.: Изд-во МГТУ им. Баумана, 2014.
27.
Чеховский В.В. Технические средства и программные системы
автоматизации управления в промышленности. - М.: Финансы и статистика,
2004.
28.
Белоусов М.В. Информационная инфраструктура предприятия. -
М.: Финансы и статистика, 2008.
29.
Лукьянова Л.И., Мальцева Е.В. Моделирование информационной
инфраструктуры
организации.
-
СПб.:
Изд-во
Политехнического
университета, 2011.
30.
Шишкин В. Интероперабельность программных систем. - М.:
Финансы и статистика, 2003.
31.
Карпов
О.И.
Системный
подход
к
проектированию
информационной инфраструктуры организации. - М.: Финансы и статистика,
2010.
32.
Бродский М.Ю, Лунев М.Е. Архитектура программных систем:
учебное пособие. - М.: Изд-во МГУ, 2013.
33.
Сергеев Д.В., Насонов В.В. Информационные технологии
предприятий: учебное пособие для вузов. - М.: МГТУ им. Н.Э. Баумана,
62
2010.
34.
Кабакова
И.Н.,
Шеко
А.И.
Управление
проектами
в
информационных технологиях. - М.: Финансы и статистика, 2008.
35.
Мартишин, С.А. Проектирование и реализация баз данных в
СУБД PostgreSQLс использованием PostgreSQLWorkbench: Методы и
средства проектирования информационных систем и техноло / С.А.
Мартишин, В.Л. Симонов, М.В. Храпченко. - М.: Форум, 2018. – 61
36.
Саймон, Ригс Администрирование PostgreSQL 9. Книга рецептов
/ Ригс Саймон. - М.: ДМК Пресс, 2018. - 806 c
37.
Макин, Дж.К. Проектирование серверной инфраструктуры баз
данных Microsoft SQL Server 2005 / Дж.К. Макин. - М.: Русская редакция,
2018. - 560 c.
38.
Среднемесячная номинальная начисленная заработная плата
работников по полному кругу организаций по субъектам Российской
Федерации с 2013 года (по месяцам) [Электронный ресурс]. — 2023. URL:
https://rosstat.gov.ru/labor_market_employment_salaries
(дата
обращения:
25.04.2023)
39.
Управление проектами информатизации [Электронный ресурс]:
практикум / Т. В. Лентяева. — М.: РТУ МИРЭА, 2022. — Электрон. опт. диск
(ISO)
63