Очень простая корпоративная архитектура приложений - ее масштабирование

Question

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

Клиент:

• 1 агент, работающий на каждом компьютере, отправляющий данные конфигурации системы (один раз), reports (каждые 2–5 мин.) => размер данных, передаваемых с клиента на сервер, составляет несколько сотен байтов и редко затрагивает КБ.

Сервер:

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

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

До сих пор я запускал свое приложение в сети из 2000 компьютеров, и, похоже, оно работает хорошо.Теперь мне нужно масштабировать это для поддержки сети из 25 000 клиентов.Я собираюсь запустить симуляционные тесты с 25 000 запросов в секунду и проверить, хорошо ли работает архитектура.

Сервер основан на .NET.Веб-приложение ASP .NET - front-end, веб-сервис для выгрузки данных.Системный сервис на основе .NET для выполнения ETL.SQL Server 2005/2008 в качестве сервера базы данных.

Надеемся получить конструктивную критику и рекомендации от сообщества stackoverflow для улучшения этой архитектуры.Считаете ли вы, что это достаточно хорошо, чтобы работать с 25 000 клиентов, использующих один сервер?Как вы думаете, что компонент, скорее всего, сломается с увеличением одновременной активности?Это в корне ошибочно?Все виды руководства приветствуются.Спасибо.

Answer 1

Равномерно распределяйте в «наихудшем случае» скорость 12500 транс / мин, что составляет 209 транс / с.

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

Если у вас было 4 машины, вы снижаете до 52 транс в секунду на каждой машине.Каждая машина хранит свои транс-данные локально, а затем, в пакетном режиме, делает массовые вставки в конечную базу данных.Это поддерживает низкий уровень громкости в основной базе данных.Разница между вставкой 1 строки и 50 строк (в зависимости от размера строки) довольно незначительна.В какой-то момент это «то же самое» в зависимости от нагрузки на сеть и т. Д.

Итак, если мы округлим до 50 (для упрощения математики), каждые 5 секунд внешние машины вставляют 250 строк в базу данных конца,Это не низкий уровень громкости (опять же, в зависимости от размера строки).

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

В частности, вполне возможно, что обработка бэкэнда будет медленнее, чем скорость вставки внешнего интерфейса вв краткосрочной перспективе, пока в конечном итоге ваш бэкэнд догоняет.Например, возможно, большая часть вашего трафика идет с 8 утра до 5 вечера, но все сказанное и выполненная обработка вашего бэкэнда будет завершена к 9 вечера. * 10101 *

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

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

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

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

Answer 2

25 тыс. Запросов в секунду, которые нужно масштабировать (даже при 25 тыс. В минуту 25 тыс. В секунду - это действительно огромная нагрузка, и вам потребуется много серверов для ее обработки).У вас должен быть парк сервисных серверов WWW, каждый из которых сбрасывает запрос в локальное хранилище (очередь).Невозможно, чтобы ферма WWW говорила прямо в бэкэнде, она умрет из-за конфликта (исключение блокировки из-за запросов клиента, пытающихся вставить / обновить в том же месте в базе данных).Служба WWW просто выгружает запросы локально, а затем возвращает ответ HTTP и продолжает работу.От WWW-серверов среднего уровня эти запросы должны быть агрегированы и загружены в центральные серверы.Эта загрузка должна быть надежной, легко настраиваемой и достаточно быстрой.Не попадайтесь в ловушку «Я просто напишу утилиту копирования с логикой повторения», эта дорога вымощена телами.Хорошим кандидатом для этого локального хранилища является экземпляр SQL Server Express, а хорошим кандидатом для агрегирования и загрузки является Service Broker.Я знаю, что эта архитектура работает, потому что я делал проекты, которые ее используют, см. Аудит в реальном времени при больших объемах и ETL .И я знаю о проектах, использующих эту архитектуру для ее масштабирования ( действительно , см. Мартовское безумие по требованию или Аналитика в реальном времени с SQL Server 2008 R2 StreamInsight окак собирается интеллектуальная информация о потоковой передаче мультимедиа Silverlight (акцент на обеих ссылках сделан на разных технологиях, но так как я знаю, что этот проект достаточно хорошо знаю, я знаю, как они собирают данные из веб-сервисов WWW в их серверную часть).

Answer 3

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

1-й выкл. Надеюсь, вы используете UDP, а не TCP ??

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

Много памяти на вашем сервере.

При условии, что все это сделано, и если оно все еще не работает, то

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

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

Answer 4

В худшем случае это означает, что вашей системе необходимо набрать 5000-13000 запросов в минуту.Вам необходимо вычислить приблизительную пропускную способность вашей системы с использованием системы на 60-70% (например, для 2000 клиентов) - если веб-служба занимает примерно 50 миллисекунд на запрос, это означает, что она может поддерживать до 1200 запросов в минуту.Аналогичный расчет можно сделать для сервиса .NET.По мере увеличения нагрузки пропускная способность может уменьшиться, поэтому фактическое число будет меньше.Основываясь на таких расчетах, вы должны решить, нужно ли масштабировать вашу систему.Вы можете запускать свои сервисы на нескольких серверах, и нагрузка будет разделена.Если db-сервер становится узким местом, его можно использовать кластерным способом.Единственное, что вам нужно проверить, - это то, что ваша реализация службы .NET допускает параллелизм (IMO, веб-служба будет меньше состояния и должна масштабироваться без проблемы) - например, нужно ли вставлять записи в порядке, который вы получилии т.д.

Answer 5

По моим расчетам, в худшем случае у вас есть 25000 вставок каждые 120 секунд. Каждые 10 секунд вы читаете 100 строк, что означает, что за 120 секунд вы прочитали 1200 строк. Это означает, что ваша временная таблица будет продолжать накапливать данные.

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

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

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

Таким образом, вы можете добавить дополнительные процессы для вставок и ETL.

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