автордың кітабынан сөз тіркестері  Реактивные шаблоны проектирования

Джейми Аллен, Роланд Кун, Брайан Ханафи

делью акторов. Все это основано на применении парадигмы функционального программирования, с которой мы и начнем.

В следующей главе мы познакомимся с соответствующими инструментами: циклами обработки событий, объектами Future и Promise, библиотекой Reactive Extensions и мо

Основная идея предыдущего абзаца состоит в том, что применение синхронных, блокирующих программных интерфейсов, скрывающих внутри себя основанную на сообщениях структуру, — это пустая трата ресурсов процессора. Если сделать сообщения явной частью API — так, чтобы вместо приостановки потоков вы останавливали вычисления, позволяя потокам заняться чем-то другим, — эти накладные расходы были бы существенно снижены.

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

Вам, наверное, интересно, зачем нужен второй этап — асинхронное составление результата? Разве уменьшения времени ожидания ответа путем использования параллельного выполнения недостаточно? Вспомним, что наша цель — ограничить время ожидания в системе вложенных взаимоотношений между пользователем и сервисами, где каждый новый уровень использует сервис, находящийся уровнем ниже. Поскольку параллельное выполнение подзадач A, B и C зависит от возвращения вызвавшими их методами объектов Future вместо реальных результатов, это применимо и ко всей задаче в целом

Основная идея состоит в добавлении необходимой инкапсуляции и асинхронных границ путем взаимодействия с ресурсом в рамках

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

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

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

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