RU2733507C1 - Контейнерное развертывание микросервисов на основе монолитных унаследованных приложений - Google Patents

Abstract

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

Description

ОБЛАСТЬ ТЕХНИКИ, К КОТОРОЙ ОТНОСИТСЯ ИЗОБРЕТЕНИЕ

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

ПРЕДПОСЫЛКИ К СОЗДАНИЮ ИЗОБРЕТЕНИЯ

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

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

На ФИГ. 1А показаны элементы унаследованной платформы (100), в которой используется гипервизорная виртуализация. Аппаратное обеспечение (10) системы может включать, например, мэйнфрейм, запускающий гипервизор (30), зачастую в виде монитора виртуальных машин (z/VM) для создания набора полностью изолированных виртуальных машин (70), причем каждая машина имеет свою собственную гостевую операционную систему (OS), в которой, как правило, осуществляется выполнение программ. Гипервизор (30) создает платформу управления, разбивающую ресурсы хост-машины на набор виртуальных или гостевых машин (70), которые могут работать независимо в рамках унаследованной системы. Гостевая операционная система (40) или множество гостевых операционных систем (40) инсталлированы на виртуальных машинах. Далее на данной виртуальной машине осуществляется выполнение набора двоичных файлов и библиотечных программ (50) и одного или более приложений (60). Подобно физической машине виртуальная машина содержит ассоциированную информацию о состоянии оборудования, машину можно вернуть в исходное состояние или восстановить, и ей могут быть назначены ресурсы выделенной системы. Для запуска и останова виртуальной машины в системе гипервизора требуются значительные накладные расходы, и по этой причине, после установки виртуальные машины, как правило, продолжают функционировать в течение длительного времени выполнения программ.

На ФИГ. 1Б показан пример системы управления контейнерами (110). Аппаратное обеспечение (15) системы контейнеров может представлять собой физический сервер или кластер физических серверов, которые могут, например, представлять собой компьютеры на базе Х86. Ядро (25) хостовой операционной системы для систем, например, с Linux, совместно используется платформой, и набор контейнеров (75) запускается с помощью системы (35) управления контейнерами, такой как Docker. В частности, пространство имен и функциональность с-групп (контрольных групп) ядра Linux могут быть использованы для контейнеризации. Системы управления контейнерами могут быть представлены в виде оберток вокруг функциональностей ядра и могут обеспечивать управление контейнерами, например, развертыванием.

Могут быть использованы другие системы управления контейнерами, такие как Amazon ACS, Azure Container Service, Cloud Foundry Diego, CoreOS Fleet, Docker Swarm, Google Container Engine, или система управления контейнерами Mesosphere Marathon, или другая система управления контейнерами и оркестрирования контейнеров. Система управления контейнерами (35) и набор совместно используемых библиотек (85) операционной системы образуют платформу, в которой может быть выполнен набор контейнеров (75). Например, некоторые низкоуровневые библиотеки (35) операционных систем (35), такие как библиотеки, используемые для основных функций файлового ввода/вывода (I/O), могут совместно использоваться всеми контейнерами в рамках ядра операционной системы или системы управления контейнерами, а не являться резидентными в отдельных контейнерах.

Как и в случае с виртуальной машиной, набор двоичных файлов и библиотечных программ (55) и одно или более приложений (65) выполняются в наборе контейнеров (75). В качестве примера, библиотека, предоставляющая веб-сервисы доступа, такие как протокол http, может быть необходима только в некоторых приложениях, а не в других, и, таким образом, могла бы быть включена в библиотечные программы (55), если она потребуется для сервиса специфичных приложений, но может быть исключена из библиотечных программ (55) контейнера, в котором находятся только приложения, никогда не использующие сервис веб-доступа.

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

В частности, виртуальные машины имеют свою собственную операционную систему, файловую систему, процессор(-ы), сетевые адаптеры и тома ассоциативной памяти. Тот факт, что в виртуальных машинах функционирует гостевая операционная система посредством гипервизора, процесс исполнения виртуальной машины является тяжеловесным процессом, при этом увеличиваются накладные расходы в связи с работой двух операционных систем (гипервизор + гостевая операционная система), установленных одна поверх другой, который не может быть просто запущен и завершен с целью удовлетворения изменяющегося спроса на сервисы приложений. С другой стороны, контейнеры делят основные функции операционной системы за счет прямого доступа к ядру и иных физических ресурсов, включающих тома хранилища. Тома хранилища, как правило, являются резидентными на накопителях на фиксированном диске, но могут также содержаться в другом ЗУ большой емкости, включающем флэш-накопители, магнитную ленту или иные носители фиксированного или съемного хранилища. Несмотря на то, что поведение различных контейнеров может отличаться с учетом двоичных и библиотечных программ, встроенных в изображение, загруженное в указанные конкретные контейнеры, использование общих сервисов операционных систем существенно сокращает накладные расходы, связанные с каждым индивидуальным экземпляром контейнера. Ввиду этого, контейнеры являются облегченными по отношению к виртуальным машинам, что обеспечивает более реальное инстанцирование и завершение контейнеров в ответ на требования приложения. Действительно, например, в случае с системой управления контейнерами Kubernetes, в которой запущен Docker, контейнер может быть запущен за долю секунды. По этой причине крупное развертывание может запустить и завершить несколько тысяч указанных контейнеров каждую секунду.

