Создание масштабируемого веб-приложения ASP.NET MVC

Question

Я сейчас нахожусь в процессе создания веб-приложения ASP.NET MVC на c #.

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

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

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

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

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

Обновление Думал, что я опубликую обновление по этому вопросу, как это было давно. Мы фактически использовали Windows Azure, но решение применимо к другим платформам.

В конечном итоге мы используем очередь Windows Azure для отправки сообщений \ команд. Это очень быстрый процесс и возвращается немедленно. Затем у нас есть рабочая роль, которая обрабатывает эти сообщения в другом потоке. Это позволяет нам минимизировать любые записи / обновления БД в веб-роли в теории, что позволяет нам легче масштабировать.

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

Answer 1

Не уверен, помогает ли это, но почему, например, у вас нет автоматического обновления на странице каждые 30 секунд. Это иногда, как новостные ленты работают на спортивных сайтах, говоря, что страница будет обновляться каждые x минут.

<meta http-equiv="refresh" content="120;url=index.aspx">

Answer 2

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

Ваш сценарий так отличается от этого?

Answer 3

Может быть, вы можете добавить область «ожидающих транзакций» в пользовательский интерфейс. Когда вы ставите транзакцию в очередь, добавьте ее в список «ожидающих транзакций» пользователя.

Когда он завершится, покажите, что в списке «ожидающие транзакции» пользователя в следующий раз они запросят новую страницу.

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

Answer 4

Хотя я не знаю, согласен ли я с логикой того, почему, но я знаю, что что-то вроде jQuery сделает вашу жизнь намного проще. Я бы предложил создать веб-API RESTful, который использует ваш клиентский код. Например, вы хотите опубликовать новый заказ в системе, чтобы клиент реагировал? Сделайте сообщение на www.mystore.com/order/create и попросите его вернуть новый URI для доступа к заказу (т. Е. Order #) в качестве URI (www.mystore.com/order/1234). Этот ответ затем сохраняется в клиентском коде, и jQuery call настроен для запроса ответа или прекращения опроса об ошибке.

Для дальнейшего прочтения ознакомьтесь с этой статьей в Википедии о концепции ОТДЫХ.

Кроме того, вы можете рассмотреть Reactive Extensions для .NET , и в рамках этого проверьте подпроект RxJS, в котором есть несколько довольно изящных способов решения проблемы опроса, не заставляя вас писать код опроса самостоятельно , Веселые вещи, чтобы играть с!

Answer 5

Извините, в моем предыдущем ответе я, возможно, неправильно понял. Я говорил о «очереди» как о чем-то, хранящемся в БД SQL, но, читая ваш пост снова, вы, возможно, говорите об отдельном компоненте очереди сообщений, таком как MSMQ или JMS?

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