Читать книгу Из разработчика в архитекторы. Практический путь - Евгений Сергеевич Штольц - Страница 3

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

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

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

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

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

сильно связанны функционально через сложное техническое API – для пользователя известно лишь поддерживаемая совместимость одних версий CMS с другими версиями СУБД.

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

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

масштабированием, другой вид поддержки (SLA)

* Для бизнеса выделяемый сервис уже является отдельной и мало зависимой функцией – далее рассмотрим

подход DDD (model-driven design + ubiquitous language) к реализацию микрсервисов

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

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

1. Должен из себя представляеть компонент или сервис. Каждый микросервис – законченный полноценны независимый сервис с точки зрения разработчика, системного администратора и пользователя. Он должен обладать возможностью быть легко заменённым на другой, как в коде разработчика, как в процессе работы (должны быть ), так и представлен другим или убран в интерфейсе пользователя. Не выполнения условий заменимости на разных уровнях приводят к одному сервису разделённому на части – распределённому монолиту.

2. Организация бизнес возможностей.

3. Продукты – не проекты.

4. Умные конечные точки и глупые связи. Не требующая сложной интеграции с отлаженными сервисами (интеграцию сложных систем занимается сервис ориентированная архитектура SOA)

5. Децентрализованное управление. Здесь имеется в виду оркестрация, например, Kubernetes, управление сетью, например, Istio, управление доставкой, например, Knative.

6. Децентрализованное управление данными. В силу самодостаточности сервиса и независимости от других он должен иметь независимое состояние – базу данных, а чтобы и выбор системы управления базой данных был независим – есть и её свою.

7. Автоматизированная инфраструктура. Процесс деплоя, масштабирования и откатов должен быть автоматизированы, что позволяет быстро автоматически откатываться, фиксировать в коде изолированность работы сервиса.

8. Предусмотрен отказ в работе. Для визуализации отказов можно посмотреть на Jaeger и Prometheus, для локализации проблем сервисы должны быть изолированны, представлять один единый сервис, что позволяет изолировать, ограничить пагубное воздействия на другие сервисы при отказе и автоматизировать откат.

9. Эволюционирующийся дизайн. Система наращивает отростки в виде сервисов – обрастает ими, при этом не требуется изменение её структуры. Neal Ford и Rebeca Parsons в "Микросервисы как эволюционирующая архитектура" ориентируются на постоянные улучшения.