Система управления контейнерами также может включать наборы (группы) контейнеров (Pod'ы). Pod является минимальной единицей развертывания в контейнерной системе, включающей один или более контейнеров, совместно развертываемых в одной и той же хост-системе или кластере. В некоторых системах управления контейнерами, такими как Kubernetes, контейнеры в Pod'e совместно используют сетевое пространство имен и пространство порта. Кроме того, тома общего хранилища, прикрепленные к Pod'y, могут быть установлены в одном или более контейнерах Pod'а.

Типичное распределение Linux включает десятки (даже сотни) тысяч отдельных файлов, и в зависимости от приложения, для которого используется такая система, может комбинироваться с тысячами дополнительных пакетов системы, придающих дополнительные функциональные возможности платформе. Примеры таких пакетов включают веб-сервер Apache, виртуальную машину Java, PostgreSQL или другие пакеты, обеспечивающие сопровождение базы данных или языковую поддержку и тому подобное. Указанные пакеты включают программный код и метаданные, описывающие пакеты и зависимости между пакетами и другими библиотеками. Совместно используемые библиотеки могут быть использованы динамически подключаемыми пакетами с целью обеспечения колоссальных функциональных возможностей, однако при этом они могут существенно увеличить потребление памяти, занимаемой образом Linux, и усложнить администрирование системой. Минимальный экземпляр Linux, включающий исключительно небольшое количество пакетов, может занимать только несколько мегабайт памяти. С другой стороны, большая инсталляция с множеством пакетов, используемых для сопровождения, например, веб-сервера крупномасштабного приложения с сервисом расширенной базы данных может занимать сотни мегабайт памяти или даже более. Администрирование платформ на операционной системе с ядром Linux зачастую предусматривает использование программного обеспечения диспетчера пакетов для управления зависимостями между пакетами и библиотеками и регулярного обновления указанных библиотек и пакетов. Большой образ, служащий для одновременного решения многочисленных задач, является более сложным в управлении, чем упрощенный образ.

Микросервисы, как правило, представляют собой небольшие автономные сервисы, которые могут тесно взаимодействовать друг с другом для обеспечения функциональности приложения. Автономный характер микросервисов обеспечивает их развертывание независимо друг от друга в виде изолированных сервисов, которые могут связываться с другими сервисами посредством вызовы в сети. Набор тесно связанных между собой микросервисов, либо микросервисов, которые в процессе своего функционирования имеют совместный доступ к общему тому, может быть развернут внутри одного и того же Pod'а. Архитектура микросервиса предоставляет важные преимущества управляемости, работоспособности, масштабируемости и развертываемости на кластерных системах. Тем не менее, ввиду монолитного характера многих унаследованных приложений, задача преобразования таких монолитных приложений в наборы минимально взаимозависимых микросервисов является сложной и трудоемкой. Проблему в большей степени усложняют унаследованные монолитные приложения, написанные на языке Cobol и скомпилированные для выполнения на унаследованных архитектурах, таких как MVS или z/OS, при этом их специальные программные интерфейсы в целом не могут быть экспортированы из унаследованной архитектуры запущены на выполнение в Linux или иной операционной системе или кластере, в частности, базирующихся на серверах х86, ввиду различий в наборе команд и программных интерфейсов.

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

КРАТКОЕ ИЗЛОЖЕНИЕ СУЩЕСТВА ИЗОБРЕТЕНИЯ

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

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

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

ii) анализатор журнала регистрации операций использует унаследованные журналы регистрации операций монолитного унаследованного приложения, генерируемые путем выполнения монолитного унаследованного приложения в унаследованной компьютерной среде;

iii) анализатор журнала регистрации операций использует эмулятор для выполнения монолитного унаследованного приложения для генерирования файлов журнала регистрации и для определения того, какие программы используются монолитным унаследованным приложением в процессе выполнения транзакций;

iv) анализатор исходного кода предназначен для использования информации из анализатора журнала регистрации операций для выявления векторов определения транзакций;

v) анализатор исходного кода дополнительно предназначен для создания множества трансляционных таблиц;

vi) оптимизатор определения микросервисов предназначен для дальнейшей оптимизации векторов определения микросервисов;

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

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

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

x) унаследованная компьютерная среда включает операционную систему Множества Virtual Storage (MVS) или z/OS;

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

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

xiii) система управления контейнерами предназначена для создания множества контейнеров;

xiv) набор комплементарных образов инстанцируются в отдельном контейнере в рамках общего Pod'а;

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

xvi) система управления контейнерами предназначена для изменения количества контейнеров в рамках множества контейнеров;

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

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

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

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

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

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

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

Способ дополнительно включает выполнение микросервиса или набора микросервисов в контейнере.

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

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

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

iii) включение анализатора журнала регистрации операций с использованием эмулятора для выполнения монолитного унаследованного приложения для генерирования файлов журнала регистрации и для определения того, какие программы используются монолитным унаследованным приложением в процессе выполнения транзакций;

iv) включение анализатора исходного кода с использованием информации из анализатора журнала регистрации операций для выявления векторов определения транзакций;

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

vi) дополнительную оптимизацию векторов определения микросервисов с использованием оптимизатора определения микросервисов;

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

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

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

x) включение в унаследованную компьютерную среду операционной системы Множества Virtual Storage (MVS) или z/OS.

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

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

xiii) создание множества контейнеров с использованием системы управления контейнерами;

ix) инстанцирование набора комплементарных образов в отдельном контейнере в рамках общего набора контейнеров (Pod);

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

xi) изменение количества контейнеров в рамках множества контейнеров системой управления контейнерами;

xii) распределением системой управления контейнерами изменяющихся ресурсов по отдельным контейнерам;

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

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

ФИГ. 1А - схематическое изображение среды гипервизорной виртуальной машины предшествующего уровня техники.

ФИГ. 1Б - схематическое изображение контейнерной виртуализированной среды, которая может быть модифицирована и использована в соответствии с настоящим изобретением.

ФИГ. 2А - схематическое изображение набора векторов программ, соответствующих транзакциям приложения.

ФИГ. 2Б - схематическое изображение набора векторов оптимизированных программ, соответствующих транзакциям приложения.

ФИГ. 3 - изображение компонентов масштабируемой контейнерной системы для разбиения монолитного унаследованного приложения на микросервисы.

ФИГ. 4 - изображение компонентов деревьев вызова для двух транзакций в монолитном унаследованном приложении.

ФИГ. 5 - изображение деревьев вызова для одних и тех же двух транзакций на ФИГ. 4, реализованных в виде микросервисов в масштабируемой контейнерной среде.

ФИГ. 6 - структурная схема, на которой изображены этапы способа проведения анализа монолитного унаследованного приложения для развертывания микросервисов в масштабируемой контейнерной среде.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

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

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

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

На ФИГ. 3 проиллюстрирована масштабируемая контейнерная система (300). Масштабируемая контейнерная система может включать репозиторий (305) для хранения исходного кода, в котором хранится исходный код монолитного унаследованного приложения. Исходный код монолитного унаследованного приложения может представлять собой, например, монолитное COBOL приложение, которое может включать десятки, сотни или даже десятки сотен отдельных файлов программы, предназначенных для выполнения раздельно или в группах сотен различных транзакций, T₁, Т₂,… Т_х. Примеры таких транзакций могут включать создание, обновление, перемещение или удаление записей абонента, которые могут, например, использовать Абонентскую информационно-управляющую систему («CICS») или Информационную систему управления («IMS») для выполнения транзакций реляционных баз данных (Database 2 («DB2»)) или транзакций иерархических баз данных (Язык интерфейса данных (DL/I)(«DL/I»)). Компилятор (310), компилирует исходный код в набор одного или более двоичных файлов, которые хранятся в бинарном репозитории (315).

