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

Сервисы могут использовать множество технологий для связи между друг другом: rest или grpc поверх http, или же механизмы коммуникации сообщений, такие как amqp или stopm. Форматы сообщений тоже различаются: от json до двоичных avro или protocol buffers.

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

Общение "один к одному" может быть нескольких видов:
1. Запрос - синхронный ответ;
2. Запрос - асинхронный ответ;
3. Однонаправленные уведомления - клиент не ждёт ответа от сервера.

Общение "один ко многим" так же может быть нескольких видов:
1. Издатель/подписчик - клинет публикует сообщение с уведомлением, которое потребляется любым количеством заинтересованных сервисов;
2. Издатель/асинхронные ответы - клиент публикует сообщение с запросом и ждёт определённое время ответа от заинтересованных сервисов.

API приложения важно проектировать таким образом, чтобы его можно было развивать и поддерживать без урона для клиентов. Если минорные правки или новые API-методы, не ломающие логику, мы можем ввести в API без проблем, то мажорные изменения, такие как изменение формата данных уже существующих методов, нужно делать с помощью версионирования. Хороший подход - семантическая нумерация версий (semver.org). Это набор правил, регламентирующий, как использовать и увеличивать номера версий. Каждая версия API состоит из 3-х частей: major.minor.patch, где:
major - изменяется при внесении в API несовместимых изменений;
minor - изменяется при внесении в API изменений с обратной совместимостью;
patch - изменяется при исправлении ошибок с сохранением обратной совместимости.

Например, в случае REST API мажорную версию можно указать в качестве первого элемента URL-адреса (https://.../v1/...). Если сервис задействует обмен сообщениями, мажорную версию можно включать в публикуемое сообщение.