Философия Эрланга "пусть все рухнет" - применима в других местах?

Question

Эрланг (или Джо Армстронг?) советы НЕ использовать защитное программирование и позволить процессам аварийно завершаться (вместо того, чтобы загрязнять ваш код ненужными охранниками, пытающимися отслеживать обломки) теперь имеет для меня такой смысл, что я удивляюсь, почему я потратил столько усилий на обработку ошибок за эти годы!

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

Как вы думаете, это изменение подхода будет хорошо работать (скажем) в пространстве .NET или Java?

Answer 1

Это применимо повсюду. Анкет Независимо от того, пишете ли вы свое программное обеспечение в шаблоне «Let It Crash», он в любом случае будет сбоем, например, когда аппаратное обеспечение не удается. «Пусть сбой» применяется везде, где вам нужно противостоять реальности. Quoth James Hamilton:

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

Хотя это не означает «никогда не пользоваться охранниками». Но не бойтесь разбиться!

Answer 2

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

С учетом вышесказанного я думаю, что Эрланг должен быть особым случаем, что вы не только можете немедленно перезапустить вещи, что перезапущенная программа может появиться, осмотреть и сказать: «Аааа ... это было то, что я делал!»

Answer 5

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

Вопрос в том, "Безопасно ли допускать сбой?" или лучше "Возможно ли вообще применить парадигму надежности, подобную Erlang's “let it crash”, к программным проектам, связанным с безопасностью?".

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

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

Answer 6

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