ГОСТ Р 70860-2023. Национальный стандарт Российской Федерации. Информационные технологии. Облачные вычисления. Общие технологии и методы

9 Архитектура микросервисов

 

9.1 Общие положения

 

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

Примечание - Термины "сервис" (услуга) и "сервисный интерфейс" используются в соответствии с определениями, приведенными в ГОСТ Р ИСО/МЭК 18384-1. Стандарт также содержит понятное объяснение сервис-ориентированной архитектуры, конкретным примером которой является архитектура микросервисов. Сервис или микросервис не следует путать с облачным сервисом. Может возникнуть ситуация, когда микросервис реализуется как облачный сервис, но это зависит исключительно от выбора разработчика приложения, и никаких определенных требований здесь нет.

 

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

 

 

Рисунок 4 - Пример приложения, структурированного

с использованием архитектуры микросервисов

 

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

Часто в контексте предметно-ориентированного проектирования использование функциональной декомпозиции является залогом построения успешной архитектуры микросервисов. Есть мнение, что эта архитектура представляет собой усовершенствованную и упрощенную версию сервис-ориентированной архитектуры (SOA). Архитектура микросервисов имеет следующие особенности:

- каждый архитектурный компонент ("сервис") имеет четко определенный и явно обозначенный интерфейс;

- каждый сервис работает полностью автономно;

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

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

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