В соответствии с конкретными вариантами осуществления настоящего изобретения анализатор (320) исходного кода, как правило, через компонент анализатора зависимостей анализирует исходный код и ассоциированные файлы в монолитном унаследованном приложении, хранящиеся в репозитории (305) для хранения исходного кода, и генерирует дерево кода, идентифицирующее взаимозависимости (вызывающая подпрограмма <> вызываема подпрограмма) в исходном коде. Предпочтительно, чтобы анализатор (320) исходного кода выполнял обход каждой транзакции монолитного унаследованного приложения, как определено в конфигурационных параметрах системы обработки транзакций, таких как CICS, IMS и т.д. В одном примере анализатор (320) исходного кода получает в качестве входных данных из репозитория (305) для хранения исходного кода файл, определяющий доступные определения транзакции Абонентской информационно-управляющей системы (CICS), которые могут быть инициированы пользователями при их взаимодействии с монолитным унаследованным приложением. Предпочтительно, чтобы указанный файл идентифицировал каждую транзакцию и ее корень, или первую программу, инициированную при выполнении транзакции. Файл может включать корневую программу в виде вызываемой подпрограммы команды EXEC CICS LINK, используемой во многих транзакциях. В указанном примере корневая программа относится к первой программе, вызываемой программой, обрабатывающей интерфейс (например, выполнение SEND/ ECEIVE MAPs в том случае, когда интерфейс является интерфейсом 3270, а также другие эквивалентные специальные программные интерфейсы, когда имеется другой интерфейс). Могут быть использованы другие файлы или форматы, определяющие транзакции или дополняющие их сервисы, например, дополнительные файлы построения могут включать файлы определений для ресурсов, используемых транзакцией, таких как очереди сообщений и источники данных.

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

Предпочтительно провести разбиение монолитного унаследованного приложения с целью разделения приложения на наборы доступных минимально взаимозависимых транзакций, например, с помощью протоколов SOAP или REST (с JSON или другим форматом данных). Каждая из минимально взаимозависимых транзакций может запускаться на выполнение в независимом экземпляре унаследованного эмулятора (325). Результатом работы анализатора исходного кода (320) может быть вызов программы, либо дерево включений, либо граф, определяющие для каждой транзакции полный набор программ, который может быть инициирован или использован при выполнении каждой транзакции, и вызывающая подпрограмма <> вызываемая подпрограмма или отношения включения между программами. На ФИГ. 4 представлен пример такого дерева вызовов, в котором первая транзакция Т1 начинается с корневой программы А, которая может затем вызвать программу F или программу D. Тем не менее, в транзакции Т1 программа D может затем вызвать программу Е. Вторая транзакция Т2 начинается с корневой программы В, которая затем может вызвать программу С или также вызвать ту же самую программу D, которая затем вызывает программу Е.

Дерево вызовов может быть преобразовано в набор векторов, по одному для каждой транзакции, или в определенный поднабор возможных транзакций монолитного унаследованного приложения, определяющего программу, которая может быть инициирована при проведении транзакции. На ФИГ. 2А показан пример набора (200) вектора определения транзакций, Та (210), Tb (220),…Тс (230). В указанном примере первый вектор, такой как Та (210), включает набор программ <Р1, Р2,…Рх>, потенциально вызываемых при проведении первой транзакции. На примере, приведенном на ФИГ. 4, транзакция может быть Т1, и указанный набор программ будет включать программы A, F, D и Е. На Также на ФИГ. 2А показаны второй иллюстративный вектор Tb (220), включающий программы <Р2, Р3,…Ру>, и третий иллюстративный вектор Тс (230), включающий программы <Р1, P6,…Pz>, соответствующие второй транзакции и третьей транзакции. Разное количество и различные комбинации программ могут обозначать различные транзакции монолитного унаследованного приложения.

Исходя из определения интерфейса корневой программы, анализатор (320) исходного кода также способен извлекать или генерировать типы данных, сообщения, форматы/привязки сообщений и наборы входных и выходных данных сообщений и определять адреса и конечные точки каждой транзакции и преобразовывать указанную информацию в структуру сообщения для использования при построении и определении интерфейса транзакции (-й) при предоставлении сообщения сборщику (330) контейнера и (или) системе (335) управления контейнерами, например как часть образа микросервисов. Кроме того, анализатор (320) исходного кода также способен генерировать интерфейс WSDL сообщений при использовании протокола SOAP. Интерфейс WSDL-сообщений может представлять собой отформатированный документ, определенный в стандарте W3C (Консорциум Всемирной паутины), включающем структуру для хранения определенных типов данных, сообщений, абстрактных операций portType, привязок, портов и информацию определения сервисов. Анализатор (320) исходного кода также способен генерировать другие представления сообщений интерфейса, если другие протоколы (REST и т.д.) и представления (JSON) являются предпочтительными для данной ситуации. Кроме того, анализатор исходного кода может быть сконфигурирован для генерирования двунаправленных трансляционных таблиц кодирования данных или процедур для преобразования UTF-символов в 8-битные EBCDIC символы и наоборот (или между наборами различных символов, включая ASCII), и подобная трансляция может быть реализована путем генерирования скрипта/программы, используемых с микросервисами на основе транзакций и на их интерфейсах по отношению к реквестеру.

Набор (200) векторов определения транзакций, определение коммуникационного интерфейса (WSDL, REST) и трансляционные директивы в скрипте могут храниться в репозиторий (340) определения состояний транзакций.

Анализатор (320) исходного кода может также включать часть перекодирующего приложения для представления пути транскодера к масштабируемой контейнерной системе для использования перекодированных программ. Таким образом, анализатор исходного кода также может быть использован для сопровождения перехода исходного кода с его исходного языка, такого как Cobol, на другой язык, такой как Java. Могут быть выполнены другие трансляции исходного кода. Более того, анализатор исходного кода (320) также может быть использован в форме автономной программы, не являющейся частью приложения для перекодирования.

Каждый вектор определения транзакций (210), (220), (230) в репозиторий (340) определения состояний транзакций включает расширенный набор программ, которые фактически инициированы в ходе выполнения фактических транзакций с использованием монолитного унаследованного приложения. Зачастую приложения транзакций содержат множество программ, которые никогда не и инициируются. Такая ситуация может быть обусловлена исходной архитектурой приложения транзакций, изменениями структуры, изменением вариантов использования, совместным использование программ и их вызываемых подпрограмм в различных частях приложения транзакций или иными процессами изменений приложения транзакций. Включение указанных неиспользуемых программ в код приводит к снижению эффективности контейнеризированного приложения по ряду причин, включающих накладные расходы, необходимые для перемещения с места на место на постоянном запоминающем устройстве, загрузку неинициируемых программ в память центрального компьютера и их выгрузку из него, а также дополнительные задержки с компилированием, сборкой или транспортировкой по сети к контейнерам транзакций. Для удаления указанных неиспользуемых программ из образов приложения микросервисов оптимизатор (345) определения микросервисов извлекает вектор определения транзакций, определение интерфейса и таблицы трансляций из репозитория (340) определения состояний транзакций и применяет вектор динамических определений, хранящийся в репозиторий (350) динамических определений, для удаления неиспользуемых программ, включенных в векторы (210), (220), (230) определения транзакций репозитория (340) определения состояний транзакций с целью достижения соответствующих векторов (260) (270), (280) определения микросервисов, как показано на ФИГ. 2Б, которые могут храниться в промежуточном состоянии оптимизатором определения микросервисов (345) в ожидании дополнительного уточнения и определения микросервисов, либо могут обрабатываться построителем (350) образов микросервисов для создания образов микросервисов, хранящихся в репозиторий (355) образов микросервисов. Как правило, в большой монолитной системе унаследованного приложения будут находиться неиспользуемые программы, которые могут быть удалены подобным образом. Тем не менее, для транзакций, использующих все из программ, идентифицированных путем проведения статического анализа состояния транзакций, вектор определения микросервисов будет такими же, как и начальный вектор определения транзакций. Это проиллюстрировано на примере вектора (220) определения транзакций на ФИГ. 2А и соответствующего вектора (270) определения микросервисов на ФИГ. 2Б.

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

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

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

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

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

