Здравствуйте, vsb, Вы писали:

vsb>Есть несколько сервисов. У каждого своя БД. Часть данных условно общая, т.е. идёт синхронизация между этими сервисами. Ну к примеру пришли данные в первый сервис, он их принял, положил в свою базу и отправил во второй сервис. Второй сервис их обработал и отправил какой-то результат в первый сервис. И тд.
vsb>Если не думать про ошибки, то всё просто. Но на практике сервис может временно не работать.
Задача совершенно типовая и имеет два типовых решения.

1. Промежуточный сервис очередей. Изменение кладется в промежуточную очередь. Промежуточная очередь недостаточно стабильна, для гарантий репликации. По этому сами запросы, вызывающие изменения в сервисе тоже должны поступать через промежуточную очередь. Чтобы повторятся до тех пор, пока сервис не сделает все что нужно. Или внешний сервис должен гарантировать что будет повторять запрос, пока ему не ответят ок. Сейчас для этого обычно использую Kafka — так как другие очереди слишком тяжеловесны, и слишком ненадежны и плохо переваривают большие объекты.
   
2. Реализовать внутри сервиса конечный автомат, который гарантирует что при поступлении запроса выполнит все шаги связанные с запросами. Это все называется паттерном Saga. У него много вариаций, например паттерн Workflow. Есть готовые библиотеки, и свервисы реалзующи его. Но ни чего удобного для использования нет, по этому обычно копании вынуждены пилить свой велосипед.

Первый вариант значительно проще в реализации, но имеет ряд ограничений. Ключевых недостатков два — резкое возрастание латентности в обработке запросов, и очень сложно реализовать решение в парадигме запрос-ответ. Вообще варан с очередью хорошо работает, в тех случаях когда не нужно знать результаты обработки запроса. Это называет event-streaming. С некоторым опытом примерно в 90% случаев, можно написать систему так, чтобы пользователю или сервису не будет нужен ответ. Например если пользователь постит сообщение в чатик, ему не нужно знать что сообщение уже размещено, достаточно написать что сообщение отправлено. В той же телеге, с начало сообщение без галочек (поставлено в очередь на отправку на клиенте), потом с галочкой (поставлено в очередь сервера), потом с двумя галочками (прочитано абонентом). Если требуется получать ответы на запрос, то все начинает превращаться в ад. Вариант с сагами решен этих недостатков. То-есть латентность низкая, результаты обработки получаются легко, ответ внешнему абоненту дать еще проще. Хорошо подходит для сложных бизнес процессов, когда любой запрос проходит через десятки разных стадий, при этом на каждой следующей используются результаты предыдущей. Но требует использования сложных библиотек, которые придется дорабатывать под конкретные потребности.


vsb>1. Использовать полновесный сервер очередей. Сто лет назад я работал с websphere mq. Наверное сейчас есть получше что-нибудь.
Эти сервера решали другие задачи, а именно оркестрацию сообщений. То-есть возможность менять поведение приложение без его повторного деплоя. В времена двопс это бессмыслено чуть менее чем полностью. Ну и обеспечение связанности системы через подписку на сообщения. Но опять таки быстрые релизы и Service-discavery с успехом решают эту проблему.

vsb>Будем считать, что очередь работает всегда и данные в ней никогда не теряются.
Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.

vsb>2. Использовать легковесный сервер очередей, что-то вроде kafka. С ней я толком не работал, но представляю это так: в очередь кладём не данные, а только id. На отдающем сервере делаем endpoint, который по этому id отдаёт данные.
Это искуственное ограничение — кафка отлично справляется с большими сообщениями, так что если у вас там не по 500 мегабай данных в сообщении, так усложнять систему не нужно.

vsb>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.
Да, сага и есть такой конечный автомат, где на каждой стадии выполняется какая-то работа. Нормальные реализации паттерна Сага позволяют собрать это все в одно место, например в один класс.

vsb>3. Я когда-то сталкивался с т.н. business process management платформами. Там рисуешь процесс по блок-схеме, прописываешь действия и тд, а движок уже отвечает за то, чтобы хранить состояния, вызывать действия и тд.
Это реализации паттерна workflow. Но заточенные на другое. Раньше ими решали проблему того как быстро поправить бизнес процесс если деплой приложения происходит один раз в два года. Я надеюсь у вас не так и вы можете деплоится хотябы раз в неделю? Ну и влажная мечта всех менеджеров — возможность нарисовать бизнес-просесс не привлекая программистов, что не осуществимо по определеню — тот кто рисует бизнес процесс в компьютере и зовется программистом. Мой опыт говорит, что если нужен результат, то конфигурация Workflow должна деплоится строго вместе с приложением, и ни как иначе. Иначе разработка становится бесконечной и бессмысленной корпоративной работой без всякого результата на выходе. Желательно чтобы конфигурация Workflow была написана на том же языке программирования, на котором и остальной код.


vsb>Менеджмент предлагает использовать airflow в виде такого движка.
Airflow это и артефакт той эпохи, когда искренне верили что менджеры смогут писать код рисуя красивые блок-схемы. Но его с тех пор сильно допилили, так что на нем вполне можно сделать то что вам нужно. Но я бы посоветовал поискать что-нибудь полегковестнее. Сейчас опенсурсят по пять сага-фремворков в год, и лидер вроде как еще не определился, но я уверен что есть весьма достойные кандидаты.

Здравствуйте, vsb, Вы писали:

