практика реактивного программирования в spring 5 pdf
Знакомство с реактивным программированием в Spring
На этой неделе мы ожидаем из типографии новую книгу по Spring 5:
Среди интересных возможностей Spring 5 отдельного упоминания заслуживает реактивное программирование, о реализации которого в этом фреймворке кратко рассказывает предлагаемая статья Мэтта Рэйбла (Matt Raible). В вышеупомянутой книге реактивные паттерны рассмотрены в главе 11.
Соавтором Мэтта выступил Джош Лонг, автор еще одной отличной книги про Java и Spring, «Java в облаке», вышедшей у нас прошлым летом.
Реактивное программирование – ваш путь к созданию систем, устойчивых к высоким нагрузкам. Обработка огромного трафика – уже не проблема, так как сервер неблокирующий, и клиентским процессам не приходится дожидаться откликов. Клиент не может непосредственно наблюдать, как программа выполняется на сервере, и синхронизироваться с нею. Когда API затрудняется с обработкой запросов, он должен все равно давать разумные отклики. Не должен отказывать и отбрасывать сообщения неконтролируемым образом. Должен сообщать вышестоящим компонентам о том, что работает под нагрузкой, чтобы те могли его частично от этой нагрузки освободить. Такой прием называется «обратный поток» (backpressure), это важный аспект реактивного программирования.
Эту статью мы написали в соавторстве с Джошем Лонгом. Джош – Java-чемпион, Spring Developer Advocate и вообще мировой парень, работающий в Pivotal. Я давно работаю со Spring, но именно Джош показал мне Spring Boot, это было на конференции Devoxx в Бельгии. С тех пор мы крепко сдружились, увлекаемся Java и пишем классные приложения.
Реактивное программирование или I/O, I/O, на работу мы идем…
Реактивное программирование – это такой подход к созданию ПО, при котором активно используется асинхронный ввод/вывод. Асинхронный ввод/вывод – небольшая идея, чреватая большими переменами в программировании. Сама идея проста: исправить ситуацию с неэффективным распределением ресурсов, высвобождая те ресурсы, которые без нашего вмешательства простаивали бы впустую, дожидаясь завершения ввода/вывода. Асинхронный ввод/вывод инвертирует привычный подход к обработке I/O: клиент освобождается и может заниматься другими задачами, ожидая новых уведомлений.
Рассмотрим, что общего между синхронным и асинхронным вводом/выводом, и каковы отличия между ними.
Напишем простую программу, считывающую данные из источника (конкретно – речь о ссылке java.io.File ). Начнем с реализации, в которой используется старый добрый java.io.InputStream :
Пример 1. Синхронное считывание данных из файла
В данном примере основной кусок работы приходится на считывание – на других фронтах почти ничего не происходит. Мы зависим от ввода/вывода. Рассмотрим, как асинхронное решение помогает нам частично побороть монополизацию наших потоков.
Пример 2. Асинхронное считывание данных из файла
Я работаю в компании, занимающейся облачными вычислениями. Мы хотели бы, чтобы для решения проблем с горизонтальным масштабированием вы приобретали все новые инстансы приложения! Разумеется, здесь я немного лукавлю. Асинхронный ввод/вывод немного усложняет ситуацию, но, надеюсь, этот пример иллюстрирует, чем же так полезен реактивный код: он позволяет обрабатывать больше запросов и выполнять больше работы на имеющемся аппаратном обеспечении, если производительность сильно зависит от ввода/вывода. Если производительность работы зависит от использования процессора (скажем, речь об операциях над числами Фибоначчи, майнинге биткойнов или криптографии), то реактивное программирование ничего нам не даст.
Если бы Iterator и Stream действительно поддерживали push-обработку, то мы столкнулись бы с другой проблемой, которая по-настоящему обостряется именно в контексте I/O: нам понадобится какой-либо механизм обратного проникновения! Поскольку потребитель данных обрабатывается асинхронно, мы понятия не имеем, когда данные окажутся в конвейере и в каком количестве. Не знаем, сколько данных потребуется обработать при следующем обратном вызове: один байт или один терабайт!
Поиск недостающей метафоры
В данном случае мы ищем метафору, которая бы красиво отражала суть асинхронного ввода/вывода, поддерживала такой механизм обратной передачи данных и позволяла контролировать поток выполнения в распределенных системах. В реактивном программировании возможность клиента просигнализировать, с какой нагрузкой он в состоянии справиться, называется «обратный поток».
Сейчас существует ряд хороших проектов — Vert.x, Akka Streams и RxJava – поддерживающих реактивное программирование. Команда Spring также ведет такой проект, именуемый Reactor. Между этими различными стандартами есть достаточно широкое обще поле, де-факто выделенное в стандарт Reactive Streams initiative. В Reactive Streams initiative определяется четыре типа:
Reactor – это опенсорсный проект, запущенный компанией Pivotal; сейчас он стал очень популярен. Facebook использует его в своем реактивном механизме для вызова удаленных процедур, также применяется в Rsocket, под руководством создателя RxJava Бена Кристенсена. Salesforce использует его в своей реактивной реализации gRPC. Reactor реализует типы Reactive Streams, поэтому может взаимодействовать с другими технологиями, поддерживающими эти типы, например, с RxJava 2 от Netflix, Akka Streams от Lightbend и с проектом Vert.x от Eclipse Foundation. Дэвид Кэрнок, руководитель RxJava 2, также активно сотрудничал с Pivotal по разработке Reactor, благодаря чему проект стал еще лучше. Плюс, естественно, он в той или иной форме присутствует в Spring Framework, начиная с Spring Framework 4.0.
Реактивное программирование с Spring WebFlux
При всей своей полезности Reactor – это просто базис. Наши приложения должны коммуницировать с источниками данных. Должны поддерживать аутентификацию и авторизацию. Spring все это предоставляет. Если Reactor дает нам недостающую метафору, то Spring помогает всем нам разговаривать на общем языке.
Spring Framework 5.0 вышел в сентябре 2017. Он строится на Reactor и спецификации Reactive Streams. В нем есть новая реактивная среда исполнения и модель компонентов под названием Spring WebFlux.
Spring WebFlux не зависит от Servlet API и не требует их для работы. Он поставляется с адаптерами, позволяющими использовать его поверх движка Servlet, если потребуется, но это не обязательно. Также в нем предоставляется совершенно новая среда исполнения на основе Netty, называется Spring WebFlux. Spring Framework 5, работающий с Java 8 и Java EE 7 и выше, теперь служит основой для большей части экосистемы Spring, в том числе, для Spring Data Kay, Spring Security 5, Spring Boot 2 и Spring Cloud Finchley.
Современному бизнесу необходимы программные системы нового типа, способные оставаться отзывчивыми при любых нагрузках. Эту потребность можно удовлетворить с использованием приемов реактивного программирования; однако разработка таких систем – сложная задача, требующая глубокого понимания предметной области. Для разработки отзывчивых систем разработчики Spring Framework придумали и создали проект Project Reactor. Данная книга начинается с основ реактивного программирования в Spring. Вы
исследуете многочисленные возможности построения эффективных реактивных систем с помощью Spring 5 и других инструментов, таких как WebFlux и Spring Boot. Познакомитесь с методами реактивного программирования и научитесь использовать их для взаимодействий с базами данных и между серверами. Освоите навыки масштабирования с Spring Cloud Streams и научитесь создавать
независимые и высокопроизводительные реактивные микросервисы.
С помощью этой книги вы:
— откроете разницу между реактивной системой и реактивным программированием;
— исследуете преимущества реактивных систем и область их применения;
— освоите приемы реактивного программирования в Spring 5;
— получите представление о Project Reactor;
— построите реактивную систему с использованием Spring 5 и Project Reactor;
— создадите высокоэффективный реактивный микросервис с использованием Spring Cloud;
— научитесь тестировать, выпускать и осуществлять мониторинг реактивных приложений.
Практика реактивного программирования в spring 5 pdf
Hands-On Reactive Programming in Spring 5
This is the code repository for Hands-On Reactive Programming in Spring 5, published by Packt.
Build cloud-ready, reactive systems with Spring 5 and Project Reactor
What is this book about?
If you feel this book is for you, get your copy today!
Oleh Dokuka is an experienced software engineer, Pivotal Champion, and one of the top contributors to Project Reactor and Spring Framework. He knows the internals of both frameworks very well and advocates reactive programming with Project Reactor on a daily basis. Along with that, the author applies Spring Framework and Project Reactor in software development, so he knows how to build reactive systems using these technologies.
Igor Lozynskyi is a senior Java developer who primarily focuses on developing reliable, scalable, and blazingly fast systems. He has over seven years of experience with the Java platform. He is passionate about interesting and dynamic projects both in life and in software development.
All code samples should run on any operating system where the appropriate Java runs. Some examples require Docker Engine.
There is no hard requirement for OS. However, examples use JDK8 and later, Docker Engine 18.06 and later, and also download native executables (embedded MongoDB). Consequently, for successful execution, all software described above should work on your OS.
Tested operation systems: MacOS High Sierra, Windows 10, Ubuntu Linux 16.04 LTS.
All examples were developed with JDK8 and tested to be compatible with JDK11. Because of the significant changes introduced by JDK11, some examples may display warnings or run only on JDK8.
To install JDK8, please refer to these instructions: http://jdk.java.net/8
To install JDK11, please refer to these instructions: http://jdk.java.net/11
A couple of examples assume running Docker Engine to start supporting services (MongoDB, PostgreSQL, Prometheus, etc.)
Only Chapter 10’s example requires running Docker commands manually, other examples do automatic service provisioning.
To install Docker Engine on your PC, please follow the official instructions: https://docs.docker.com/install
All examples use Gradle build system, so they are not IDE dependent. However, we recommend using a free version of IntelliJ IDEA for a seamless exploration of the provided examples. We recommend using the latest version of IntelliJ IDEA as it has better support for JDK11.
The Community Edition of IntelliJ IDEA may be downloaded here: https://www.jetbrains.com/idea/download
Many examples use a handy the Lombok library (https://projectlombok.org/) which require annotation processing. Consequently, please install IntelliJ Lombok plugin (https://github.com/mplushnikov/lombok-intellij-plugin).
All code in this repository is for demonstration purposes and, consequently, often oversimplified.
Chapter 1: Why Reactive Spring?
Contains the following examples:
Chapter 5: Going Reactive with Spring Boot 2
Chapter 6: WebFlux Async Non-blocking Communication
Chapter 7: Reactive Database Access
Chapter 8: Scaling Up with Cloud Streams
this is an example of Chat application that is fully decoupled and ready to be run in the cloud. The following is a steps required to prepare this sample:
The Project uses MongoDB as the primary database for all data’s querying and storing.
There are two available options in order to install MongoDB:
(Option 1) Dockerized MongoDB
Before starting that option, please ensure that Docker (has already been installed on the local machine).
It is necessary to execute the following command in the terminal to run MongoDB image in the Docker container:
(Option 2) Local Community MongoDB Server
There is an option to install MongoDB locally. All required information related to the local installation is available by the following link.
The Project uses RabbitMQ as a message broker for this example
There are two available options in order to install RabbitMQ:
(Option 1) Dockerized RabbitMQ
Before starting that option, please ensure that Docker (has already been installed on the local machine).
It is necessary to execute the following command in the terminal to run MongoDB image in the Docker container:
(Option 2) Local Community MongoDB Server
There is an option to install RabbitMQ locally. All required information related to the local installation is available by the following link.
Preparing the Environment
To properly run the Project the proper environment variables / YAML properties are required. The following is the list of available Spring Framework properties/environment variables:
Chapter 9: Testing the Reactive Application
Chapter 10: And, Finally, Release It!
This sample depicts a reactive application based on Spring Boot 2 and WebFlux with all required infrastructure for operational monitoring.
Prometheus pulls metrics, Grafana has a simple dashboard with app metrics, Zipkin gathers traces.
Start or stop infrastructural services
To start services run the following command:
To stop services run the following command:
Start Spring Boot application
Accessing application components
Your feedback is important for us, so do not hesitate creating issues if some examples do not work with your environment.
Also, please star of fork this repository if you find it useful!
About
Hands-On Reactive Programming in Spring 5, published by Packt
Реактивное программирование со Spring, часть 1 Введение
Это первая часть серии заметок о реактивном программировании, в которой представлен обзор различных концепций реактивного программирования и их истории.
1. Почему реактивное программирование
Реактивное программирование существует уже некоторое время, но за последние пару лет оно стало вызывать гораздо больший интерес. Причина этого связана с тем фактом, что традиционное императивное программирование имеет некоторые ограничения, когда дело доходит до удовлетворения требований сегодняшнего дня, когда приложения должны иметь высокую доступность и обеспечивать низкое время отклика даже при высокой нагрузке.
1.1 Модель поток на запрос
Если приложение разработано в соответствии с архитектурой на основе микросервисов, у нас есть лучшие возможности для масштабирования в зависимости от нагрузки, но за высокое использование памяти по-прежнему приходится платить. Таким образом, модель потока на запрос может стать довольно дорогостоящей для приложений с большим количеством одновременных запросов.
Важной характеристикой архитектур на основе микросервисов является то, что приложение распределено, выполняется большое количество отдельных процессов, обычно на нескольких серверах. Использование традиционного императивного программирования с синхронными вызовами запроса/ответа для взаимодействия между службами означает, что потоки часто блокируются в ожидании ответа от другой службы, что приводит к огромной трате ресурсов.
1.2 Ожидание операций ввода/вывода
Такой же тип потерь также возникает при ожидании завершения других типов операций ввода-вывода, таких как вызов базы данных или чтение из файла. Во всех этих ситуациях поток, выполняющий запрос ввода-вывода, будет заблокирован и будет ожидать, пока операция ввода-вывода не будет завершена, это называется блокирующим вводом-выводом. Такие ситуации, когда выполняющийся поток блокируется, просто ожидая ответа, означают потерю потоков и, следовательно, потерю памяти.
1.3 Время ответа
Другой проблемой традиционного императивного программирования является время отклика, когда службе необходимо выполнить более одного запроса ввода-вывода. Например, службе A может потребоваться вызвать службы B и C, а также выполнить поиск в базе данных, а затем вернуть в результате некоторые агрегированные данные. Это будет означать, что время ответа службы A, помимо времени ее обработки, будет суммой следующих значений:
время отклика услуги B (задержка сети + обработка)
время отклика службы C (задержка сети + обработка)
время ответа на запрос к базе данных (сетевая задержка + обработка)
Если нет никакой реальной логической причины выполнять эти вызовы последовательно, то, безусловно, если эти вызовы будут выполняться параллельно, это очень положительно повлияет на время отклика службы А. Несмотря на то, что существует поддержка выполнения асинхронных вызовов в Java с использованием CompletableFutures и регистрации обратных вызовов, широкое использование такого подхода в приложении сделало бы код более сложным и трудным для чтения и поддержки.
1.4 Перегрузка клиента
1.5 Резюме
отходим от модели поток на запрос и можем обрабатывать больше запросов с небольшим количеством потоков
предотвращаем блокировку потоков при ожидании завершения операций ввода-вывода
упрощаем параллельные вызовы
поддерживаем «обратное давление», давая клиенту возможность сообщить серверу, с какой нагрузкой он может справиться
2. Что такое реактивное программирование
2.1 Определение
В документации Spring дано следующее краткое определение реактивного программирования:
2.2 Объяснение
Так как же всего этого достичь?
Вкратце: программированием с использованием асинхронных потоков данных. Допустим, служба A хочет получить некоторые данные из службы B. При подходе в стиле реактивного программирования служба A отправит запрос службе B, которая немедленно вернет управление (неблокирующий и асинхронный запрос). Затем запрошенные данные будут доступны службе A в виде потока данных, где служба B будет публиковать событие onNext для каждого элемента данных один за другим. Когда все данные будут опубликованы, об этом просигнализирует событие onComplete. В случае ошибки будет опубликовано событие onError, и больше никаких элементов не будет.
Реактивное программирование использует подход функционального стиля (аналогично Streams API), который дает возможность выполнять различные виды преобразований в потоках. Один поток можно использовать как вход для другого. Потоки можно объединять, отображать и фильтровать (операции merge, map и filter).
2.3 Реактивные системы
Создание реактивной системы означает решение таких вопросов, как разделение ответственности, согласованность данных, управление отказами, выбор реализации обмена сообщениями и т. д. Реактивное программирование может использоваться в качестве метода реализации систем, гарантирующего, что отдельные службы используют асинхронную неблокирующую модель. Но чтобы спроектировать систему реактивную в целом, также требуется архитектура, которая обеспечивает все эти аспекты.
3. История вопроса
3.1 REACTIVEX
ReactiveX использует сочетание шаблона Iterator и шаблона Observer из Gang of Four. Разница в том, что используется модель push по сравнению с обычным поведением итераторов на основе pull. Помимо наблюдения за изменениями, подписчику также сообщается о завершении и ошибках.
3.2 Спецификация реактивных потоков
Спецификация Reactive Streams включает следующие интерфейсы:
Publisher:
Он представляет производителя данных/источник данных и имеет один метод, который позволяет подписчику зарегистрироваться на издателе.
Subscriber:
Он представляет потребителя и имеет следующие методы:
onSubscribe должны вызываться Publisher перед началом обработки и использоватся для передачи на Subscription объекта от Publisher до Subscriber
onNext используется для того, чтобы сигнализировать о том, что был отправлен новый элемент
onError используется для того, чтобы сигнализировать о том, что произошел сбой Publisher и больше никаких элементов не будет
onComplete используется для того, чтобы сигнализировать, что все элементы были успешно отправлены
Subscription:
Subscription содержат методы, которые позволяют клиенту управлять выдачей элементов Publisher (т.е. обеспечивать поддержку противодавления).
request позволяет Subscriber сообщить, Publisher сколько дополнительных элементов будет опубликовано
cancel позволяет подписчику отменить дальнейшую отправку элементов Publisher
3.3 PROJECT REACTOR
Spring Framework поддерживает реактивное программирование, начиная с версии 5. Эта поддержка построена на основе Project Reactor.
Практика реактивного программирования в spring 5 pdf
1zQSrokan207eG6c82 — Читайте и скачивайте книгу Олега Докуки Практическое реактивное программирование в Spring 5: Build cloud-ready. Реактивные системы с Spring 5 и Project Reactor в PDF. EPub, Mobi. Kindle online. Бесплатная книга Практическое реактивное программирование в Spring 5: Создание облачных реактивных систем с Spring 5 и Project Reactor Олега Докуки. Практическое реактивное программирование в Spring 5: Создание облачных реактивных систем с Spring 5 и Project Reactor
Олега Докуки
Краткий обзор: Исследуйте реактивную систему и создавайте эффективные микросервисы с Spring Boot 2.1 и Spring CloudKey Features Поймите. Какая система требуется современному бизнесу с SpringGain более глубокое понимание реактивного программирования с реактором и Spring CloudGet глубокие знания об асинхронной и неблокирующей связи с Spring 5 WebFluxBook Описаниеоткройте разницу между реактивной системой и реактивным программированиемизайте преимущества реактивной системы и поймите ее приложения
понимание проекта Reactor Постройте реактивную систему с использованием Spring 5 и Project Reactor Создайте высокоэффективный реактивный микросервис с Spring CloudTest. Монитором и выпуском реактивных приложений.
Это достижимо при реактивном программировании. Однако разработка такого рода систем является сложной задачей. Требующей глубокого понимания предметной области. Для разработки высокочувствительных систем разработчики Spring Framework придумали проект Reactor.Практическое Реактивное программирование в Spring 5 начинается с основ Реактивного программирования Spring. Вы исследуете бесконечные возможности создания эффективных реактивных систем с помощью фреймворка Spring 5 наряду с другими инструментами. Такими как WebFlux и Spring Boot. Далее вы изучите методы реактивного программирования и примените их к базам данных и межсерверной связи. Вы будете развивать свои навыки в масштабировании потоков Spring Cloud и запускать независимые высокоэффективные реактивные микросервисы.Эта книга предназначена для разработчиков Java. Которые используют Spring для разработки своих приложений и хотят создавать надежные и реактивные приложения. Способные масштабироваться в облаке. Базовые знания о распределенных системах и асинхронном программировании помогут вам понять концепции. Описанные в этой книге.