Микросервисы: Обмен данным между микросервисами

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

Вступление

Построить взаимодействие можно разными способами, я опишу три: "Простой", "Смешанный", "Полный". Названия обусловлены принципами реализации. Скажу честно, названия я придумал, потому что не нашел нигде подобной классификации.

Спрособ "Простой"

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

В такой архитектуре:

• Данные передаются по средствам протокола HTTP, который по определению не поддерживается состояние сеанса (stateless). 
• Данные читаются и записываются по одним и тем же каналам.

Плюсы

1. Простой способ реализации без использования дополнительных технологий.
2. Относительно быстрый вариант, потому что не требуется каких-либо надстроек в иерахии обмена данными.

Минусы

1. Разобщенность в форматах передаваемых данных между сервисами.
2. Существует вероятность потери данных при общении между сервисами в силу использования HTTP (only)
3. Реструктуризация схемы общения меджу сервисами (например, ввод нового сервиса) трудозатратна по причине обязательно реорганизации существующих связей.

Способ "Смешанный"

Отличие данного способа в том, что данные читаеют по одним каналам, а записывают по другим. Причем речь идет не обо всех данных, а об особо чувствительных в сохранению. То есть о тех типах, сохранение которых имеет принципиальное значение.

На схеме показана реализация обмена некоторыми данными через специальные каналы. Например, через "очередь сообщений".

Плюсы

1. Не требует реализации для всех сущностей дополнительных "надстроек", которые обеспечивают взаимодействие с системой обмена сообщений
2. Относительно способа "Полного" достаточно быстрый вариант реализации

Минусы

1. Нет общей принципа и подхода.
2. Разобщенность в форматах передаваемых данных между сервисами.
3. Реструктуризация схемы общения меджу сервисами (например, ввод нового сервиса) трудозатратна по причине обязательно реорганизации существующих связей для связанных сущностей.
4. При масштабировании системы невозможно предусмотреть какие изменения и в какой из реализаций обмена собщениями потребуются произвести. Возможные зависимости придется также переводить на формат общений через очередь.

Способ "Полный"

При полном певеводе микросервисной системы на общение через очереди сообщений, архитектура принимает следующую форму.

Все сообщения между сервисами происходят через систему сообщений.

Плюсы

1. Общий формат обмена сообщений
2. При использовании специальных технологий, возможна типизация сообщений (.NET )
3. Брокер сообщений гарантирует доставку собщения до адресата
4. Брокер сообщений может осуществлять маргрутизацию
5. Брокер сообщений позволяет осуществить подписку на сообщения определеных типов
6. Брокер сообщений позволяет осуществить распределение потоков данных (масштабирование системы)
7. При появлении в системе новых сервисов, переделка других не потребуется
8. При изменении бизнес-правил достаточно будет подписаться на другие события (меняются типы)

Минусы

1. Трудоемкий процесс первичной настройки и реализации вспомогательных типов, классов, wrappers, consumers и subscribers

Заключение

Важно понять следующее. При выборе "простого" решения, переделка его на "смешанный" и, тем более, на "полный" потребует не частичной, а полной переделки инфрастуктуры. Сущестующие механизмы "общения" между сервисами придется не обновить, а заменить, при этом реализовать более сложную систему вспомогательных классов (consumer, publisher, subscriber, etc).

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