сколько веб-сервисов

Question

У меня есть веб-сервис, который выглядит следующим образом:

public class TheService : System.Web.Services.WebService
{
  [WebMethod(EnableSession = true)]
  public string GetData(string Param1, string Param2) { ... }
}

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

Проблема, с которой я сталкиваюсь, связана с масштабируемостью.Я создаю веб-приложение, которое должно работать на 1000 ежедневных пользователей, и каждый пользователь будет совершать около 300-500 звонков в день в веб-службу, то есть примерно 300–500 000 запросов в день.Мне нужно добавить еще 9 звонков в веб-сервис.Некоторые из этих вызовов будут связаны с записью в базу данных.

Мой вопрос таков: мне лучше создать 9 отдельных веб-служб или продолжить работу с одной службой, которую я имею, и добавить другие методы.Или может быть что-то другое и лучшее.Я планирую развернуть приложение в Azure, поэтому меня не волнует аппаратное обеспечение, а только прикладная сторона.

Answer 1

Я не уверен в точности вашего случая, но перенос дорогостоящих (с точки зрения ЦП / БД) задач на отдельную рабочую роль обычно является хорошим решением для Azure. В этом случае у вас будет одна WebRole со службами, которые будут принимать запросы (это будет небольшой вес, поэтому у вас не должно быть много экземпляров для этого), и вы создадите задачи для рабочих ролей и одну или несколько рабочих ролей, которые будут обрабатывать эти задачи - # 1 Рабочие роли могут быть созданы для каждого вида задач (для группирования схожих действий, таких как чтение / запись данных в БД) или # 2 одна Рабочая роль может обрабатывать задачи любого типа. Я не вижу никаких преимуществ в # 2, потому что, чтобы получить то же самое поведение, вы можете просто создать одну WebRole со многими экземплярами и обрабатывать все там. Таким образом, у вас будет возможность контролировать время обработки путем добавления / удаления рабочих ролей.

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

Я не знаю, связано ли это с этим квестом, но просто для того, чтобы вы знали - Azure сбрасывает соединения, которые не активны в течение 60 секунд (я не нашел способа увеличить этот тайм-аут, вы можете решить эту проблему в Google ). Это может быть проблемой, если вы портируете веб-сервисы на Azure, и ваши ответы могут достигать 60 секунд. Один из способов избежать этого - поддерживать соединение активным, что довольно просто, если клиенты знают об этой «функции».

Answer 2

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

Итак, с точки зрения гранулярности:

• Наименее гранулировано: объедините все методы в одну веб-службу, размещенную наодиночная роль.При масштабировании до нескольких экземпляров все запросы к методам службы распределяются по нагрузке во всех экземплярах.Поскольку вы объединяете все в одну роль, вы обнаружите, что это оптимизировано с точки зрения затрат: вы можете запустить весь код веб-служб в одном экземпляре (в действительности 2 экземпляра, чтобы получить SLA).
• Более детально:Создайте отдельные веб-сервисы, каждый со своими собственными методами, и размещайте их на одной роли (позволяет использовать принципы SOLID, как описано Мерлином).Те же базовые характеристики производительности, что и в первом варианте, поскольку все запросы по-прежнему сбалансированы по нагрузке для одного и того же набора экземпляров.
• Наиболее детализированный: создайте отдельные веб-службы, каждый со своими методами, и разместите каждую конечную точку веб-службы.на отдельной роли, что позволяет независимый размер виртуальной машины и масштабирование каждой конечной точки веб-службы.Эта опция имеет более высокую стоимость выполнения, поскольку теперь у вас есть минимум один экземпляр на конечную точку веб-службы (опять же, 2 экземпляра в реальном мире, работающее приложение).

Answer 3

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

Используя Azure, вы можете масштабировать свои роли независимо друг от друга.Это означает, что если различные веб-методы должны масштабироваться по разным схемам (т. Е. Ваш первый веб-метод имеет самый большой объем по утрам и после обеда, а два других веб-метода имеют самый большой объем вечером и ночью), ипоследние 2 веб-метода обычно не работают в течение дня, может быть, стоит разделить ваши методы по ролям по ограничениям масштабируемости, а не по логическим ограничениям.

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

HTH

Answer 4

Количество веб-сервисов не повлияет на масштабируемость приложения.

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

Но просто не начинайте добавлять роли.Поймите, где ваши узкие места.Измерение, профилирование и настройка.

В Azure есть локально devfabric и IIS, которые также помогут вам профилировать локально.

Answer 5

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

Дизайн

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

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

Одним из перечисленных принципов, который особенно важен, является Принцип разделения интерфейса , который можно определить как the notion that "many client specific interfaces are better than one general purpose interface."

Производительность и масштабируемость

Поскольку вы упомянули о производительности и масштабируемости, я рекомендую вам придерживаться следующего плана:

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

Answer 6

Разделение веб-методов на несколько веб-сервисов здесь вам не поможет; балансировка нагрузки будет.