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

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

Несмотря на то что до сих пор нет четкого определения микросервисов, известен набор характеристик, помогающих идентифицировать этот архитектурный стиль. По сути, микросервисная архитектура — это метод создания распределенных приложений в виде набора независимо разрабатываемых и развертываемых небольших сервисов, запускаемых как один или несколько изолированных процессов. Все это очень похоже на давно известную сервисную архитектуру (Service-Oriented Architecture, SOA), которая решает ту же задачу — снижение сложности ИТ-ландшафта. Иногда утверждается, что микросервисы — это и есть правильно реализованная SOA, однако следует обратить внимание на ряд ключевых различий между этими подходами.

Во-первых, в качестве программных интерфейсов для взаимодействия с микросервисами, как правило, используют RESTful API и асинхронный обмен сообщениями через очереди (рис. 1), а для реализации сервисной архитектуры использовался протокол SOAP. Строго говоря, SOA не определяла способ взаимодействия между сервисами, но на момент ее появления какой-либо реальной альтернативы использованию SOAP не было. Из-за этого сервисы и микросервисы различаются по логической организации. Микросервисы реализуют возможность управления структурированным информационным ресурсом посредством ограниченного набора операций: чтения и обновления его отдельных частей. А все взаимодействия строятся без сохранения на сервере состояния клиента. Cервисы в SOA не используют концепцию ресурса, а представляют собой набор операций над некоторыми объектами, которые четко нигде не определены. По сути, SOA-сервис — это набор из множества методов, выражаемых глаголами инициации операций по созданию или модификации таких объектов.

Рис. 1. Программные интерфейсы микросервиса
Рис. 1. Программные интерфейсы микросервиса

 

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

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

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF