Микросервисная архитектура

Архитектура приложения

— общая структура, состоящая из отдельных частей и зависимостей между ними.

масштабируемость
надежность
безопасность
Логическое представление — программные элементы, создаваемые разработчиками. В объектно-ориентированных языках это классы и пакеты. Связи между ними соответствуют отношениям между классами и пакетами, включая наследование, взаимосвязи и зависимости.
Представление реализации — результат работы системы сборки. Это представление состоит из модулей, представляющих упакованный код, и компонентов, которые являются исполняемыми или развертываемыми единицами и содержат один или несколько модулей.
Представление процесса — компоненты на этапе выполнения. Каждый элемент является процессом, а отношения между процессами представляют межпроцессное взаимодействие.
Развертывание — то, как процессы распределяются по устройствам. Элементы в этом представлении состоят из серверов (физических или виртуальных) и процессов. Связи между серверами представляют сеть. Это представление также описывает отношение между процессами и устройствами.

Архитектура монилита, к чему привыклю большинство разработчиков

уровень представления — содержит код, реализующий пользовательский интерфейс или внешние API;
уровень бизнес-логики — содержит бизнес-логику;
уровень хранения данных — реализует логику взаимодействия с базой данных.

Шестигранная архитектура — это альтернатива многоуровневому стилю проектирования. Она организует логическое представление таким образом, что бизнес-логика оказывается в центре

У бизнес-логики есть один или несколько портов. Порт определяет набор операций и то, как и в чем бизнес-логика взаимодействует с внешним кодом. Порт часто является интерфейсом. Существует два вида портов: входящие и исходящие.

Входящий порт — это API, выставляемый наружу бизнес-логикой и доступный для вызова внешними приложениями.

Исходящий порт — это то, как бизнес-логика обращается к внешним системам.

Вокруг бизнес-логики размещаются адаптеры. Как и порты, они бывают двух типов: входящие и исходящие.

Входящий адаптер обрабатывает запросы из внешнего мира, обращаясь к входящему порту.

Еще один пример — клиентский брокер сообщений, который на них подписывается. Несколько входящих адаптеров могут обращаться к одному и тому же входящему порту.

Исходящий адаптер реализует исходящий порт и обрабатывает запросы бизнес-логики, обращаясь к внешнему приложению или сервису.

Важное преимущество шестигранного архитектурного стиля состоит в том, что его адаптеры отделяют бизнес-логику от логики представления и доступа к данным и делают ее независимой.

Сервис

Сервис— это автономный, независимо развертываемый программный компонент, который 
реализует определенные функции. Через собственный API сервис предоставляет 
доступ к своим функциям.

API состоит:

Команд - такая как createOrder(), выполняет действия и обновляет данные.
Запрос - такой как findOrderById(), извлекает данные.
Сервис - публикует события, например OrderCreated, которые потребляются его клиентами.

API сервиса инкапсулирует его внутреннюю реализацию. В отличие от монолита этот подход не позволяет разработчику писать код, минующий API. Благодаря этому микросервисная архитектура обеспечивает модульность приложения.

Каждый микросервис обладает собственной архитектурой и иногда отдельным стеком технологий. Но обычно сервисы имеют шестигранную архитектуру. Их API реализуются адаптерами, которые взаимодействуют с бизнес-логикой приложения. Бизнес-логика вызывается адаптером операций, а события, которые она генерирует, публикуются адаптером событий.

Требование, согласно которому сервисы должны быть слабо связанными и взаимодействовать только через API, исключает коммуникацию через базу данных. Отсутствие общих таблиц БД также улучшает изоляцию на этапе выполнения. Это, например, гарантирует, что сервису не придется ждать из-за того, что другой сервис заблокировал базу данных.

Размер сервиса обычно не имеет значения

Одна из проблем термина «микросервис» — то, что в глаза сразу бросается «микро». В реальности размер не является полезной характеристикой. Определение хорошо спроектированного сервиса лучше связать с возможностью разрабатывать его в небольшой команде, как можно быстрее и минимально взаимодействуя с другими командами. Теоретически команда должна отвечать только за один сервис, чтобы тот и в самом деле был микроскопическим. Если же сервис требует большой команды разработчиков или слишком много времени на тестирование, его, как и саму команду, имеет смысл разделить на части.