vsb>Есть несколько сервисов. У каждого своя БД. Часть данных условно общая, т.е. идёт синхронизация между этими сервисами. Ну к примеру пришли данные в первый сервис, он их принял, положил в свою базу и отправил во второй сервис. Второй сервис их обработал и отправил какой-то результат в первый сервис. И тд.
vsb>Если не думать про ошибки, то всё просто. Но на практике сервис может временно не работать.
Задача совершенно типовая и имеет два типовых решения.

1. Промежуточный сервис очередей. Изменение кладется в промежуточную очередь. Промежуточная очередь недостаточно стабильна, для гарантий репликации. По этому сами запросы, вызывающие изменения в сервисе тоже должны поступать через промежуточную очередь. Чтобы повторятся до тех пор, пока сервис не сумеет пропихнуть запрос дальше. Или внешний сервис должен гарантировать что будет повторять запрос, пока ему не ответят ок. Сейчас для этого обычно использую Kafka — так как другие очереди слишком тяжеловесны, и слишком ненадежны и плохо переваривают большие объекты.
   
2. Реализовать внутри сервиса конечный автомат, который гарантирует что при поступлении запроса выполнит все шаги связанные с запросами. Это все называется паттерном Saga. У него много вариаций, например паттерн Workflow. Есть готовые библиотеки, и свервисы реалзующи его. Но ни чего удобного для использования нет, по этому обычно копании вынуждены пилить свой велосипед.

Первый вариант значительно проще в реализации, но имеет ряд ограничений. Ключевых недостатков два — резкое возрастание латентности в обработке запросов, и очень сложно реализовать решение в парадигме запрос-ответ. Вообще вариант с очередью, хорошо работает, в тех случаях когда не нужно знать результаты обработки запроса. Это называет event-streaming. С некоторым опытом, примерно в 90% случаев, можно написать систему так, чтобы пользователю или сервису не будет нужен ответ. Например если пользователь постит сообщение в чатик, ему не нужно знать что сообщение уже размещено, достаточно написать что сообщение отправлено. В той же телеге, с начало сообщение без галочек (поставлено в очередь на отправку на клиенте), потом с галочкой (поставлено в очередь сервера), потом с двумя галочками (прочитано абонентом). Если требуется получать ответы на запрос, то все начинает превращаться в ад. Вариант с сагами лишен этих недостатков. То-есть латентность низкая, результаты обработки получаются легко, ответ внешнему абоненту дать еще проще. Хорошо подходит для сложных бизнес процессов, когда любой запрос проходит через десятки разных стадий, при этом на каждой следующей стадии используются результаты предыдущей. Но требует использования сложных библиотек, которые придется дорабатывать под конкретные потребности.


vsb>1. Использовать полновесный сервер очередей. Сто лет назад я работал с websphere mq. Наверное сейчас есть получше что-нибудь.
Эти сервера решали другие задачи, а именно оркестрацию сообщений. То-есть возможность менять поведение приложение без его повторного деплоя. В времена двопс это бессмысленно чуть менее чем полностью. Ну и обеспечение связанности системы через подписку на сообщения. Но опять таки быстрые релизы и Service-discavery с успехом решают эту проблему.

vsb>Будем считать, что очередь работает всегда и данные в ней никогда не теряются.
Вы же понимаете что это нереально? Сервис очередей высоконагруженный и персистентный. Последнее означает, что по CAP теореме будет низко-надежным и плохо-масштабирующимся. Читай как самой часто-ломающейся частью системы.

vsb>2. Использовать легковесный сервер очередей, что-то вроде kafka. С ней я толком не работал, но представляю это так: в очередь кладём не данные, а только id. На отдающем сервере делаем endpoint, который по этому id отдаёт данные.
Это искусственное ограничение — кафка отлично справляется с большими сообщениями, так что если у вас там не по 500 мегабайт данных в сообщении, так усложнять систему не нужно.

vsb>Вообще по сути вся эта машинерия очень напоминает что-то вроде state machine, где всё распределено, схема неявным образом спрятана в коде, который обрабатывает это всё.
Да, сага и есть такой конечный автомат, где на каждой стадии выполняется какая-то работа. Нормальные реализации паттерна Сага позволяют собрать это все в одно место, например в один класс.

vsb>3. Я когда-то сталкивался с т.н. business process management платформами. Там рисуешь процесс по блок-схеме, прописываешь действия и тд, а движок уже отвечает за то, чтобы хранить состояния, вызывать действия и тд.
Это реализации паттерна workflow. Но заточенные на другое. Раньше ими решали проблему того как быстро поправить бизнес процесс, если деплой приложения происходит один раз в два года. Я надеюсь у вас не так и вы можете деплоится хотябы раз в неделю? Ну и влажная мечта всех менеджеров — возможность нарисовать бизнес-просесс не привлекая программистов, что не осуществимо по определению — тот кто рисует бизнес процесс в компьютере и зовется программистом. Мой опыт говорит, что если нужен результат, то конфигурация Workflow должна деплоится строго вместе с приложением, и ни как иначе. Иначе разработка становится бесконечной и бессмысленной корпоративной работой без всякого результата на выходе. Желательно чтобы конфигурация Workflow была написана на том же языке программирования, на котором и остальной код.


vsb>Менеджмент предлагает использовать airflow в виде такого движка.
Airflow это и артефакт той эпохи, когда искренне верили что менеджеры смогут писать код рисуя красивые блок-схемы. Но его с тех пор сильно допилили, так что на нем вполне можно сделать то что вам нужно. Но я бы посоветовал поискать что-нибудь легковеснее. Сейчас опенсурсят по пять сага-фремворков в год. Лидер вроде как еще не определился. Я уверен что есть весьма достойные кандидаты.