В некоторых системах анализатор журнала (365) регистрации операций может использовать информацию как из унаследованных журналов (360) регистрации операций, так и из унаследованного эмулятора (325) для определения того, какие программы фактически используются транзакциями в монолитном унаследованном приложении. Например, если унаследованные журналы (360) регистрации операций не содержат примеры программы, используемой в данной транзакции, можно обратиться за информацией к журналам из унаследованного эмулятора (325), либо можно не обращаться до вынесения заключения о том, что программа не используется данной транзакцией. В другом примере оценку транзакций, в отношении которых имеется более чем достаточный объем унаследованных данных, осуществляют, используя только унаследованные журналы (360) регистрации операций без дополнительной эмуляции унаследованным эмулятором (325). Еще в одном примере унаследованные данные журнала могут быть использованы в качестве исходного ключа к определению микросервисов.

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

Загрузочный модуль относится ко всей исполняемой программе или ее части, как правило, в контексте унаследованной компьютерной среды мэйнфрейма. Унаследованный эмулятор (325) может быть эмулятором, разработанным для выполнения скомпилированного унаследованного приложения или загрузочного модуля из z/OS или другой унаследованной компьютерной среды для выполнения в другой компьютерной среде, такой как платформа х86 с операционной системой Linux. Унаследованный эмулятор может конвертировать каждую собственную команду или вызов сервиса собственной операционной системы исходной выполняемой программы в эквивалентные команды и вызовы систем другой компьютерной среды. Унаследованный эмулятор (325) может реализовать набор собственных прикладных программных интерфейсов с целью эмуляции отдельных унаследованных команд или системных вызовов сервисов. Унаследованный эмулятор (325) может представлять собой единственный образ всего эмулятора, или он может включать разделенные образы, как изложено ниже в настоящем документе. Унаследованный эмулятор (325) может дополнительно включать или иметь управляемый доступ к операционной системе или ее компонентам, фактически используемым унаследованным эмулятором.

Оптимизатор (345) определения микросервисов применяет векторы динамических транзакций, хранящиеся в репозитории (370) динамических определений, к векторам определения транзакций, хранящимся в репозитории (340) определения состояний транзакций для получения векторов определения микросервисов, которые могут быть использованы построителем (350) образов микросервисов для создания образов микросервисов. Указанные образы затем хранятся в репозиторий (355) образов микросервисов.

На Фиг. 2Б показан пример набора (250) векторов определения микросервисов MSa (260), MSb (270),…MSc (280). В указанном примере первый вектор определения микросервисов Msa (260) включает оптимизированный вектор, выполненный из набора программ<P1b,…Px-qb>, которые вызываются при выполнении первой транзакции Та. В указанном примере программа Р2 фактически не используется в транзакции Та и, следовательно, удаляется из вектора определения микросервисов. Второй иллюстративный вектор (270) определения микросервисов MSb включает программы<Р2, Р3,…Ру>. В указанном примере все программы, которые составляют вектор определения транзакций, используются и, следовательно, сохраняются в векторе определения микросервисов. Третий иллюстративный вектор (280) определения микросервисов MSc включает программы <Р1, P6,…Pz-y>. Полученная архитектура включает набор транзакций Тх, каждая из которых определена наименьшим числом программ. Любая из транзакций Тх монолитного унаследованного приложения может быть определена как независимо вызываемый микросервис MSx, как в транслированной операции предшествующего монолитного унаследованного приложения, так и в расширенных или модифицированных приложениях, которые могут инициировать определенные микросервисы MSx.

Любая из транзакций Тх также может быть определена как набор независимо вызываемых микросервисов. Для полного набора транзакций Тх из монолитного унаследованного приложения некоторый поднабор может быть определен одним микросервисом на транзакцию, в то время как другой поднабор может быть определен набором микросервисов на транзакцию. Например, как проиллюстрировано на ФИГ. 5, если транзакции Т1 и Т2 используют общие программы D и Е при преобразовании указанных транзакций в микросервисы оптимизатором (345) определения микросервисов, указанные общие программы могут быть сгруппированы в виде независимого микросервиса MS3, который может быть вызван MS1, содержащим другие программы Т1, или может быть вызван MS2, содержащим другие программы Т2.

Оптимизатор (345) определения микросервисов может хранить векторы образов микросервиса или промежуточные векторы образов микросервисов, которые оптимизатор в дальнейшем дополнительно изменяет или оптимизирует. Например, оптимизатор (345) определения микросервисов при представлении с векторами определения транзакций для транзакций на ФИГ. 4, может начала создавать промежуточные векторы определения микросервисов MS1 и MS2, оба из которых содержат программы, также размещенные в векторах определения транзакций. Оптимизатор (345) определения микросервисов может распознавать общий компонент указанных векторов определения микросервисов MS1 и MS2, как показано элементами D и Е на ФИГ. 4, и выделять общий компонент из первых двух векторов определения микросервисов. Как показано на ФИГ. 5, дополнительно к первым и вторым микросервисам MS1 и MS2 общие элементы D и Е используются для создания третьего вектор определения микросервисов MS3, который содержит указанные общие компоненты и который может быть вызван MS1 или MS2. Указанные оптимизированные векторы определения микросервисов MS1, MS2 и MS3 затем предоставляются построителю (350) образов микросервисов.

В альтернативном варианте промежуточные векторы определения микросервисов могут храниться в другом месте, кроме оптимизатора (345) определения микросервисов, например, в промежуточном репозиторий (не показан). В некоторых вариантах осуществления настоящего изобретения промежуточные векторы определения микросервисов могут храниться в построителе (350) образов микросервисов или в виде промежуточных образов - в репозитории (355) образов микросервисов, и далее к ним может быть обеспечен доступ и (или) они могут быть заменены оптимизированными векторами определения микросервисов или образами микросервисов.

Компилятор (310) компилирует исходный код в репозитории (305) для хранения исходного кода для создания двоичных файлов в бинарном репозитории (315). Компилятор (310) генерирует двоичные файлы для унаследованной компьютерной среды, такой как система 390 или z/OS мэйнфрейма. Таким образом, двоичные файлы, используемые для построения образов микросервисов в масштабируемой контейнерной системе, описание которой приведено в настоящем документе, могут быть аналогичными двоичным файлам, выполняемым в унаследованной компьютерной среде, способствуя интероперабельности и постепенной миграции монолитного унаследованного приложения из унаследованной компьютерной среды в масштабируемую контейнерную систему.

