В контексте архитектуры микросервиса создается ориентированный на сообщения асинхронный дизайн на основе событий (см. здесь и здесь для некоторых примеров, а также Реактивный манифест - характеристика, управляемая сообщением) в отличие от синхронного (возможно, основанного на REST) механизма.
Принимая этот контекст и представляя чрезмерно упрощенную систему упорядочения, как показано ниже:
и следующий поток сообщений:
- Заказ помещается из некоторого источника (веб-сайт/мобильный телефон и т.д.).
- Служба заказов принимает заказ и публикует
CreateOrderEvent
- InventoryService реагирует на
CreateOrderEvent
, делает некоторые вещи инвентаря и публикуетInventoryUpdatedEvent
, когда это делается - Затем служба счета-фактуры реагирует на
InventoryUpdatedEvent
, отправляет счет-фактуру и публикуетEmailInvoiceEvent
Все услуги завершены, и мы счастливо обрабатываем заказы... Все счастливы. Затем служба инвентаризации по какой-то причине снижается 😬
Предполагая, что события на шине событий текут в "неблокирующей" усадьбе. То есть сообщения публикуются в центральную тему и не накапливаются в очереди, если никакая служба не читает от нее (то, что я пытаюсь передать, является шиной события, где, если событие опубликовано на шине, оно будет течь "прямо", а не в очереди - игнорируйте, какая платформа/технология обмена сообщениями используется в этой точке). Это означало бы, что если служба инвентаризации снизилась в течение 5 минут, CreateOrderEvent
, проходящая через шину событий в течение этого времени, теперь "ушла" или не увидена службой Inventory, потому что в нашей слишком упрощенной системе никакая другая система не заинтересована в этих событиях.
Теперь мой вопрос: как служба инвентаризации (и система в целом) восстанавливает состояние таким образом, что никакие заказы не будут упущены/не обработаны?