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

Для кого эта книга

Книга создавалась для всех, кто заинтересован в реализации реактивных систем.

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

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

Необходимость в реактивных шаблонах проектирования

Многие из приведенных решений и большинство исходных проблем не новы. Разделение архитектуры разных компонентов программы является одной из задач информатики с момента ее возникновения и обсуждается в технической литературе со времен публикации знаменитой книги «Шаблоны проектирования»1. По мере проникновения компьютеров в повседневную жизнь программирование стало получать заслуженное внимание со стороны общества и превратилось из искусства, практикуемого учеными, а позже молодыми фанатиками в гаражах, в массовое прикладное ремесло. Рост общего числа компьютерных систем, установленных за последние два десятилетия, привел к формализации проектирования, а заодно определил набор рекомендуемых методик и расширил количество освоенных областей. В 2003 году вышла книга «Шаблоны интеграции корпоративных приложений»2, рассматривающая обмен сообщениями между компонентами и определяющая шаблоны взаимодействия и обработки сообщений, которые, например, реализованы в проекте Apache Camel. Следующий шаг назывался сервис-ориентированной архитектурой (service-oriented architecture, SOA).

По мере чтения данной главы вам будут встречаться элементы предыдущих стадий, такие как сервисы и ориентированность на передаче сообщений. В связи с этим возникает естественный вопрос: что может предложить эта книга такого, что не было подробно рассмотрено ранее в других изданиях? Особенно интересным выглядит сравнение с определением SOA, которое дается в книге Арнона Ротем-Гал-Оза «Шаблоны SOA» (SOA Patterns. — Manning, 2012): «Сервис-ориентированная архитектура (SOA) — это стиль проектирования для построения систем на основе взаимодействия слабосвязанных, обобщенных и автономных компонентов под названием “сервисы”. Каждый сервис использует для предоставления процессов и поведения контракты, состоящие из сообщений, которые можно обнаружить по заданным адресам (конечным точкам). Поведение сервиса определяется правилами, которые определяются за его пределами. Контракты и сообщения используются внешними компонентами, которые называются потребителями сервисов».

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

Управление сложностью

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

• неотъемлемая, присущая предметной области;
• побочная, создаваемая исключительно самим решением.

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

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

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

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

Делаем модели программирования ближе к реальному миру

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

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

Конечно, не следует злоупотреблять антропоморфизмом: такая терминология, как master/slave (дословно «хозяин/раб»), постепенно исчезает из обихода, поскольку при ее интерпретации не всегда учитывается технический контекст. Но даже ответственное использование подобных метафор может придать пикантности потенциально скучной работе: например, компонент, отвечающий за сохранение журнальных записей на диск, можно назвать Scribe (рус. писарь). Реализация этого класса даст вам ощущение того, что вы создаете маленького робота, который будет выполнять ваши команды и с которым можно немного поиграть, — кто-то называет такое занятие написанием тестов, произнося это словосочетание с кислой миной. Реактивное программирование позволяет взглянуть на это с другой стороны и осознать: это весело!

» Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 20% по купону — Reactive Design Patterns