Координация повествований
🚨 ОСТОРОЖНО 🚨 Сейчас ты услышишь не самое популярное мнение! Микросервисы это уже не модно. Но до сих пор многие (и я в том числе) продолжают их везде юзать.
Потому что за столько лет все уже научились это делать хорошо и не за чем что-либо менять.
Но есть одна вещь, которую не все научились делать – это нормально координировать эти самые микросервисы. В чем суть? У нас есть большой бизнес-процесс, в рамках него и статусная модель, и транзакции, и уведомления, и какие-то проверки, и прочие интеграции. И вот этот процесс нужно как-то координировать, это не бэкенд сайта с односложной задачей: купить, найти, добавить в корзину и тд. (хотя даже тут иногда нужно что-то координировать).
Почему же нужна координация?
А все очень просто. Когда приложение состоит из множества отдельных сервисов, легко положить забить на согласованность действий и транзакций между ними. Но это не правильно, так как часто изменение состояния одного сервиса должно привести к соответствующим изменениям в другом(их). И вот умные айтишники уже давно придумали два основных подхода в координации:
🐚Хореография
🐚Оркестрация
На самом деле есть еще два подхода:
🐚Полное отсуствие координации // Анархия – мать порядка
🐚Симбиоз из хореографии и оркестрации // I am Venom
Итак, хореография – это
распределение принятия решений и упорядочения действий между участниками повествования, которые в основном общаются, обмениваясь событиями.
По книге Криса Ричардсона «Микросервисы. Паттерны разработки и рефакторинга»
То есть это децентрализованный обмен сообщениями между микросервисами. Каждый сервис сам решает, как реагировать на события, происходящие в других частях системы. По сути это как человеческая многоножка цепочка из сервисов, где каждый участник запускает свой кусок выполнения процесса на основе какого-то триггера, а завершает свой кусок, триггеря следующего по цепочке. При чем такой триггер может прийти извне (например, запрос из браузера, который не является звеном цепи), а следующий по цепочке необязательно должен быть нашим сервисом (например, когда улетает пуш-уведомление, следующий по цепочке клиент).
У этого подхода есть очевидные плюсы в виде отказоустойчивости и масштабируемости, но отсюда вытекают и минусы в виде отсутствия централизации и сложности реализации.
Эту публикацию мы подготовили совместно с Александром. Прочитать про оркестрацию можете здесь
Кого больше в канале?
💃 – хореографы на месте
🎹 – оркестраторы в здании
