Erlang let-it-crash философия - применимо в другом месте?

Ответ 1

Он применим везде. Независимо от того, пишете ли вы свое программное обеспечение в шаблоне "пусть он падает", он все равно сбой, например, при сбое аппаратного обеспечения. "Пусть это крушение" применяется везде, где вам нужно противостоять реальности. Quoth Джеймс Гамильтон:

Если аппаратный сбой требует каких-либо немедленных административных действий, служба просто не будет экономить и надежно масштабировать. Вся служба должна быть способна выжить без административного взаимодействия человека. Восстановление отказа должно быть очень простым путем, и этот путь должен проверяться часто. Армандо Фокс из Стэнфорда утверждал, что лучший способ проверить путь отказа - никогда не закрывать службу нормально. Просто трудно это сделать. Это звучит контр-интуитивно, но если часто используются пути отказа, они не будут работать, когда это необходимо.

Это не означает, что "никогда не использовать охранников". Но не бойтесь рушиться!

Ответ 2

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

Основной дизайн - это сложить систему и изолировать центральные части системы, чтобы контролировать и контролировать другие части, которые выполняют работу. В терминологии OTP есть надзорные и рабочие процессы. Надзорные органы выполняют работу по наблюдению за рабочими и другими надзорными органами с целью их правильного повторного запуска, когда они разбиваются, когда работники выполняют всю фактическую работу. Правильное структурирование системы в слоях с использованием этого принципа строгого разделения функциональности позволяет изолировать большую часть обработки ошибок от рабочих в супервизорах. Вы пытаетесь создать ядро ​​с ошибкой small, которое, если оно правильно, может обрабатывать ошибки в любом месте остальной части системы. Именно в этом контексте предполагается использовать философию "let-it-crash".

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

Мои коллеги и я подумали о том, что тема не особенно технологична, но больше с точки зрения домена и с точки зрения безопасности.

Вопрос: "Безопасно ли это терпеть крах?" или лучше ". Можно ли даже применить такую ​​парадигму надежности, как Erlangs," позволить ей врезаться "в проекты программного обеспечения, связанные с безопасностью?".

Чтобы найти ответ, мы сделали небольшой исследовательский проект, используя близкую к реальности сценарий с промышленным и особенно медицинским образованием. Посмотрите здесь (http://bit.ly/Z-Blog_let-it-crash). Есть даже бумага для загрузки. Скажите мне, что вы думаете!

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

Ответ 6

IMHO Некоторые разработчики обрабатывают/переносят проверенные исключения с кодом, который мало ценит. Часто проще разрешить метод генерировать исходное исключение, если вы не собираетесь его обрабатывать и добавить какое-то значение.