2015-09-11 5 views
4

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

например: следующий метод является частью Legal Service

@Autowired 
public ServiceManager UserServiceManager; 

public void updateUserLegalData(){ 

    //do db update of Legal info for the user 

    userServiveManager.setAcceptedLegal(true); 


} 

Есть два db transactions происходит выше. один обновляет legalService db, а другой обновляет UserService db. ПРИМЕЧАНИЕ. userService - это microservice, работающий на отдельной виртуальной машине.

Мы видим ситуации, когда юридическая служба db обновляется, но вызывает функцию userService сбой (Internal server error). поэтому это оставляет приложение в несогласованном состоянии. Как мы можем исправить это в рекомендуемом порядке?

Благодаря

ответ

2

Эта ситуация может быть обработан только с ССТ глобальных/распределенных транзакций. JTA является частью стандарта Java EE и может иметь различные исполнители. Atomikos часто является инструментом выбора.

Here is good writeup from Dave Syer (Spring ecosystem contributor). В него также включены рабочие примеры. Это немного устарело, но все же актуально. Вы можете применить некоторые более современные абстракции Spring поверх своих примеров.

Я создал несколько GitHub examples of JTA transactions для моей книги. Обратите внимание, что есть ошибки, имитируемые, а транзакция распространяется по источникам данных JMS и JDBC.

Но также помните, что транзакции JTA через различные источники данных медленны из-за использования алгоритма с 2-фазным фиксацией. Так часто люди стараются избегать их и как-то прагматично относятся к несоответствиям.

+0

спасибо. есть ли ссылка на вашу книгу? –

+0

http://www.apress.com/9781484207949. Но это еще не закончено. Работа над последней главой в настоящее время. – luboskrnac

+0

> Операции JTA медленны и в настоящее время часто рассматриваются как архитектурные анти-шаблоны' - я думаю, что обратное верно. В эти дни транзакции JTA оптимизированы настолько, что для их использования едва ли накладные расходы. Когда вы используете только один транзакционный ресурс или один ресурс tx, а также один-другой LRCO, можно также применить любые возможные затраты, связанные с двухфазными фиксациями. –

2

Не выполняйте распределенные транзакции.

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

Cheers, Майкл

0

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

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

Итак, в чем альтернатива, я лично разработал еще одну концепцию и написал блог об этом, это может быть интересно для вас.В своих базовых принципах он использует полные принципы проектирования микросервиса и Spring Boot + Netflix в контейнере J2EE и полностью использует транзакции, слишком долго писать все подробности здесь, если вам интересно, вы можете прочитать их по приведенной ниже ссылке.

Micro Services and Transactions with Spring Boot + Netflix

Смежные вопросы