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

Question

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

Ферма моего веб-приложения находится в Калифорнии.

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

У меня есть страница /show-web-service-result.aspx, которая работает следующим образом:

1) Страница запросов пользователя /show-web-service-result.aspx?s=foo

2) Кодовая страница Пейджа запрашивает веб-службу, размещенную третьей стороной в Нью-Йорке.

3) Когда веб-сервис возвращается, возвращенные данные форматируются и отображаются пользователю в ответе на страницу.

Есть ли у этой архитектуры потенциальные проблемы с масштабируемостью? Предположим, я получаю сотни уникальных хитов в секунду, например,

/ шоу-веб-сервис-result.aspx? S = foo1

/ шоу-веб-сервис-result.aspx? S = foo2

/ шоу-веб-сервис-result.aspx? S = foo3

и т.д ...

Типично ли для веб-серверов в ферме использование веб-служб для данных вместо базы данных? Есть личный опыт?

Какие изменения я должен внести в архитектуру для улучшения масштабируемости?

Answer 1

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Журнал MSDN - Злой код - Асинхронные страницы в ASP.NET 2.0

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

• Код Microsoft Project с именем «Скорость»
• NCache

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

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

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

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

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

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

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

---

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

Answer 7

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

Answer 8

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

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