Влияние на производительность наличия уровня доступа к данным / уровня обслуживания?

Question

Мне нужно спроектировать систему, которая имеет следующие основные компоненты:

• Веб-сервер, который будет получать ~ 100 запросов / сек.Веб-серверу требуется только выгрузить данные в репозиторий необработанных данных.
• Репозиторий необработанных данных, содержащий одну таблицу, которая получает от сервера 100 строк / с.
• Блок обработки необработанных данных (Простая обработка, не много. Удаление недопустимых необработанных данных, вставка отсутствующих компонентов в поврежденные необработанные данные и т. д.на чем будут построены все компоненты?Все межкомпонентное взаимодействие будет проходить через сервисные уровни.Хотя это сделает систему легко обновляемой и обслуживаемой, не окажет ли она также существенного влияния на производительность, поскольку у меня так много трафика для обработки?

Answer 1

Вот что может случиться, если вы не защититесь от этого.

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

Затем вы бездельничаете с профилировщиками, которые заставляют вас догадываться, в чем проблема.

Когда я работал над такой проблемой, я использовал метод stackshot и быстро нашел проблему. Вы бы подумали, что это ввод / вывод. НЕ. Дело в том, что преобразование данных в XML и синтаксический анализ XML для восстановления структуры данных занимали примерно 80% времени. Не было слишком сложно найти лучший способ сделать , что . Результат - ускорение в 5 раз.

Answer 2

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

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

1. Подтвердите набор технических навыков команды разработчиков и группы операций / поддержки.
2. Согласуйте первоначальный конечный список систем, которые будут интегрироваться в ваш сервис, поддерживаемые ими протоколы и некоторыеSLA.
3. Определите стратегию обмена сообщениями.
4. Поймите, как вы будете развертывать свою службу / систему.
5. Определитесь с выбором промежуточного программного обеспечения (ESB, Message Brokers и т. Д.), базы данных (SQL, Oracle, Memcache, DB2 и т. д.) и сторонние интегрированные среды / инструменты.
6. Выбор стратегии кэширования и задержки данных.
7. Разбейте свое приложение на различные сферы бизнесаответственность - это позволит вам разделить работу и упростить коммуникацию основных этапов во время разработки.Разработка / тестирование и внедрение.
8. Разработка каждого компонента в соответствии с требованиями зон ответственности.Области ответственности должны автоматически привести вас к решению о том, как проектировать компонент, сборку или обслуживание.

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

Удачи.

Answer 3

Что вы видите в качестве затрат на создание отдельного уровня обслуживания?

Как эти затраты сравниваются с расходами, которые должны понести?В вашем случае это, по крайней мере,

1. чтение сети по запросу
2. запись в базу данных для необработанных данных
3. чтение базы данных из необработанных данных
4. запись в базу данных обработанных данных

Плюс некоторые операции с данными.

Какие услуги у вас есть на уме?Возможно

• saveRawData ()
• getNextRawData ()
• writeProcessedData ()

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

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

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

Answer 4

Абстракция и многоуровневая рассылка приведут к задержке, но реальный вопрос заключается в том, что ВЫ ПОЛУЧАЕТЕ, чтобы оправдать затраты? Слабая связь, управление, масштабируемость, ремонтопригодность стоят реальных $.

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