Конспект ИТ-архитектора. Евгений Сергеевич Штольц
Читать онлайн книгу.
браковать (что редко), либо дорабатывать. Доработка требуется как после подтверждения предположения, так и ошибочного в виде корректировки. Для службы эксплуатации это означает выкатку огромного количества фич, которые были разработаны впопыхах и могут обрушить основное приложение – монолит. Эта служба пытается запускать эти изменения в изолированной среде в виде отдельного функционала, для чего просит отдел разработки, разрабатывать их отдельно – в виде микросервисов.
Нужно разделять два уровня разделения: технологическое и доменное. Технологические особенности в работе едины, так как что сервисы, что его компоненты, если он разбит на составные части технологически запускаются и поддерживается одинаково. Но, в отличии от сервисов, которые должны быть минимально взаимосвязаны с другими сервисами и должны обеспечивать определённое API и SLA, то компоненты сильно связанны. Причиной разделения на компоненты имеют технологическую природу. Например, интернет-магазин содержит сервисы, такие как сама интернет-витрина, сервисы оплаты, складские сервисы, а интернет-витрина представляет из себя сервис на CMS Joomla! и систему управления базой данных (СУБД) MySQL. Здесь разделение сервиса на составные части произошло из-за разных программных продуктов, написанных на разных языках программирования. При этом, для заказчика это единый сервис на CMS Joomla!, выполняющий единую функцию предоставления интерфейса для заказа пользователям в онлайн, предоставляемый хостингом как единый сервис (по отдельности не будет работать), может работать как каталог товаров без других сервисов (оплаты, заказа). С технологической точки зрения компоненты сервисы:
* По одиночки не функциональны;
* Сильно связанны, так как на каждый запрос к CMS формируется множество запросов;
* Интерфейсы взаимодействия сложны и разнообразны – тут применяется даже не API, а язык взаимодействия SQL;
* Сильно связанны функционально через сложное техническое API – для пользователя известно лишь
поддерживаемая совместимость одних версий CMS с другими версиями СУБД.
Разделение системы на микросервисы начинается с анализа их границ, анализ выгод от разделения и привнесённых сложностей распределённой системой. Отделять микросервисы лучше при комбинации необходимости:
* Технологической необходимости, например, большая нагрузка, которую сложно выдержать без отделения, например, масштабированием, другой вид поддержки (SLA);
* Для бизнеса выделяемый сервис уже является отдельной и мало зависимой функцией – далее рассмотрим подход DDD (model-driven design + ubiquitous language) к реализации микросервисов;
* Необходима смена технологической платформы.
Микросервис отвечает следующим характеристикам, по мнению М. Фаулера (martinfowler.com). Их можно свести к:
* 1. Должен из себя представляет компонент или сервис. Каждый микросервис – законченный полноценны независимый сервис с точки зрения разработчика, системного администратора и