Никакие службы не должны знать друг друга.

р: «Как я могу протолкнуть сообщение через группу асинхронных неупорядоченных микросервисов и узнать, когда это сообщение прошло через каждый из них?»

Я изо всех сил пытаюсь найти правильную систему обмена сообщениями / протокол для конкретной архитектуры микросервисов. Это не вопрос «что лучше», а вопрос о том, какие у меня есть варианты для шаблона / протокола проектирования.

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

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

Единственное, полу-элегантное решение, которое я мог придумать, было

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

Но это все еще требует, чтобы каждый сервис был в курсе всех других сервисова также требует от каждой службы оставить свой след. Ни один из них не желателен.

Я открыт для какой-то службы "Пастух".

Я был бы признателен за любые варианты, которые я пропустил, и готов признать, что они могут быть лучшим, фундаментальным дизайном.

Спасибо.

Ответы на вопрос(2)

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

Вы можете определить, какие n сервисов должны его обработать и сколько из n сервисов его обработали.

Никакие службы не должны знать друг друга.

Решение Вопроса

включающей несколько микросервисов): оркестровка и хореография. Есть много статей, описывающих их.

Короче: Воркестровка у вас есть микросервис, который отслеживает состояние процесса и вХореография все микросервисы знают, куда отправлять следующее сообщение и / или когда процесс завершен.

Этотстатья объясняет преимущества и преимущества этих двух стилей.

оркестровка

Преимущества оркестровки

Обеспечивает хороший способ управления потоком приложения при синхронной обработке. Например, если служба A должна успешно завершить работу до вызова службы B.

Оркестровые компромиссы

Соединяет сервисы вместе, создавая зависимости. Если служба A не работает, служба B и C никогда не будут вызываться.

Если для всех запросов существует централизованный общий экземпляр оркестратора, то он является единственной точкой отказа. Если он падает, вся обработка останавливается.

Использует синхронную обработку, которая блокирует запросы. В этом примере общее время сквозной обработки представляет собой сумму времени, которое требуется для вызова Сервиса A + Сервиса B + Сервиса C.

Хореография

Преимущества хореографии

Обеспечивает более быструю сквозную обработку, поскольку службы могут выполняться параллельно / асинхронно.

Легче добавлять / обновлять сервисы, так как их можно легко подключать / выводить из потока событий.

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

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

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

Хореография Компромиссы

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

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

 Apollo21 дек. 2017 г., 18:47
Ах, значит, каждая служба уведомляет оркестратора, когда это сделано, и оркестратор знает, какие службы существуют, и, следовательно, может опубликовать окончательный результат. Это великолепно. Спасибо!
 Apollo21 дек. 2017 г., 18:01
Так что, читая об оркестровке, это кажется уместным и захватывающим, но я до сих пор не понимаю, как я могу написать окончательную «Очередь завершения» после того, как все службы были там разбиты. Как я могу знать, что у каждой службы был свой выстрел?
 Apollo21 дек. 2017 г., 16:55
Вау, какой чудесный исчерпывающий ответ. Я пытаюсь обернуть голову вокруг твоего ответа и статьи. Диаграмма выше - фактически только один шаг в более крупном конвейере ETL. Я думаю, что "реакция между сервисами и оркестровка внутри сервиса" может иметь здесь больше смысла.
 Constantin Galbenu21 дек. 2017 г., 18:31
@ В этом случае Orchestrator записывает / обновляет состояние всего процесса после получения ответа от вышестоящего микросервиса.

Ваш ответ на вопрос