Построитель (350) образов микросервисов извлекает скомпилированные двоичные файлы из бинарного репозитория (315), которые соответствуют программам, идентифицированным в векторах определения микросервисов или в оптимизированных векторах определения микросервисов, при необходимости и комбинирует двоичные файлы для генерирования образа для каждого микросервиса, включающего двоичные образы для каждой программы, в векторе определения микросервисов. Образы микросервисов могут также включать ассоциированные артефакты и информацию, такие как определения совместно используемого ресурса и т.д., извлеченные построителем (350) образов микросервисов. Указанные образы микросервисов хранятся в репозиторий (355) образов микросервисов.

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

Может быть осуществлено разбиение унаследованного эмулятора на функции или поднаборы функций для формирования унаследованных элементов, которые создают преимущества для развертывания унаследованного эмулятора в контейнерной системе, описание которой приведено в настоящем документе. Например, поддержка для поднаборов команд на интерфейсах, поддерживаемых унаследованным эмулятором, может быть разделена. Кроме того, может быть проведено разбиение поддержки в унаследованном эмуляторе для групповых операций, для сервисов транзакций CICS, DB2 или иных сервисов реляционных баз данных, сервисов IMS, безопасности, регистрации и других функциональных возможностей. Таким образом, только отдельный унаследованный элемент или набор элементов унаследованного эмулятора, используемые микросервисами в контейнере, могут выполняться внутри конкретного контейнера. Кроме того, определенные унаследованные элементы, используемые контейнерами в Pod'e, могут храниться в отдельных контейнерах, к которым в дальнейшем могут обращаться микросервисы в других контейнерах в Pod'e. Подходящие унаследованные элементы включают функции трассировки и регистрации среды выполнения эмулятора. Такая настройка может повысить производительность и (или) безопасность системы.

Репозиторий (380) комплементарных компонентов может также хранить пакеты программного обеспечения из операционной системы, которые может использовать унаследованный эмулятор и которые можно называть элементами ОС. Например, компоненты API отдельной системы также могут храниться по отдельности как отдельные образы. В некоторых примерах отдельные пакеты и файлы библиотек могут быть объединены в процессе выполнения для повышения функциональных возможностей, обеспечиваемых Linux или другой операционной системой, и двоичные файлы могут храниться в репозитории (380) комплементарных компонентов.

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

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

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

Включение не всех элементов ОС в контейнер или в контейнер в Pod'e может аналогичным образом сократить объем памяти, используемый для хранения контейнера или Pod'а в пять-семь раз по сравнению с идентичным контейнером или Pod'ом, содержащим образ полной ОС или элементы ОС, не используемые микросервисами, и (или) элементы эмулятора в контейнере или Pod'e.

Включая не все элементы эмулятора и не все элементы ОС в контейнер или в контейнер в Pod'e, объем памяти, используемый для хранения контейнера или Pod'а, может также быть сокращен в пять-семь раз по сравнению с идентичным контейнером или Pod'ом, содержащим образ всего унаследованного эмулятора или элементы эмулятора, не используемые микросервисами в контейнере или Pod'e, и образ полной ОС или элементы ОС, не используемые микросервисами, и (или) элементы эмулятора в контейнере или Pod'e. В этом случае относительные вклады уменьшения размера унаследованного эмулятора и размера операционной системы в сокращение объема памяти, используемого для хранения сочетания указанных двух объектов, может зависеть от относительных общих размеров унаследованного эмулятора и операционной системы и степени разбиения обоих. Например, в случае разбиения унаследованного эмулятора с оперативной памятью 200 МБ на приблизительно десять элементов и операционной системы с оперативной памятью 50 MB на приблизительно пятьдесят элементов вклады в удаление элементов эмулятора, как правило, перевесят вклады в удаление элементов операционной системы.

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

Также может быть проведено разбиение унаследованного эмулятора для размещения основных функциональных возможностей, используемых другими компонентами унаследованного эмулятора, в основной элемент эмулятора. Такой элемент может быть включен в большинство, если не во все контейнеры или Pod'ы. Зачастую указанный основной элемент эмулятора будет составлять значительную долю от размера всего унаследованного эмулятора по сравнению с другими элементами эмулятора. Например, размер основного элемента эмулятора может составлять от 30% до 40% от размера всего унаследованного эмулятора.

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

При использовании транзакционного эмулятора в качестве примера подходящие элементы эмулятора также могут включать онлайновый/коммуникационный элемент эмулятора (в частности, элемент, содержащий подпродукты для CICS и IMS-TM для транзакционных сервисов), реляционный элемент эмулятора (в частности, один для DB2), элемент иерархических баз данных эмулятора (в частности, элемент для IMS-DB), элемент наборов данных/управления данными эмулятора (в частности, элемент для VSAM файлов и файлов с последовательным доступом), элемент пакетных сервисов эмулятора, и (или) элемент языков эмулятора (в частности, элемент с подпродуктами для Cobol и PL/1), элемент безопасности эмулятора и элемент пользовательского интерфейса/консоли управления эмулятора.

Подпродукты могут быть исключаемыми из образа элемента эмулятора, фактически встроенного в контейнер. Например, онлайновый/коммуникационный элемент эмулятора может содержать только двоичные образы для CICS, а не для IMS-TM.

Элементы эмулятора могут различаться по размеру по сравнению с полным размером унаследованного эмулятора, но, как правило, размер каждого из неосновных элементов эмулятора может составлять от 1% до 20%, в частности, от 3% до 15% от полного размера унаследованного эмулятора. Размер элемента эмулятора по сравнению с полным размером унаследованного эмулятора наряду с другими факторами, такими как вероятность совместного использования, может быть использован при определении того, какие функциональные возможности разделены на различные элементы эмулятора.

Элементы ОС могут быть в формате доступных пакетов, таких как различные пакеты Linux, например, PostgresSQL, LLVM, node.js, и т.д.

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

В некоторых масштабируемых контейнерных системах сборщик (375) контейнера включает компилятор загрузочного модуля, который принимает в качестве входных данных двоичные файлы, такие как исполняемые файлы образов операционных систем System 390 или z/OS, хранящиеся в репозитории (355) образов микросервисов. Компилятор загрузочного модуля обнаруживает все сигнатуры в двоичных файлах вызовов программ, сервисов или функций унаследованной компьютерной среды монолитным унаследованным приложением, такие как набор команд ассемблера. Компилятор загрузочного модуля может использовать указанную информацию для определения функций унаследованного эмулятора, используемых микросервисом или набором микросервисов. Сборщик (375) контейнеров может далее размещать элементы эмулятора, способные выполнять указанные функции среди элементов эмулятора в репозитории (380) комплементарных компонентов и размещать в образе контейнера элементы эмулятора наряду с любыми ассоциированными элементами ОС из репозитория (380) комплементарных компонентов с образами микросервисов или набором образов микросервисов. В альтернативном варианте сборщик (375) контейнера будет размещать образы элементов эмулятора и элементы ОС в образе контейнера, связанном с образом контейнера или образом микросервисов или набором образов с таким расчетом, чтобы обеспечивалось размещение обоих образов контейнеров в Pod'e.

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

