CC BY
82
технической конференции студентов, аспирантов и молодых ученых, Томск, 13-15 мая 2015 г. -Томск: В-Спектр, 2015: В 5 частях. - Ч. 5. - С. 304-306.
2. Дмитриев В.М. Формализм сетей Петри с транзактами для моделирования бизнес-процессов / В.М. Дмитриев, Т.Е. Григорьева, С.А. Панов, Е.В. Истигечева, И.В. Дмитриев // Информатика и системы управления. - 2016. - № 2 (48). - С. 36-47.
3. Панов С.А. Интерактивное документирование бизнес-процессов в среде моделирования МАРС / С.А. Панов, Т.Е. Григорьева // Электронные средства и системы управления: Материалы докладов XI Международной научно-практической конференции, Томск, 25-27 ноября 2015 г. -Томск: В-Спектр, 2015: В 2 ч. - Ч. 2. - С. 289-293.
4. Григорьева Т.Е. Моделирование систем массового обслуживания на примере очереди в банке // Научная сессия ТУСУР-2016: материалы Международной научно-технической конференции студентов, аспирантов и молодых ученых, Томск, 25-27 мая 2016 г. - Томск: В-Спектр, 2015: в 6 частях. - Ч. 3. - С. 105-108.
5. Истигечева Е.В. Моделирование логистических схем бизнес-процессов / Е.В. Истигечева, Т.Е. Григорьева // Информатика и системы управления. - 2016. - № 1 (47). - С. 25-33.
6. Истигечева Е.В. Моделирование бизнес-процессов на примере модели «Сбыт» / Е.В. Истигечева, Т.Е. Григорьева, С.А. Панов // Таврический научный обозреватель. - 2015. - № 3, часть 2. - С. 55-59.
7. Истигечева Е.В. Моделирование бизнес-процессов на примере модели «Хранение» / Е.В. Истигечева, Т.Е. Григорьева, С.А. Панов // Научная дискуссия: вопросы технических наук: Сборник статей по материалам XL международной заочной научно-практической конференции, Москва, 2015 г. — № 11 (29). - Москва: Изд. «Интернаука», 2015. - С. 17-22.
УДК 004.42
ИСТОРИЧЕСКИЕ АСПЕКТЫ ПОЯВЛЕНИЯ МИКРОСЕРВИСНОЙ АРХИТЕКТУРЫ6
Артамонов Иван Васильевич, к.т.н., доцент Байкальского государственного университета, Россия,
Иркутск, ivan.v.artamonov@gmail. com
Последние годы достаточно часто в литературе, посвященной программной инженерии, можно встретить термин «микросервисная архитектура» [1-3]. Это сравнительно молодая концепция, которая, на наш взгляд, является прямым следствием развития представлений и тенденций в области архитектуры распределенных программных систем.
Появившись в начале 2000-х сервис-ориентированная парадигма дала существенный толчок развитию наукоемких технологий, связанных с прикладным использованием ИТ, особенно в коммерческом секторе. Например, сервисные идеи хорошо соотносятся с теорией процессного управления в менеджменте, и, значит, могут являться ядром современных корпоративных информационных систем. С помощью сервисов можно строить сложные, иерархические распределенные системы, не привязанные к закрытым протоколам и стандартам, обеспечивая высокий уровень асинхронности, повторного использования и автономности отдельных частей. Тем самым сохраняя возможность привлечения к взаимодействию множества организационно и технологически независимых участников в разных отраслях деятельности: начиная от выполнения бизнес-процессов в корпоративной среде, интеграции облачных приложений, построения многоагентных систем и заканчивая организацией совместной деятельности в научном сообществе.
Сервисно-ориентированное программирование является наследником всех принципов объектных систем, отличаясь от него тем, что вопросы иерархии, наследования, инкапсуляции вынесены на организационный уровень. Сервис представляет собой завершенную, откомпилированную программу, он контролирует доступ к своим данным и
6 Работа публикуется при финансовой поддержке РФФИ в рамках научного проекта № «16-37-00095 мол_а»
21
функциям через явный интерфейс. Вопросы построения более функциональных систем на базе простейших решаются композицией сервисов силами скорее аналитиков, нежели программистов. В отличие от компонентно-ориентированных систем сервис-ориентированные не привязаны к специфичной технологии или языку программирования и изначально ориентированы на использование в интернете, что позволяет быстро строить сложные распределенные системы или облегчать интеграцию существующих.
В статье будет рассмотрен сравнительно новый подход к реализации сервис-ориентированной парадигмы в виде микросервисов через призму некоторых стержневых идей современной программной инженерии.
Под микросервисом будем понимать независимую программу, которая выполняет четко очерченный набор функций и взаимодействует с другими приложениями через определенный интерфейс и посредством общепринятых, стандартных и легковесных протоколов, например, HTTP. Ключевая идея микросервиса - независимость от окружающей среды, слабая с ней связанность и высокий уровень повторного использования.
Идея повторного использования в современном программировании, несомненно, занимает центральное место. Первым шагом в этом направлении стало появление структурного программирования и концепции подпрограммы. Программа разбивается на небольшие подпрограммы таким образом, что, комбинируя эти подпрограммы, можно воссоздавать итоговый алгоритм уже не из отдельных операторов, а из завершенных блоков кода, имеющих конкретную смысловую нагрузку, при этом обращаться к этим блокам можно по названиям. При необходимости подпрограммы можно переносить между исходными кодами различных программ.
Таким образом, одну и ту же часть кода можно неограниченное количество раз и вызывать внутри одной программы, и копировать между разными приложениями. Благодаря структурам повышается надежность программ. Во-вторых, программы становятся более эффективными, так как структурирование позволяет легко находить и исправлять ошибки, а отдельные подпрограммы можно видоизменять независимо от других.
Недостатком повторного использования подпрограмм является сложность управления кодом: исправление ошибки в подпрограмме одного приложения требует внесения изменений в аналогичные участки кода других программ. Кроме того, в сферах, где было нужно управлять большим объемом разнородных сущностей, сложно было работать с разделенными данными и операциями, проводимых над ними.
Последний фактор привел к разработке объектно-ориентированной концепции программирования (ООП). В ООП появляется понятие класса, как сущности, объединяющей данные и код их обработки, инкапсуляции, скрывающей особенности реализации класса, а позднее вводятся концепции интерфейса. Все это значительно упрощает повторное применение кода. Тем самым устраняются проблемы структурного программирования, уровень повторного использования повышается, снижается степень связанности между частями программного обеспечения [4].
При этом объектно-ориентированный подход также не был лишен недостатков [5]. Во-первых, существует проблема «уязвимых» базовых классов - изменения в родительских классах, от которых унаследованы другие, может привести к потере функциональности последних. Во-вторых, при распространении библиотек классов нередко возникает ситуация, когда код классов из библиотеки модифицируется под специфические задачи, чем нарушается согласованность всей системы. В-третьих, рост сложности программных систем приводит к тому, что иерархии классов проектов становятся запутанными и хуже поддаются сопровождению.
Частично эти проблемы решались с помощью модульного программирования, когда библиотека классов формировалась в виде откомпилированной части кода, доступной локально разным программам. Однако зарождающиеся массовые сетевые технологии
привели к развитию в начале 1990-х новой парадигмы, во многом базирующейся на принципах, заявленных в ООП, - компонентно-ориентированного программирования. В основе этой концепции лежит понятие компонента - независимой программы с четко-определенным интерфейсом и ясно очерченными зависимостями от внешней среды [6]. Компонент может быть независимо установлен или удален из среды, может предоставлять функциональность другим компонентам и должен работать, если в среде есть все необходимые ему другие компоненты. По своим целям компонент похож на программный модуль или библиотеку функций, однако позволяется осуществлять независимое развертывание. Тем самым реализуется слабая связанность компонента со средой, возможность его повторного использования в различных контекстах, и вероятность быстрой и эффективной разработки сложных, распределенных программ.
Конечно, наборы классов, применяемые при ООП, также дают возможность повторного использования кода, но компоненты выводят повторное применение кода на еще одну ступень выше. В компоненте выделяется интерфейс, не зависящий от программного кода. Интерфейс определяет все зависимости и возможности компонента. Программную реализацию компонента можно свободно изменять, не затрагивая его интерфейс. Таким образом, обновление программы становится простой и малозатратной процедурой, не требующей массового изменения кода.
К сожалению, инновационная идея компонента и компонентной разработки натолкнулась на жесткие реалии активно-развивающегося рынка программной инженерии 90-х [6]. Коммерциализация этой области, постоянное кардинальное обновление операционных платформ, конкурентная борьба между основными поставщиками продуктов разработки привело к потере стабильности в развитии компонентных технологий. Новые версии компонентных моделей появлялись очень часто, их составляющие могли настолько изменяться, что уже не поддерживали компоненты предыдущих версий. Разработчикам каждый раз приходилось следовать несколько измененным правилам, а старые компоненты не подлежали повторному использованию. При этом создатели компонентных моделей недооценили растущую роль глобальных телекоммуникационных сетей, и среде интернет распределенные компонентные системы, ориентированные на постоянное подключение, работали нестабильно и ненадежно. Наконец, конкурентная борьба привела к невозможности взаимодействия программ, написанных на разных языках программирования для разных компонентных моделей.
В начале 2000-х крупнейшие разработчики средств программирования предприняли совместную попытку создания новой технологии, которая смогла бы учесть и исключить ограничения компонентного подхода [7]. Заимствовав все идеи компонента, они предложили нивелировать его технологические ограничения путем широкого использования уже существующих открытых протоколов и стандартов интернета, типизации интерфейса и ввода специального языка для его описания, ориентации на работе через интернет и вообще на любую инфраструктуру сетевого взаимодействия. Программа с идеями компонента, но с новыми технологическими возможностями стала называться веб-службой (или веб-сервисом), а соответствующая парадигма разработки - сервис-ориентированное программирование.
В основу платформы веб-службы лег набор уже существующих механизмов типа HTTP, SMTP, XML, UDDI, SOAP... и новых открытых протоколов, обобщенно называемых WS-* (от англ. web-service) - WSDL (язык описания веб-служб), WS-Security, WS-Reliability, WS-Coordination, WS-Addressing и пр. На данный момент технологию веб-служб в том или ином масштабе поддерживают все популярные средства разработки программного обеспечения, даже, например, 1С.
Технология веб-служб, лишенная недостатков компонентов, и потому предлагающая широкие возможности повторного использования и слабого связывания, была быстро
популяризирована и, несомненно, открыла новые возможности разработки сетевых программ и интеграции приложений в корпоративной среде. Она же стала толчком к развитию идей как сервис-ориентированной архитектуры информационных систем, так и сервис-ориентированных моделей управления бизнес-процессами.
Дальнейшим развитием веб-служб стала технология микросервисов. Предполагается, что микросервисы отличаются от веб-служб следующим. Во-первых, меньшей привязкой к WS-стандартам. Микросервисы не задумываются для широкого общественного использования и потому реализуются силами разработчиков одной компании для решения ее локальных задач. Разработчики вольны применять собственные протоколы взаимодействия, хотя широкая поддержка таких элементов как HTTP, SOAP или WSDL и др. позволяет на данный момент считать их оптимальными для поддержки взаимодействия микросервисов. Во-вторых, считается (например, в [8]), что веб-службы обычно реализуют «крупную» бизнес-логику, тогда как задача микросервисов - простейшие неделимые операции. С этим нельзя согласится, т.к. веб-службы поддерживают неограниченную иерархию вложенности и, теоретически, один веб-сервис может вызывать операции нескольких других, те, в свою очередь, функции следующего уровня и т.д. до самых низких уровней декомпозиции, на которых находятся простейшие бизнес-операции.
Таким образом, основным и, возможно, единственным отличием микросервисов от веб-служб является отсутствие ограничений в виде набора специальных протоколов. Сложно сказать, является ли это положительным шагом развития. С одной стороны, отрешение от WS-* стандартов дает больше возможностей разработчикам, с другой стороны, наличие общепринятых стандартов давало возможность широкой интероперабельности веб-служб. В целом было показано, что технология микросервисов, не являясь кардинально революционной, стала очередным этапом развития идей построения сложных программных систем, отвечая на современные вызовы этой отрасли информационных технологий. Она вобрала в себя лучшие на данный момент решения проблем повторного использования, слабой связанности и независимости программы. И, на наш взгляд, лучше отвечает задачам сервис-ориентированного программирования, нежели веб-сервисы.
Литература
1. Ньюмэн, С. Создание микросервисов / С. Ньюмэн. - СПб. : Питер, 2016. - 304 c.
2. Osowski , R. Microservices in action, Part 1: Introduction to microservices [Электронный ресурс] /
Rick E. Osowski // IBM developerWorks. - 2015. - Режим доступа: http://www.ibm.com/developerworks/cloud/library/cl-bluemix-microservices-in-action-part-1-trs/index.html (дата обращения: 02.03.2016).
3. Fowler, M. Microservices - a definition of this new architectural term [Электронный ресурс] / Martin
Fowler. - 2014. - Режим доступа: http://martinfowler.com/articles/microservices.html (дата обращения: 02.03.2016).
4. Артамонов, И. В. Слабое связывание как фактор эволюции технологий интерграции распределенных систем / И. В. Артамонов // Материалы конференции "Инновации на основе информационных и коммуникационных технологий". - Москва, 2014. - C. 294-297.
5. Кутикин, С. С. Конструктор составных типов с использованием JavaFX / С. С. Кутикин. -
Москва : ВШЭ, 2013. - 76 c.
6. Артамонов, И. В. Разработка распределенных сервисно-ориентированных программных средств / И. В. Артамонов. - Иркутск : БГУЭП, 2012. - 130 c.
7. Ньюкомер, Э. Веб-сервисы: XML, WSDL, SOAP и UDDI / Эрик Ньюкомер. - СПб. : Питер,
2003. - 256 c.
8. Маццара, М. Моделирование интеграции веб-сервисов [Электронный ресурс] / Мануэль Маццара // ПостНаука. - 2015. - Режим доступа: http://postnauka.ru/video/46057 (дата обращения: 02.03.2016).
