Блог

В монолитной архитектуре интерфейс обычно выполняет один вызов rest для серверной части, а серверная часть делает все за один раз и возвращает код состояния ( 2xx, 4xx, 5xx ). Интерфейс использует этот код состояния для изменения отображения информации пользователю.

В архитектуре микросервисов внешний интерфейс по-прежнему будет выполнять один вызов серверной части, но на этот раз серверная часть, разбитая на микросервисы, может вернуть 2xx от своего внешнего интерфейса, обращенного к микросервису (назовем это SUCCESS-SERVICE ), но может произойти сбой какой-либо другой службы ( FAILED-SERVICE ), что должно привести к откату.

Предполагая, что микросервисы на бэкэнде прослушивают события, и СЛУЖБА УСПЕХА в конечном итоге откатывает свою транзакцию (удаляет запись).

Как следует спроектировать интерфейс, чтобы зафиксировать сбой ПОСЛЕ того, как он уже получил успех от первой службы?

Один из шаблонов, о котором я могу подумать, — это сразу после получения 2xx от службы, опрос о статусе вновь созданного ресурса ( GET /resource/:id ) и поиск определенного набора сообщений о состоянии, которые могут указывать, был ли весь рабочий процесс успешным или неудачным. Учитывая, что серверная служба откатила бы транзакцию, вызов GET в конечном итоге вернет 4xx, потому id что он больше не будет действительным.

Есть ли другой или лучший способ спроектировать переднюю часть?

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

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

Также может быть полезно проверить, как транзакции могут выполняться в микросервисах (интересная статья здесь).