Использование удаленной внешней веб-службы вместо базы данных

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

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

Кроме того, вам необходимо убедиться, что ваша платформа может использовать параллельные соединения для доступа к удаленной службе. Предположим, у вас есть время в оба конца из Калифорнии в Нью-Йорк 20 мс (что было бы неплохо), вы не можете сделать более 50 запросов через одно TCP-соединение. Точно так же запуск новых TCP-соединений для каждого запроса также снижает производительность, поэтому вы хотите объединить эти параллельные соединения.

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

Будет ли блокироваться отображение вашей страницы в ожидании ответа веб-службы? Что делать, если ответ не приходит, т.е. служба не работает?

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

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

У вас могут быть проблемы с масштабируемостью, но большинство из них можно тщательно спроектировать.

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

MSDN Magazine - Wicked Code - Asynchronous Pages in ASP.NET 2.0

Локальное кеширование абсолютно необходимо. Чем меньше раз вам придется ехать из Калифорнии в Нью-Йорк, тем лучше. Возможно, вы захотите изучить Microsoft Velocity (хотя он все еще находится в CTP) или NCache или другой распределенный кеш, чтобы каждому из ваших 4 веб-серверов не приходилось создавать и кэшировать одни и те же данные из веб-службы - один раз сервер получает его, он должен быть доступен всем.

• Microsoft Project под кодовым названием "Скорость"
• NCache

Другие вещи, которые могут пойти не так, что вам следует разработать:

• Веб-служба не работает (очевидно), данные выпадают из кеша, и вы не можете их вернуть. Постарайтесь сделать так, чтобы данные фактически не удалялись из кеша, пока вы не убедитесь, что у вас есть доступное обновление. Тогда единственный риск заключается в том, что служба не работает и пул приложений сброшен, поэтому не сбрасывайте его как средство устранения неполадок первой линии!
• Есть два разных тайм-аута для веб-запросов: соединение и общий тайм-аут. Убедитесь, что оба параметра установлены на очень низкое значение, и что вы обрабатываете оба тайм-аута. Если DNS службы выходит из строя, это может выглядеть как совсем другой сбой.
• Наблюдайте за perfmon для запросов в очереди ASP.NET. Это число будет быстро расти, если услуга выйдет из строя, и вы не сможете ее покрыть должным образом.
• Изучите и настройте параметры реестра производительности ASP.NET, чтобы получить высокооптимизированный пул потоков ASP.NET. Я не помню подробностей, но, кажется, помню, что есть ограничение на порты завершения ввода-вывода и что-то еще в этом роде, абсурдно низкое для мощного оборудования, которое, как я полагаю, у вас есть под рукой.

модный ответ - ОТДЫХ. Любой запрос GET может быть кэширован HTTP-ответом (с множеством параметров настройки), и он будет кэшироваться самим Интернетом (по сути, вашим интернет-провайдером).

Архитектура вашего проекта отражает направление, в котором Microsoft и многие другие в мире SOA хотят следовать. Тем не менее, многие люди пытаются избежать этого типа риска в реальном времени, создаваемого веб-службой.

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

По крайней мере, я бы получил веб-инструмент для стресса и протестировал производительность вашего веб-сервиса, по крайней мере, на уровне трафика, который вы ожидаете получить на пиках, и, вероятно, сверх этого. Когда он ломается (если вообще?), Когда начинает тормозить? Это хорошие показатели, которые нужно знать.

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

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

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

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

Я рекомендую вам обязательно использовать WCF, а не устаревшую технологию веб-сервисов ASMX в качестве клиента. Используйте «Добавить ссылку на службу» вместо «Добавить веб-ссылку».

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

В частности, я имею в виду аутентификацию и авторизацию как ваших конечных пользователей, так и самого веб-приложения. Где эти вещи обрабатываются? Все в веб-приложении? со стороны WS? Или, может быть, интерфейсное приложение аутентифицирует пользователей и передает идентификационные данные пользователя на серверный WS, что позволяет проверить, что пользователю разрешено? Как вы это проверяете? Поскольку многие другие респонденты здесь упоминают локальный кеш данных во внешнем приложении (ОТЛИЧНАЯ идея, BTW), это становится еще более сложным: вы кешируете данные, которые разрешены для пользователя A, но не для пользователя B? если да, то как проверить, что userB не может получить доступ к данным из кеша? Что, если авторизация проверяется WS, как тогда кэшировать разрешения?

С другой стороны, как вы проверяете, что только вашему веб-приложению разрешен доступ к WS (например, злоумышленник не имеет прямого доступа к вашим данным WS через Интернет)? В этом отношении, как вы гарантируете, что ваше веб-приложение обращается к ПРАВИЛЬНОМУ серверу WS, а не к фиктивному? И, конечно, я предполагаю, что все подключение к WS осуществляется только через TLS / SSL ... (но, конечно, также программно проверяйте, что сертификат применяется к серверу, к которому осуществляется доступ ...)

Короче говоря, это сложно, и здесь нужно учитывать множество элементов .... но это НЕ непреодолимо.

(что касается проверки ввода, это на самом деле НЕ проблема, поскольку это должно выполняться ОБА приложением внешнего интерфейса И серверной частью WS ...)

Другой аспект здесь, как упоминал @Martin, - это необходимость в SLA для любого провайдера / хостинга, который у вас есть для NY WS, не только для производительности, но и для обеспечения доступности. Т.е. что произойдет, если сервер недоступен, как быстро они берут на себя обязательство восстановить его, что произойдет, если он не будет работать в течение длительного периода времени и т. д. Это единственный способ законно перенести риск того, что ваша доступность будет контролируется внешними факторами.