В 4-й главе рассмотрены различные режимы движения данных.

🔼Передача данных между сервисом и БД

Сохранение данных в базе можно рассматривать как отправку сообщения будущему самому себе. Поэтому здесь важна обратная совместимость, чтобы новый код мог читать то, что записали ранее.
К базе могут одновременно обращаться несколько приложений. Это могут быть разные сервисы или несколько инстансов одного сервиса, запущенные параллельно для масштабирования или отказоустойчивости. Существует вероятность, что часть приложений будет с новым кодом, а часть — со старым. Например, в процессе rolling update. В такой ситуации строка, записанная новым кодом, будет прочитана старым. Поэтому прямая совместимость тоже важна.

Старый код легко заметить новым, развернув новую версию приложения (особенно на бэке). Применительно к содержимому БД так сказать нельзя: пятилетние данные останутся на своем месте, в исходном формате, если не перезаписать их явным образом. Однако перезапись (миграция) данных в новую схему — это ресурсоемкая операция, поэтому большинство БД по мере сил избегают ее выполнения. В большинстве реляционных БД разрешены простые изменения схемы, такие как добавление нового поля со значением null. При чтении старой строки база заполнит значениями null новые поля, отсутствующие в данных с диска.

🔼 Передача данных между сервисами

Это может быть обмен данными между фронтом и бэком или взаимодействие между микросервисами на бэке.

Для такого взаимодействия часто используется REST. Для описания/документации REST API удобно использовать OpenAPI (Swagger).

Кстати, по OpenAPI спецификации возможно сгенерировать код для бэка. Мы часто используем это, когда один наш микросервис вызывает другой: оба ссылаются на одну и ту же спецификацию, в одном генерируется код вызовов, а в другом — код принимающий http-запросы. Удобно, что в случае изменений их достаточно отразить только в одном месте — в спецификации, а код просто перегенерировать.

Есть ещё SOAP, основанный на XML, который раньше использовался в крупном энтерпрайзе, но сейчас он стал мало распространён.

Альтернативным вариантом является модель RPC (remote procedure call). Современная известная реализация — gRPC. Она использует двоичный формат Protocol Buffers. Такой подход может быть более производительными, чем JSON поверх REST, однако в силу других своих преимуществ REST остаётся наиболее популярным для общедоступных API, а RPC может использоваться при внутреннем обмене данными между микросервисами одной системы.

🔼Асинхронная передача данных с помощью брокера сообщений

Преимущества при использовании брокера сообщений:
➕ брокер служит в качестве буфера в случае недоступности или перегруженности получателя, а следовательно, повышает надежность системы
➕ брокер может автоматически отправлять сообщения повторно сбойным процессам, тем самым предотвращая потерю сообщений
➕ ‰‰отправителю не требуется знать IP-адрес и порт получателя
➕ можно отправить одно сообщение нескольким получателям
➕ отправитель с получателем логически не сцеплены

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

Брокеры сообщений обычно не навязывают какой-либо конкретной модели данных — сообщение представляет собой просто байтовую последовательность с метаданными, так что можно использовать любой формат сериализации.
Сравнение различных брокеров (RabbitMQ, ActiveMQ, Kafka) в этой главе не приводится.

#кабанчик #сисдиз