Дизайн веб-приложений

Question

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

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

Базовый дизайн выглядит следующим образом.

Существует «ядро», которое написано в ASP.NET MVCи управляет всеми взаимодействиями JSON API и HTML в Интернете.Однако он не создает и не управляет «бизнес-объектами», такими как «Посты», «Участники» и т. Д. Все они обрабатываются в своих отдельных веб-службах WCF.

Идея заключается в том, чтобы по-настоящему просто использовать отдельные элементы управления, которыеиспользовать объекты управления для извлечения бизнес-данных / объектов из веб-сервисов.Это, в свою очередь, означает, что ядро ​​может быть многопоточным и одновременно вызывать элементы управления на странице.

Каждый веб-сервис будет управлять соответствующим бизнес-объектом и своими данными в БД.Любая специфическая для бизнеса обработка также будет здесь, например, сопоставление данных в таблицах с полезными структурами данных для использования в элементах управления.Весь объект будет передан ядру, и ядро ​​должно либо извлекать, либо устанавливать бизнес-объект только один раз за транзакцию.Если в будущем понадобятся операции с несколькими факторами, мне потребуется сделать эти функции доступными.

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

После разговора с моим другом у меня возникают следующие вопросы.

1. Я ценю этот WCFне так быстро, как вызовы DLL или что-то подобное.Но сколько будет накладных расходов на то, что вся система основана на них?

2. Создание потока может быть дорогостоящим.Это будет стоить дороже, чем просто вызывать все элементы управления один за другим?

3. Существуют ли какие-либо другие врожденные ямы, которые вы можете увидеть с этим дизайном?

Answer 1

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

Если бы это был я, я бы упростил конструкцию: переходил на однопоточный, использовал встроенный сервисный интерфейс. Затем, если бы проблема была с производительностью, я бы посмотрел, где я мог бы решить существующие проблемы с производительностью с помощью кэширования, многопроцессорной обработки и т. Д. Это позволяет фактическому приложению управлять проектом, хотя вы все равно будете применять хорошие шаблоны и практики, когда производительность выпуск всплывает. Если производительность не станет проблемой, значит, вы не создали много сложной инфраструктуры - YAGNI! Тебе это не понадобится!

Answer 2

1. Дизайн, ориентированный на веб-службы, целесообразен, если у вас есть один или несколько не собственных клиентов (которые не могут напрямую обращаться к вашей логике). Например, AJAX, Flash, другое веб-приложение из другого домена и т. Д. Но использование WCF для вашего приложения, когда вы можете напрямую обращаться к логике, - очень плохая идея.

Если позже вам понадобятся веб-службы, вы можете легко обернуть модель своего домена с помощью Сервисный уровень .

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

3. Основным провалом является то, что вы пытаетесь использовать много вещей. Избыточный дизайн, вероятно, хороший термин.

Answer 3

1. Это зависит от степени детализации ваших вызовов. Один из принципов SOA - сделать ваши интерфейсы менее общительными, т. Е. Один вызов выполняет целый ряд действий. Если вы разработали интерфейс службы так, как если бы это был бизнес-объект регулятора, то, скорее всего, он будет слишком болтливым.

2. Это зависит от вашей модели использования. Также в отношении нитей гранулярность является ключевым фактором.

3. Очень похоже на то, что вы перегружаете систему. Изменение интерфейса службы гораздо сложнее, чем изменение сигнатуры простого метода. Если все ваши бизнес-объекты представлены как сервисы, вас ждет кошмар отладки.

Answer 4

Это не похоже на что-то, что будет очень масштабируемым; по крайней мере, не много пользователей в секунду. Перекрытие в WCF повсеместно замедлит процесс, создав гораздо больше потоков, чем вам нужно. Если вызовы WCF не делают много работы, тогда издержки потока сильно повредят вам. Хотя он будет многопоточным, несколько вызовов страниц ASPX уже многопоточны. Вы можете ускорить работу своей системы, когда работает только один человек, но сильно ударить по производительности, если работает много пользователей Например, если один пользователь запрашивает страницу, то от многопоточности могут выиграть десять отдельных вызовов WCF. Однако, если у вас 100 запросов страниц в секунду, это 1000 вызовов WCF в секунду. Это много накладных расходов.

Answer 5

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