2021-02-25: Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции

Материал из MaksWiki
Перейти к: навигация, поиск
(Новая страница: «В [https://habr.com/ru/company/oleg-bunin/blog/543946/ '''третьей статье'''] из серии «'''Как сделать хорошую интегр…»)
 
м
Строка 1: Строка 1:
В [https://habr.com/ru/company/oleg-bunin/blog/543946/ '''третьей статье'''] из серии «'''Как сделать хорошую интеграцию'''» я рассматриваю разные виды взаимодействия - синхронное, асинхронное, реактивное, и связанные с этим вопросы консистентности и транзакций. Рассматривая взаимодействие, важно не ограничиваться рассмотрением обработки одного сообщения, а рассматривать обработку потока входящих сообщений, иначе нельзя оценить производительность, а главное - можно пропустить неожиданные эффекты интерференции между обработкой разных сообщений, или даже одного сообщения, возникшие между запросом и получением ответа. А для этого надо понимать механику асинхронной и реактивной обработки, которая сейчас скрывается синтаксическим сахаром и библиотеками - внутренние очереди и ожидания. Подобно тому, как для эффективной работы с памятью и обеспечением производительности надо понимать алгоритмы сборки мусора, иначе возможны неожиданные эффекты - утечки памяти, неожиданные провалы производительности при включении сборщика и другие. Так и тут, обрабатываемый объект, например, заказ, вполне может измениться между посылкой сообщения и получением ответа за счет асинхронной обработки другого запроса - и это надо учитывать, в отличие от алгоритмов классической процедурной обработки, хотя может казаться, что у вас - единый поток управления.
+
В [https://habr.com/ru/company/oleg-bunin/blog/543946/ '''третьей статье''' «Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции»] из серии «'''Как сделать хорошую интеграцию'''» я рассматриваю разные виды взаимодействия — синхронное, асинхронное, реактивное, и связанные с этим вопросы консистентности и транзакций. Рассматривая взаимодействие, важно не ограничиваться рассмотрением обработки одного сообщения, а рассматривать обработку потока входящих сообщений, иначе нельзя оценить производительность, а главное — можно пропустить неожиданные эффекты интерференции между обработкой разных сообщений, или даже одного сообщения, возникшие между запросом и получением ответа. А для этого надо понимать механику асинхронной и реактивной обработки, которая сейчас скрывается синтаксическим сахаром и библиотеками — внутренние очереди и ожидания. Подобно тому, как для эффективной работы с памятью и обеспечением производительности надо понимать алгоритмы сборки мусора, иначе возможны неожиданные эффекты — утечки памяти, неожиданные провалы производительности при включении сборщика и другие. Так и тут, обрабатываемый объект, например, заказ, вполне может измениться между посылкой сообщения и получением ответа за счет асинхронной обработки другого запроса — и это надо учитывать, в отличие от алгоритмов классической процедурной обработки, хотя может казаться, что у вас — единый поток управления.
  
 
  [https://www.facebook.com/mtsepkov/posts/3812691015454491 Пост на FB]
 
  [https://www.facebook.com/mtsepkov/posts/3812691015454491 Пост на FB]

Версия 11:31, 22 сентября 2021

В третьей статье «Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции» из серии «Как сделать хорошую интеграцию» я рассматриваю разные виды взаимодействия — синхронное, асинхронное, реактивное, и связанные с этим вопросы консистентности и транзакций. Рассматривая взаимодействие, важно не ограничиваться рассмотрением обработки одного сообщения, а рассматривать обработку потока входящих сообщений, иначе нельзя оценить производительность, а главное — можно пропустить неожиданные эффекты интерференции между обработкой разных сообщений, или даже одного сообщения, возникшие между запросом и получением ответа. А для этого надо понимать механику асинхронной и реактивной обработки, которая сейчас скрывается синтаксическим сахаром и библиотеками — внутренние очереди и ожидания. Подобно тому, как для эффективной работы с памятью и обеспечением производительности надо понимать алгоритмы сборки мусора, иначе возможны неожиданные эффекты — утечки памяти, неожиданные провалы производительности при включении сборщика и другие. Так и тут, обрабатываемый объект, например, заказ, вполне может измениться между посылкой сообщения и получением ответа за счет асинхронной обработки другого запроса — и это надо учитывать, в отличие от алгоритмов классической процедурной обработки, хотя может казаться, что у вас — единый поток управления.

Пост на FB