Архитектурные соображения

Question

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

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

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

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

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

Спасибо.

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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