Обзор IPC¶

Существует множество разных технологий IPC. Сервисы могут использовать коммуникационные механизмы на основе запросов/ответов, такие как REST или gRPC, или механизмы коммуникации на основе сообщений, такие как AMQP или STOMP. Также существует множество форматов сообщений, как текстовые форматы, понятные человеку (JSON или XML), так более эффективные двоичные — Avro или Protocol Buffers.

Стили взаимодействия¶

Стили взаимодействия между сервисами можно разложить в таблицу

Описание API¶

API сервиса является контрактом между ним и его клиентами. Как говорилось в главе 2, API состоит из операций, которыек клиент может вызывать и событий, публикуемых сервисом.
Трудность заключается в том, что определение API сервиса не основано (в отличие от модулей в монолите) на конструкциях языка программирования. Следовательно, если будет развернута версия с несовместимым API — ошибка проявится только на этапе выполнения.
Независимо от того, какой механизм IPC выбран, важно создать чёткое определение API, используя некий язык описания интерфейсов (interface definition language, IDL).

Развивающиеся API¶

API непрерывно меняются по мере внесения новых, изменения существующих и удаления старых возможностей. Обычно обновление клиентов одновременно с сервисами не представляется возможным. Кроме того, для сокращения возможного времени простоя на обслуживание обновление будет плавающим, то есть необходимо, чтобы старая и новая версия сервиса работали параллельно. Чтобы справиться с этими трудностями, необходимо иметь стратегию.
Для контроля за изменениями можно применять систему семантического версионирования. Номера версий можно использовать в нескольких местах. В REST API мажорную версию можно указать в качестве первого элемента URL-пути. Если сервис задействует обмен сообщениями, можно включать номер версии в публикуемые сообщения.

Форматы сообщений¶

Суть IPC состоит в обмене сообщениями. Сообщения обычно содержат данные, выбор формата для которых является важным архитектурным решением. Иногда выбор формата не зависит от выбранного механизма (например, протокол HTTP), а иногда, наоборот, механизм (такой, как gRPC) диктует свой формат. В любом случае важно не привязываться к конкретному языку.
Форматы сообщений бывают текстовые и бинарные. Текстовые — такие как XML и JSON. Бинарные — это, например, Protocol Buffers или Avro

Комментарии

Комментарии