В процессе или после проведения любой оптимизации или любых модификаций образа микросервисов или образа контейнеров, описание которых приведено в настоящем документе, сборщик (375) контейнеров в дальнейшем сохраняет их в репозитории (390) образов контейнеров. В последующем образы контейнеров в репозитории (390) образов контейнеров выполняются в контейнерах (395), управляемых системой (385) управления контейнерами.

В соответствии с конкретными вариантами осуществления настоящего изобретения репозиторий (390) образов контейнеров может представлять собой Docker-репозиторий, аналогичный по структуре публичному репозиторию Docker Hub. В дальнейшем предпочтительно, чтобы система (385) управления контейнерами поддерживала Docker контейнеры и обеспечивала их оптимизированное выполнение.

Система (385) управления контейнерами может сочетать функции планирования инстанцирования контейнеров, запуска контейнеров на выполнение, выделения им контролируемого количества вычислительных ресурсов/ресурсов хранения/сетевых ресурсов, их обновление, и (или) может выполнять дополнительные функции журналирования и управления для отслеживания и управления работоспособностью системы. В соответствии с конкретными вариантами осуществления настоящего изобретения система (385) управления контейнерами может представлять собой Kubernetes систему управления контейнерами для Docker-контейнеров. Однако могут быть использованы другие системы управления контейнерами, такие как Amazon ACS, Azure Container Service, Cloud Foundry Diego, CoreOS Fleet, Docker Swarm, Google Container Engine или система управления контейнерами Mesosphere Marathon, или другие системы оркестрирования контейнеров. Система (385) управления контейнерами может быть аналогична системе, приведенной на ФИГ. 1Б, с модификациями и добавлениями в соответствии с изложенным в настоящем документе описанием. Избирательное распределение ресурсов системы (385) управления контейнерами может быть выполнено при использовании с-групп, когда контейнеры основаны на Docker,

Интеллектуальный прокси (не показан) перед системой (385) управления контейнерами может поддерживать постоянное TCP-соединение с эмулятором терминала конечного пользователя или любым другим клиентским интерфейсом, требующим постоянного соединения. Затем указанный прокси сканирует запросы на постоянное соединение и конвертирует их в соответствующие сервисные запросы, которые затем маршрутизируются Kubernetes' к соответствующему микросервису. Специальные обертки в интеллектуальном прокси и в микросервисах обеспечивают инкапсуляцию трафика 3270 или любого другого специального трафика в запросах и ответах микросервисов.

Контейнеры (395) и система (385) управления контейнерами могут постоянно находиться в подсистеме (400). Подсистема (400) может быть физически отделена от остальной масштабируемой контейнерной системы (300) и может работать в качестве автономной системы, способной достичь аналогичные преимущества, имеющиеся при использовании масштабируемой контейнерной системы (300). Например, подсистема (400) может выполнять функции выделения ресурсов и управления контейнерами в соответствии с описанием, приведенным в настоящем документе. В частности, если подсистема (400) также включает репозиторий (390) образов контейнеров, система (385) управления контейнерами, используя образы контейнеров, может также создать дополнительные или дублирующие контейнеры. При этом, подсистема (400) также может извлечь выгоды от разбиения монолитного унаследованного приложения на микросервисы и от включения только необходимых элементов эмулятора и элементов ОС в образы контейнеров. Тем не менее, поскольку в подсистеме (400) отсутствуют элементы масштабируемой контейнерной системы (300), выделяемые для создания вектора определения микросервисов и образов контейнеров, система не способна автоматически обновлять свои образы контейнеров и контейнеры. Вместо этого подсистема может получать обновленные образы контейнеров, которые система (385) управления контейнерами применяет к контейнерам (395), или которые хранятся в репозитории (390) образов контейнеров, при его наличии.

