при комбинации необходимости:
* Технологической необходимости, например, большая нагрузка, которую сложно выдержать без отделения, например,
масштабированием, другой вид поддержки (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 в "Микросервисы как эволюционирующая архитектура" ориентируются на постоянные улучшения.
Взгляд со высоты бизнеса и бизнес архитектора
Бизнес архитектура (Enterprise Architect) – это IT архитектура всей компании. Она оперирует абстракциями и сущностями на уровне бизнеса, это стратегии, бизнес процессы, услуги и тому подобного. Системы и взаимосвязи, обеспечивающие работу бизнеса именуют ИТ ландшафтом, потому что она содержит множество систем, не образующих единое целое, связанные бизнес
