Координация повествований 🚨 ОСТОРОЖНО 🚨 Сейчас ты услышишь не самое популярное мнение! Микросервисы это уже не модно. Но до сих пор многие (и я в том числе) продолжают их везде юзать. Потому что за столько лет все уже научились это делать хорошо и не за чем что-либо менять.

Но есть одна вещь, которую не все научились делать – это нормально координировать эти самые микросервисы. В чем суть? У нас есть большой бизнес-процесс, в рамках него и статусная модель, и транзакции, и уведомления, и какие-то проверки, и прочие интеграции. И вот этот процесс нужно как-то координировать, это не бэкенд сайта с односложной задачей: купить, найти, добавить в корзину и тд. (хотя даже тут иногда нужно что-то координировать).

Почему же нужна координация? А все очень просто. Когда приложение состоит из множества отдельных сервисов, легко положить забить на согласованность действий и транзакций между ними. Но это не правильно, так как часто изменение состояния одного сервиса должно привести к соответствующим изменениям в другом(их). И вот умные айтишники уже давно придумали два основных подхода в координации: 🐚Хореография 🐚Оркестрация

На самом деле есть еще два подхода: 🐚Полное отсуствие координации // Анархия – мать порядка 🐚Симбиоз из хореографии и оркестрации // I am Venom

Итак, хореография – это распределение принятия решений и упорядочения действий между участниками повествования, которые в основном общаются, обмениваясь событиями. По книге Криса Ричардсона «Микросервисы. Паттерны разработки и рефакторинга»

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

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

Эту публикацию мы подготовили совместно с Александром. Прочитать про оркестрацию можете здесь

Кого больше в канале? 💃 – хореографы на месте 🎹 – оркестраторы в здании

В этом посте были ссылки, но мы их удалили по правилам Сетки