Насколько устойчивым должно быть мое веб-приложение?

В последнее время я нашел несколько аргументов с моим начальником об обработке исключений в нашем веб-приложении (приложение С# asp.net MVC).

В основном разговоры идут примерно так:

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

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

Boss: "Наше приложение должно быть более устойчивым - часть приложения, которая не требует доступа к базе данных, все равно должна функционировать".

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

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

Ответ 1

Я оставил бы это боссу, чтобы решить. Расскажите ему, сколько часов потребуется, чтобы сделать приложение "упругим", и он решит, стоит ли инвестировать.

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

Ответ 6

Это, вероятно, более академический ответ, учитывая, что вы унаследовали этот код. Если вы используете, или, вернее, если кто-то использовал, шаблон Microsoft.Practices.EnterpriseLibrary.ExceptionHandling ExceptionPolicy, то действительно легко перейти от отображения страницы ошибки (путем исключения исключения) для использования исключений и отображения пустых сеток, списков и т.д.

Возможно, вы уже знаете об этом маленьком шаблоне, но здесь все равно:

        try
        {
            //get data
        }
        catch (Exception ex)
        {
            if (ExceptionPolicy.HandleException(ex, "Data Access Exception"))
                throw ex;
        }

Ответ 7

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

Так, например, если вы показываете список пользователей/сообщений/дату, но служба, в которой вы ее собираете, отключена, возможно, вы можете показать пустой набор.

Итак, вместо отображения:

500 Server Error




.

Вы можете показать что-то вроде:

 User   |    Message     | Date 
 ------------------------------
    No data available* 




* Xyz service is be down.

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

Это зависит от того, что вы используете, но в общих чертах это может быть просто:

 List<Data> data = EmptyList<Data>();

 try 
 {
     data = service.GetData();
 } catch( ServiceUnavailableException error ) 
 {
     errorPage.SetMessage( service.GetName() + " service is down ");
     // log the error message
    logger.doLog( error );
 }

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

Ответ 8

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

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

Чтобы приложение можно было использовать, оно должно быть доступно и надежно. Почти все приложения (кроме автономных настольных утилит) - это 2 или более многоуровневые приложения, что означает, что там будет выполняться сетевой вызов и все проблемы, связанные с n/w. Итак, как только вы начнете практиковать, вы начнете внедрять шаблоны отказоустойчивости во всех приложениях.