Реактивные шаблоны проектирования

этой главе (в частности, когда мы затронем устойчивость) будет полезно вспомнить разницу между ошибками и сбоями, определение которой дается в словаре терминов66 манифеста реактивного программирования: «Сбой — это неожиданное событие, которое произошло внутри сервиса и не дает ему нормально работать дальше. В большинстве случаев он делает невозможным получение ответа на текущий и, вероятно, на все последу­ющие клиентские запросы. Это контрастирует с ошибками, представляющими собой ожидаемые условия, предусмотренные в коде (например, ошибка, обнаруженная во время проверки ввода), и передаваемыми клиенту в рамках штатной обработки сообщения. Сбои происходят неожиданно и требуют вмешательства, чтобы система смогла вернуться к прежнему уровню выполнения. Это не означает, что все сбои являются фатальными, но они определенно влекут за собой снижение работоспособности системы. Ошибки представляют собой часть нормального процесса, они обрабатываются без промедления и не влияют на функциональность».
В качестве примеров сбоев можно привести аппаратные неполадки, завершение процесса из-за фатальной нехватки ресурсов и программные дефекты, вызывающие повреждение внутреннего состояния.

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

Закон Конвея гласит: «Любая организация, проектирующая систему, неизбежно придет к архитектуре, которая является копией структуры взаимодействия внутри этой организации»48. Это говорит о том, что в примере с Gmail у нас получилось бы три модуля, которые отвечают за клиентскую часть, бизнес-логику и базу данных. В рамках этих модулей каждая команда, вероятно, определила бы собственные подмодули для контактов, входа в систему, профиля и почты (рис. 6.3).

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

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

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

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

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

Впервые модель акторов была предложена Карлом Хьюиттом в 1973 году. Это концепция конкурентных вычислений, в которой все взаимодействие происходит между сущностями под названием «акторы» и реализуется путем передачи сообщений отправителем и помещения их в очередь получателем41. Язык программирования Erlang, который одним из первых стал поддерживать разработку реактивных приложений, использует акторы в качестве основной архитектурной конструкции. Благодаря успеху фреймворка Akka на платформе JVM акторы в последнее время стали популярными.

Future — это ссылка на значение или код ошибки, которая может стать доступной (только для чтения) в какой-то момент времени, Promise — это соответствующий дескриптор с возможностью одиночной записи, который обеспечивает доступ к значению.