Добро пожаловать в другую тему, которую я хотел бы обсудить. На этот раз речь идет не о том, что люди делают, а о том, чего они не делают, но я думаю, что они должны. Я хотел бы сделать краткую мотивацию о супервизии. Честно говоря, у меня такое ощущение, что супервизия — это одна из фундаментальных идей Акки, которая не используется должным образом.
Девизом этой темы, наверное, должно быть:
Но прежде чем мы перейдем к этому, давайте кратко вспомним, что такое надзор Akka.
Иерархия актеров
На картинке ниже мы видим двух актеров высшего уровня.
Мы создаем их, вызывая актор system.actorOf. Они называются высокоуровневыми, поскольку создаются системой субъектов, а не другим субъектом. Один из ключевых моментов супервизии актера заключается в том, что у самого актера, или почти у каждого актера, как вы сейчас увидите, есть супервизор. Так кто их контролирует?
Как вы, наверное, знаете, эти субъекты неявно контролируются (пользователем) субъектом-хранителем (иногда упоминаемым просто как Корневой субъект).
Второй ключевой момент супервизии состоит в том, что каждый актор также может БЫТЬ супервизором, и каждый актер наблюдает за своими детьми.
Итак, когда мы начнем создавать акторов не с помощью системы акторов, а с помощью контекстов акторов, мы можем получить что-то вроде этого.
Как вы можете видеть на картинке, C1 и C2 контролируются B1, а B1 контролируется A2 и так далее. Итак, это была иерархия, а теперь давайте поговорим о том, для чего она хороша. Дело в том, что каждый раз, когда актор генерирует необработанное исключение, его руководитель может решить, что с этим делать. Он может сказать актеру игнорировать это, он также может остановить актера, перезапустить его или передать это своему начальнику, и он также может применить это не только к проблемному актеру, но и ко всем его братьям и сестрам. И это почти все.
Итак, это были пользовательские субъекты, но у нас также есть системные субъекты.
Их работа в основном заключается в том, чтобы заботиться о функциях системы акторов, таких как, например, ведение журнала акторов, а также они несут ответственность за отключение системы акторов и все эти функции инфраструктуры. Сейчас это не так важно для нас, но приятно знать, что есть что-то подобное. А также, если вам интересно, что означает косая черта («/») сверху. Этого актера зовут TheRoot Guardian, и это единственный актер, который не контролируется.
Две разные битвы, чтобы выиграть
Итак, это был краткий обзор того, что такое надзор, но зачем он нам нужен. По сути, есть две битвы, которые мы хотим выиграть. Во-первых, мы хотим разделить нашу бизнес-логику и нашу обработку ошибок для менее сложного кода. А во-вторых, мы хотим, чтобы наше приложение могло вернуться к жизни после того, как случилось что-то плохое. Надзор дает нам изоляцию сбоев и восстановление системы, и поэтому нас больше не вызывают в полночь. С надеждой.
Очевидно, я не хочу подталкивать вас к использованию супервизии везде, где это возможно. Вероятно, это не очень хорошая идея. Вы, ребята, всегда должны решать, что имеет больше смысла в вашем конкретном случае использования. Я думаю, что хорошее руководство, как принять решение, состоит в том, чтобы разделить ваши исключения на ошибки и сбои. Ошибки — это распространенные события, такие как неправильные запросы, проблемы во время проверки и т. д., и о них сообщается клиенту или вызывающей стороне. С другой стороны, сбой — это неожиданное событие в службе, которое не позволяет ей продолжать нормально работать. Сбой обычно не дает ответов на текущий и, возможно, на все последующие запросы. О сбоях следует сообщать супервайзеру, клиент все равно ничего не может с этим поделать. Например, у нас могут быть сбои базы данных, сетевые разделы или аппаратные сбои и так далее. И, кстати, это не то, что я вчера придумал, это взято из реактивного манифеста [1]. Так что основная идея довольно старая.
Подведем итог:
Шаблон ядра ошибки
По поводу надзора у нас может возникнуть проблема — что делать с состоянием актора при рестартах. Для этого есть эта выкройка. По сути, это всего лишь простое руководство, которому вы должны следовать, утверждая, что если актор несет важное внутреннее состояние, то он должен делегировать опасные задачи своим дочерним элементам, чтобы предотвратить сбой субъекта, несущего состояние. Иногда может иметь смысл создавать нового дочернего актора для каждой такой задачи, но это не обязательно.
Резюме
Akka обеспечивает контроль, который позволяет нам создавать богатые иерархии для разделения бизнес-логики и обработки сбоев, и при правильном использовании наши приложения могут быть самовосстанавливающимися и устойчивыми. Так что постарайтесь воспользоваться этим.
На сегодня это все, если у вас есть какие-либо вопросы/комментарии, не стесняйтесь сообщить нам об этом в разделе ниже!
— Петр
