Вопросы архитектуры

Question

В настоящее время я разрабатываю веб-приложение, и я рассматриваю возможность использования python-django для интерфейса и C# -WCF-Entity Framework на задней панели. Моя основная компетенция - C#, следовательно, выбор технологий back end. Я, однако, не хочу использовать C# в интерфейсе, потому что предпочитаю чистый дизайн django vs ASP.NET и гибкость, предлагаемую динамическим языком. Я намерен сделать REST-вызовы для службы WCF для ВСЕХ доступа к данным (т. Е. Я вообще не буду использовать модели django).

Мои вопросы ...:

• Это хорошая архитектура, с точки зрения масштабируемости? Существуют ли вопиющие, угрожающие проекту недостатки архитектуры? Было бы лучше просто использовать ASP.NET и забыть о вызовах REST?

• Архитектура также вызывает озабоченность по поводу хостинга, так как трудно найти хост django, который также выполняет .NET. Хочет ли интерфейс для Google App Engine и задней панели Windows Azure быть мудрым делом?

Ваши ответы будут высоко оценены.

Спасибо.

Answer 1

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

Разделение слоя презентации, возможно, даже в будущем, имеющего более одного такого уровня для разных клиентских платформ - также разумно, я видел успешные системы на этих линиях.

Услуги RESTful, по-видимому, очень эффективны с точки зрения простоты разработки. Я бы ожидал, что накладные расходы будут связаны с использованием механизма передачи текстовых данных (веб-сервисы любого вкуса), но с осторожным дизайном это обычно не является непреодолимой проблемой - посмотрите на производительность многих приложений с богатым интерфейсом пользовательского интерфейса, которые они почти наверняка используя вызовы AJAX с текстовыми полезными нагрузками.

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

Answer 2

В общем, наличие python-django во внешнем интерфейсе и вызов некоторых основных сервисов через сеть для извлечения и анализа данных - вполне нормальная архитектура. Мы используем это почти для всего, что есть в нашей компании. Мы не используем .NET, но я не думаю, что это имеет большое значение. Этот подход очень масштабируемый, поскольку, если наше узкое место является основным, мы добавляем вычислительную мощность там, не касаясь интерфейсов вообще и наоборот.

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

Answer 3

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

Python/Django, REST и т. Д. Все выглядят неплохо. Избегание интерфейсных компонентов ASP.NET, безусловно, звучит хорошо с точки зрения стоимости обслуживания, переносимости на другие (то есть более дешевые) интерфейсные серверы и т. Д.Масштабируемость должна фактически улучшиться за счет внедрения архитектуры, которую вы предлагаете.

Что касается Google AppEngine, вы можете выбрать приложение AppEngine, Java и Google toolkit. Очень хорошая платформа для веб-приложений, особенно если вам нужен богатый пользовательский интерфейс и масштабируемость, это серьезная проблема. Выбор для Azure в этой настройке вообще не имеет смысла, если вы не «заперты» с помощью .NET.

Answer 4

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

В частности, используйте ASP.net MVC для переднего конца вместо python.

Используйте WCF для общения между вашим интерфейсом и бэкэнд. Использование SOAP или REST - это просто изменение конфигурации.

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