Другая подсистема (не проиллюстрирована) может включать контейнеры (395), систему (385) управления контейнерами, репозиторий (390) образов контейнеров, сборщик (375) контейнеров и репозиторий (380) комплементарных компонентов. Такая подсистема может быть физически отделена от остальной масштабируемой контейнерной системы (300) и обеспечивает достижение многих из преимуществ, приведенных в отношении системы (300). Такая подсистема способна обновлять образы контейнеров при предоставлении новых образов микросервисов. Такая подсистема может также содержать репозитории (355) образов микросервисов и (или) (эмулятор (325) унаследованного приложения, но в ней могут отсутствовать компоненты, отвечающие за разработку новых векторов определения микросервисов и (или) образов микросервисов на начальном этапе или при обновлении монолитного исходного кода. Такая подсистема может также включать эмулятор (325) унаследованного приложения.

Многие унаследованные приложения, основанные на реляционных базах данных, структурированы в соответствии с реляционной теорией Tedd Codd, первоначально опубликованной в его статье «А Relational Model of Data for Large Shared Data Banks» CACM 13, No. 6, June 1970. Указанные унаследованные базы данных были спроектированы с учетом минимальной избыточности: их структура обычно была в максимально возможной степени нормализована. Для большинства из них пятая нормальная форма (5NF) являлась первоначальной целью проектирования, даже если реальная жизнь изменит эту идеальную форму с течением лет. Результатом высокой степени нормализации является высокая степень взаимозависимостей по различным секциям данных, используемых монолитным унаследованным приложением.

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

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

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

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

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

В структурах аналогичного типа сопровождение совместно используемых объектов всеми транзакциями в монолитном унаследованном приложении может быть реализовано путем обнаружения совместно используемых объектов, используя анализатор исходного кода и далее путем сбора объектов сопровождения в контейнерах специализированных ресурсов с помощью сборщика контейнеров в соответствии с информацией, предоставленной анализатором исходного кода. Например, CICS TS очереди, совместно используемые программами, присутствующими в нескольких микросервисах, могут постоянно находиться в контейнерах ресурсов с длительным жизненным циклом, в которых они хранятся. К указанным совместно используемым объектам (например, сеансы операций с памятью, очереди сообщений, совместно используемые объекты данных) может быть обеспечен удаленный, но при этом прозрачный доступ с помощью функций удаленного доступа унаследованного эмулятора, первоначально разработанных для целей репликации функций удаленного доступа унаследованной компьютерной среды. В случае с унаследованной средой CICS указанные функции являются эмулированными версиями таких унаследованных функций, как MRO, IPIC и т.д. Могут быть обнаружены зоны совместно используемой памяти (CSA, CICS CWA, CICS TCTUA и т.д. в случае с z/OS), размещенные в распределенной совместной кэш-памяти, к которым имеется доступ с помощью тех же самых функций удаленного доступа на контейнерах специализированных ресурсов при их совместном использовании различными микросервисами.

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

Контейнерная система, описание которой приведено в настоящей заявке, представляет собой измененный ландшафт с точки зрения сборки программного продукта, обеспечивая создание адаптивного интегрированного процесса сборки программного продукта, гибко связанного с производственной средой. При изменении исходного кода, хранящегося в репозитории (305) для хранения исходного кода, скомпилированного компилятором (310) и сохраненного в бинарном репозитории (315), анализатор исходного кода (320), репозиторий определения состояний транзакций (340), оптимизатор определения микросервисов (345) и построитель образов микросервисов (350) могут быть применены для построения обновленного образа микросервиса или набора образов микросервисов для микросервиса или микросервисов, соответствующих только тем транзакциям, которые подверглись воздействию проведенных изменений. Сборщик контейнеров (375) далее может запустить процедуры построения, автоматически и оптимально определенные и настроенные на основе векторов определения микросервисов, предварительно извлеченных сборщиком контейнеров, образов контейнеров для обновленных микросервисов, которые далее могут быть развернуты системой (385) управления контейнерами. Образы контейнеров могут просто включать обновленные образы для микросервиса или набора микросервисов, однако они также могут включать, при необходимости, изменения, внесенные в образы из репозитория комплементарных компонентов (380). В случае внесения более кардинальных или многочисленных изменений в исходный код могут быть изменены векторы определения микросервисов таким образом, чтобы обеспечивалось создание другого микросервиса или набора микросервисов. Например, при изменении исходного кода с целью обеспечения большого количества транзакций, использующих общий набор программ, то в этом случае данный общий набор программ может быть вновь размещен в отдельном микросервисе, аналогично MS3 на ФИГ. 5, и соответствующим образом осуществляется изменение существующих или создание новых векторов определения микросервисов для других микросервисов.

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

В качестве примера этапы процесса обновления в автоматическом режиме могут включать: (1) структуру исходного кода, размещенную в репозиторий для хранения исходного кода (310); (2) определение работы по сборке в Jenkins (или иная система сборки DevOps); (3) создание Docker-образа путем надлежащего объединения в кластеры двоичных файлов мэйнфрейма; и (4) параметры управления Kubernetes.

Структура микросервисов масштабируемой контейнерной системы также создает преимущества в плане количества изменений, необходимых для обновления, и в плане времени, затрачиваемого на обновление. Например, как проиллюстрировано на ФИГ. 5, изменения в программу D или Е необходимо только внести в сборку микросервиса MS3, а не в сборки двух отдельных микросервисов MS1 и MS2 для транзакций Т1 и Т2. Высокая крупность разбиения, представленная большим количеством независимых микросервисов обеспечивает и предпочтительно осуществляется в режиме полной автоматизации.

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

Учитывая легкость, с которой контейнеры могут быть построены и сокращение времени загрузки образа контейнера в контейнер, если он меньше, оптимизатор определения микросервисов (345) во многих масштабируемых контейнерных системах может выполнить команды для создания множества векторов определения микросервисов на один вектор определения транзакций, в частности, как проиллюстрировано на ФИГ. 4 и ФИГ. 5, при использовании транзакциями программ общего назначения или наборов программ, пригодных для размещения в отдельном микросервисе. Например, Т транзакций может легко стать Р микросервисов, где Р - количество программ и Т являлось количеством точек входа для транзакций, поддерживаемых монолитным унаследованным приложением, если необходимость в точках ввода более не определяется корневой программой каждой существующей транзакции, а любой вызываемой (через LINK, например, в рамках CICS (абонентская информационно-управляющая система)) программой внутри приложения.

Реализация данной масштабируемой контейнерной системы либо с применением Pod'ов, либо только контейнеров позволяет получить дополнительную информацию относительно способов создания и определения микросервисов. Например, большее разбиение транзакций по микросервисам и более минимальные векторы определения микросервисов возможны в масштабируемой контейнерной системе, предназначенной для применения Pod'ов, по сравнению с системой не предназначенных для этих целей.

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

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

Кроме того, поскольку контейнеры могут быть легко собраны и демонтированы, при выполнении транзакции в некоторых контейнерах новые контейнеры с обновлениями могут быть собраны для выполнения новых запросов для данной транзакции, в то время как транзакция завершается в существующих контейнерах без обновления, когда они в дальнейшем могут быть автоматически демонтированы по завершению транзакция и незамедлительно запущены на выполнения. Так, например, если десять контейнеров С1-С10 выполняют транзакцию Т1, при обновлении соответствующего MS1 система (385) управления контейнерами может автоматически создавать новый контейнер, С11 после получения нового запроса на транзакцию. Контейнер С11 включает образ обновленных микросервисов MS1'. По завершению контейнером С1 выполняемой им транзакции, новые транзакции не назначаются контейнеру С1 и его демонтируют. Незамедлительно может быть создан новый контейнер с обновленным микросервисом MS1' для замены контейнера С1, либо он может быть собран при поступлении нового запроса на транзакцию Т1 в зависимости от параметров, применяемых системой (385) управления контейнерами для создания контейнеров и управления ими.

Были разработаны технологии типа Docker и Kubernetes для работы в масштабе Интернета и в последующем для обеспечения очень быстрого роста рабочих нагрузок, которые могут быть распределены по все более возрастающему количеству добавленных х86 машин по мере поступления большего количества запросов. Именно это является целью такого оркестратора, как Kubernetes. Ввиду того, что транзакции клиента в реальном масштабе времени все в большей степени требуют ответа на все возрастающее количество запросов до завершения транзакции, требования онлайновой торговли приводят к появлению проблемы масштабируемости в области расширения присутствия унаследованных компьютерных сред в интернете. Масштабируемость такой контейнерной системы, в соответствии с описанием, приведенным в настоящем документе, является исключительно предпочтительной для увеличения масштабируемости таких унаследованных компьютерных сред путем обеспечения быстрого распространения контейнеров, выделенных для указанных приложений на запросы с большим объемом клиентов. Более того, поскольку каждый образ контейнера или в некоторых случаях каждый Pod содержит несколько элементов ОС и несколько элементов эмулятора, образ может легко тиражироваться и перемещаться с одного аппаратного обеспечения на другое до тех пор, пока может сохраняться иная компьютерная среда, такая как предусматривающая использование операционной системы Linux.

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

В некоторых вариантах начальное развертывание образов контейнеров, содержащих микросервисы или наборы микросервисов, в контейнере или Pod'ах, может быть основано, по меньшей мере, частично, на воздействии транзакции при выполнении монолитного унаследованного приложения в унаследованной компьютерной среде, или при его эмуляции. Указанная информация может быть получена от унаследованного эмулятора, такого как унаследованный эмулятор (325), как проиллюстрировано на ФИГ. 3. Такая информация также может быть получена из унаследованных журналов регистрации операций, таких как унаследованные журналы (360) регистрации операций, или из анализатора журналов регистрации операций, такого как анализатор (365) журналов регистрации операций (не проиллюстрирован на ФИГ. 3).

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

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

Контейнеры в масштабируемой контейнерной системе, такие как контейнеры общего типа, показанные на ФИГ. 1Б, могут работать без гипервизора, позволяя масштабируемой контейнерной системе работать более эффективно чем система, такая как виртуальная машина, типа которой показан на ФИГ. 1А, в которой должны также работать дополнительные компоненты, такие как гипервизор или множество копий ОС.

Система в соответствии с приведенным выше описанием может быть реализована в машинных командах, хранящихся в энергонезависимом носителе, таком как запоминающая среда ЭВМ в сервере или в серверном кластере или наборе серверных кластеров. Машинные команды могут храниться на энергонезависимом фиксированном или сменном носителе данных для инсталляции на такой системе. В одном варианте осуществления репозиторий (310) для хранения исходного кода, репозиторий (340) определения состояний транзакций и репозиторий (440) динамических определений хранятся в общей системе репозиториев, при этом бинарный репозиторий (330), репозиторий (360) образов транзакций, репозиторий (450) комплементарных компонентов и репозиторий (370) образов контейнеров хранятся в общей системе бинарных репозиториев образов. В другом варианте осуществления репозиторий (370) образов контейнеров инстанцирован в отдельной платформе. В зависимости от масштаба и потребностей системы могут быть использованы различные номера систем репозиториев и репозитории исходного кода и двоичного кода могут быть объединены или разделены на различные системы репозиториев.

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

В соответствии с другим аспектом настоящего изобретения предусмотрен способ создания и (или) сопровождения масштабируемой контейнерной системы, выполняющей операции монолитного унаследованного приложения. На ФИГ. 6 показана схема определенных этапов такого способа. Тем не менее, любые функции, описание которых приведено выше в связи с масштабируемой контейнерной системой, могут также быть включены в способ. Кроме того, несмотря на то, что способ не ограничен использованием с любой конкретной системой, он может быть реализован на масштабируемой контейнерной системе, описание которой приведено выше.

Способ 600 включает этап 605, на котором монолитное унаследованное приложение анализируют, и происходит автоматическое разбиение программных файлов. На этапе 610 идентифицируют корневые программы транзакции. На этапе 615, который может выполняться до или после этапа 610, идентифицируются взаимозависимости программ. Этапы 610 и 615 могут выполняться одновременно для различных транзакций во множестве транзакций.

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

На этапе 625 множество деревьев вызовов транзакций используют для создания множества векторов определения транзакций, которые хранятся, например, в репозитории определения состояний транзакций.

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

На этапе 630 множество векторов определения транзакций из этапа 625 сравнивается с репозиторием динамических определений из этапа 650 оптимизатором определения микросервисов, и программы, фактически не используемые в транзакции, удаляют из каждого вектора определения транзакций для создания множества векторов определения микросервисов, соответствующих множеству транзакций.

На этапе 635 оптимизатор определения микросервисов определяет будет ли происходить дополнительная оптимизация. Если произойдет дальнейшая оптимизация, то на этапе 640, по меньшей мере, один из множества векторов определения микросервисов дополнительно оптимизируется, затем на этапе 645 он предоставляется построителю образов микросервисов. Если дальнейшая оптимизация не произойдет для любого из множества векторов определения микросервисов, то на этапе 645 вектор определения микросервисов предоставляется построителю образов микросервисов. Независимо от того, произойдет оптимизация или нет для любого из векторов определения микросервисов, множество векторов определения микросервисов, полученное из множества векторов транзакций, предоставляется построителю образов микросервисов на этапе 645.

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

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

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

На этапе 670 множество образов контейнеров хранится в репозитории образов контейнеров.

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

На этапе 680, по меньшей мере, один микросервис выполняется в контейнере в системе управления контейнерами.

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

Claims (70)

1. Масштабируемая контейнерная система, реализованная в машинных командах, хранящихся в энергонезависимом носителе, при этом система включает:

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

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

репозиторий определения состояний транзакций, предназначенный для хранения множества векторов определения транзакций;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Система по п. 9, в которой скомпилированный исходный код в бинарном репозитории скомпилирован из исходного кода в репозитории для хранения исходного кода в двоичные файлы.

11. Система по любому из предшествующих пунктов, в которой унаследованная компьютерная среда включает операционную систему Multiple Virtual Storage (MVS) или z/OS.

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

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

14. Система по любому из предшествующих пунктов, в которой система управления контейнерами предназначена для создания множества контейнеров.

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

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

17. Система по любому из пп. 14-16, в которой система управления контейнерами предназначена для изменения количества контейнеров в рамках множества контейнеров.

18. Система по любому из пп. 14-17, в которой система управления контейнерами предназначена для распределения изменяющихся ресурсов по отдельным контейнерам.

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

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

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

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

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

24. Способ создания и управления масштабируемой контейнерной системы, при этом способ включает:

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

хранение множества векторов определения транзакций в репозитории состояний транзакций;

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

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

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

хранение множества образов микросервисов в репозитории образов микросервисов;

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

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

хранение образов контейнеров в репозитории образов контейнеров;

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

выполнение микросервиса или набора микросервисов в контейнере.

25. Способ по п. 24, включающий:

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

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

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

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

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

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

30. Способ по пп. 24-29, включающий дополнительную оптимизацию векторов определения микросервисов, используя оптимизатор определения микросервисов.

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

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

33. Способ по п. 32, включающий компилирование исходного кода в бинарном репозитории из исходного кода в репозитории для хранения исходных кодов в двоичные файлы.

34. Способ по пп. 24-33, при котором унаследованная компьютерная среда включает операционную систему Multiple Virtual Storage (MVS) или z/OS.

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

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

37. Способ по пп. 24-36, включающий создание множества контейнеров с использованием системы управления контейнерами.

38. Способ по п. 37, включающий инстанцирование набора комплементарных образов в отдельный контейнер в рамках общего набора контейнеров (Pod).

39. Способ по пп. 37-38, включающий активирование нескольких копий, по меньшей мере, одного образа контейнера в нескольких отдельных контейнерах.

40. Способ по пп. 37-39, включающий систему управления контейнерами, варьирующую количество контейнеров в рамках множества контейнеров.

41. Способ по пп. 37-40, включающий систему управления контейнерами, распределяющую изменяющиеся ресурсы по отдельным контейнерам.

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

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

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

45. Способ по пп. 24-44, включающий сборщик контейнера, помещающий одну или более вспомогательных баз данных или кластеров вспомогательных баз данных в один или более контейнеров.

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

Images