Конспект ИТ-архитектора. Евгений Сергеевич Штольц

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

      Нужно разделять два уровня разделения: технологическое и доменное. Технологические особенности в работе едины, так как что сервисы, что его компоненты, если он разбит на составные части технологически запускаются и поддерживается одинаково. Но, в отличии от сервисов, которые должны быть минимально взаимосвязаны с другими сервисами и должны обеспечивать определённое API и SLA, то компоненты сильно связанны. Причиной разделения на компоненты имеют технологическую природу. Например, интернет-магазин содержит сервисы, такие как сама интернет-витрина, сервисы оплаты, складские сервисы, а интернет-витрина представляет из себя сервис на CMS Joomla! и систему управления базой данных (СУБД) MySQL. Здесь разделение сервиса на составные части произошло из-за разных программных продуктов, написанных на разных языках программирования. При этом, для заказчика это единый сервис на CMS Joomla!, выполняющий единую функцию предоставления интерфейса для заказа пользователям в онлайн, предоставляемый хостингом как единый сервис (по отдельности не будет работать), может работать как каталог товаров без других сервисов (оплаты, заказа). С технологической точки зрения компоненты сервисы:

      * По одиночки не функциональны;

      * Сильно связанны, так как на каждый запрос к CMS формируется множество запросов;

      * Интерфейсы взаимодействия сложны и разнообразны – тут применяется даже не API, а язык взаимодействия SQL;

      * Сильно связанны функционально через сложное техническое API – для пользователя известно лишь

      поддерживаемая совместимость одних версий CMS с другими версиями СУБД.

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

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

      * Для бизнеса выделяемый сервис уже является отдельной и мало зависимой функцией – далее рассмотрим подход DDD (model-driven design + ubiquitous language) к реализации микросервисов;

      * Необходима смена технологической платформы.

      Микросервис отвечает следующим характеристикам, по мнению М. Фаулера (martinfowler.com). Их можно свести к:

      * 1. Должен из себя представляет компонент или сервис. Каждый микросервис – законченный полноценны независимый сервис с точки зрения разработчика, системного администратора и