Распределенная транзакция между сервисами в системе микросервисов с использованием Spring-Cloud


Текущая ситуация

Получил проект, использующий: spring-boot, spring-cloud, postgresql в качестве микросервисной системы.

Есть 2 сервиса, скажем SA и SB, они работают с 2 базами данных СУБД соответственно, скажем, DA и DB. .

Теперь есть операция, содержащая 2 подэтапа:

  1. HTTP-клиент сделает запрос к службе SA, чтобы сохранить запись RA в DA.
  2. Затем SA отправляет запрос в службу SB, чтобы сохранить запись RB в DB.

В целом, два подэтапа должны либо фиксироваться, либо откатываться.


Анализ

  • Если переместить обе операции в одну службу, то можно использовать распределенную транзакцию Spring для совмещения ее с JTA (на основе протокола 2PC).
  • Но здесь 2 операции выполняются в 2 службах, и они обмениваются данными по протоколу http REST. Возможно, для решения этой проблемы можно использовать mq + компенсацию, но я не уверен, что есть лучший подход.

Вопросы

  • В этом случае работает ли JTA (на основе 2PC протокола)?
  • If not, what is the preferred solution?
    Possible solutions I can guess:
    1. Refactor code to move the 2 operations into a single service.
    2. Реализуйте архитектуру mq + компенсация для поддержки этого.

person user218867    schedule 14.10.2019    source источник
comment
просто любопытно, какие проблемы вы видите при продвижении по протоколу 2PC, я сам этого не делал, но я прочитал двухфазную фиксацию поддержки загрузки Spring. baeldung.com/transactions-across-microservices & docs.spring.io/spring-boot/docs/current/reference/ html /   -  person Shailesh Chandra    schedule 14.10.2019
comment
@Shailesh 2PC - это guaranteed для распределенной транзакции, с учетом стоимости производительности, проблема заключается в производительности, если существует n сублокальных транзакций, то самая медленная из них определяет общее время глобальной транзакции. IMO, 2PC легче реализовать с помощью инструментов, предоставляемых Java и Spring, по сравнению с решением mq and compensation .   -  person user218867    schedule 14.10.2019
comment
согласен с вами, если частота работы низкая, я бы посоветовал перейти на 2PC, кроме того, что 2PC проще, его будет легко поддерживать / понимать другим разработчикам.   -  person Shailesh Chandra    schedule 14.10.2019


Ответы (1)


Возможно, этот проект будет вам полезен https://github.com/apache/servicecomb-pack

Apache ServiceComb Pack - это в конечном итоге решение для обеспечения согласованности данных для приложений микросервисов. Пакет ServiceComb в настоящее время предоставляет решения для распределенной координации транзакций TCC и Saga с использованием Alpha в качестве координатора транзакций и Omega в качестве агента транзакции.

person Zhang Lei    schedule 19.12.2019