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

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

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

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

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

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

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

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

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

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

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

      Взгляд со высоты бизнеса и бизнес архитектора

      Бизнес архитектура (Enterprise Architect) – это IT архитектура всей компании. Она оперирует абстракциями и сущностями на уровне бизнеса, это стратегии, бизнес процессы, услуги и тому подобного. Системы и взаимосвязи, обеспечивающие работу бизнеса именуют ИТ ландшафтом, потому что она содержит множество систем, не образующих единое целое, связанные бизнес процессами, в которых они участвуют и которые не ограничиваются ими. Бизнес- архитектора (Enterprise Architect) работает на этом уровне, подстраивая текущий ландшафт под текущую потребности бизнеса. Зачастую, для традиционных компаний, которые развивались не в высокотехнологической сфере в синем океане, он привлекается когда ИТ ландшафт сложился и возникают сложности его