2021-02-25: Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции
м |
м (Массовая правка: замена PCRE ^ на {{RightNote|Еще про архитектуру}}) |
||
| Строка 1: | Строка 1: | ||
| + | {{RightNote|[[:Категория:Архитектура|Еще про архитектуру]]}} | ||
В [https://habr.com/ru/company/oleg-bunin/blog/543946/ '''третьей статье''' «Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции»] из серии «'''Как сделать хорошую интеграцию'''» я рассматриваю разные виды взаимодействия — синхронное, асинхронное, реактивное, и связанные с этим вопросы консистентности и транзакций. Рассматривая взаимодействие, важно не ограничиваться рассмотрением обработки одного сообщения, а рассматривать обработку потока входящих сообщений, иначе нельзя оценить производительность, а главное — можно пропустить неожиданные эффекты интерференции между обработкой разных сообщений, или даже одного сообщения, возникшие между запросом и получением ответа. А для этого надо понимать механику асинхронной и реактивной обработки, которая сейчас скрывается синтаксическим сахаром и библиотеками — внутренние очереди и ожидания. Подобно тому, как для эффективной работы с памятью и обеспечением производительности надо понимать алгоритмы сборки мусора, иначе возможны неожиданные эффекты — утечки памяти, неожиданные провалы производительности при включении сборщика и другие. Так и тут, обрабатываемый объект, например, заказ, вполне может измениться между посылкой сообщения и получением ответа за счет асинхронной обработки другого запроса — и это надо учитывать, в отличие от алгоритмов классической процедурной обработки, хотя может казаться, что у вас — единый поток управления. | В [https://habr.com/ru/company/oleg-bunin/blog/543946/ '''третьей статье''' «Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции»] из серии «'''Как сделать хорошую интеграцию'''» я рассматриваю разные виды взаимодействия — синхронное, асинхронное, реактивное, и связанные с этим вопросы консистентности и транзакций. Рассматривая взаимодействие, важно не ограничиваться рассмотрением обработки одного сообщения, а рассматривать обработку потока входящих сообщений, иначе нельзя оценить производительность, а главное — можно пропустить неожиданные эффекты интерференции между обработкой разных сообщений, или даже одного сообщения, возникшие между запросом и получением ответа. А для этого надо понимать механику асинхронной и реактивной обработки, которая сейчас скрывается синтаксическим сахаром и библиотеками — внутренние очереди и ожидания. Подобно тому, как для эффективной работы с памятью и обеспечением производительности надо понимать алгоритмы сборки мусора, иначе возможны неожиданные эффекты — утечки памяти, неожиданные провалы производительности при включении сборщика и другие. Так и тут, обрабатываемый объект, например, заказ, вполне может измениться между посылкой сообщения и получением ответа за счет асинхронной обработки другого запроса — и это надо учитывать, в отличие от алгоритмов классической процедурной обработки, хотя может казаться, что у вас — единый поток управления. | ||
Текущая версия на 18:21, 7 декабря 2023
В третьей статье «Интеграция: синхронное, асинхронное и реактивное взаимодействие, консистентность и транзакции» из серии «Как сделать хорошую интеграцию» я рассматриваю разные виды взаимодействия — синхронное, асинхронное, реактивное, и связанные с этим вопросы консистентности и транзакций. Рассматривая взаимодействие, важно не ограничиваться рассмотрением обработки одного сообщения, а рассматривать обработку потока входящих сообщений, иначе нельзя оценить производительность, а главное — можно пропустить неожиданные эффекты интерференции между обработкой разных сообщений, или даже одного сообщения, возникшие между запросом и получением ответа. А для этого надо понимать механику асинхронной и реактивной обработки, которая сейчас скрывается синтаксическим сахаром и библиотеками — внутренние очереди и ожидания. Подобно тому, как для эффективной работы с памятью и обеспечением производительности надо понимать алгоритмы сборки мусора, иначе возможны неожиданные эффекты — утечки памяти, неожиданные провалы производительности при включении сборщика и другие. Так и тут, обрабатываемый объект, например, заказ, вполне может измениться между посылкой сообщения и получением ответа за счет асинхронной обработки другого запроса — и это надо учитывать, в отличие от алгоритмов классической процедурной обработки, хотя может казаться, что у вас — единый поток управления.
Пост на FB
