Высокопроизводительное связующее ПО для распределенных приложений

Question

Я разрабатываю распределенную архитектуру, в которой у нас будет веб-интерфейс (возможно, ASP.NET MVC и, возможно, ExtJS), а затем определенное количество модулей приложения в качестве серверных служб. Моя идея состоит в том, чтобы полностью освободить их для развертывания.Службы .NET на одном, двух или трех разных серверах, поэтому я могу распределить рабочую нагрузку между несколькими компьютерами.

Какую технологию мне следует использовать для записи и обмена данными между этими внутренними службами?

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

О службах WCF самих по себе, лучше разместить их в IIS или в пользовательской письменной службе Windows?

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

Спасибо, Davide.

Answer 1

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

Для начала я рекомендую использовать WCF и IIS. Еще лучше, попробуйте часть вашей системы, как доказательство концепции выбранных технологий. Затем профиль, чтобы увидеть, где / что слишком медленно для ваших требований. Подход WCF / IIS обеспечивает простоту реализации и обслуживания. Затем, если вы обнаружите, что IIS вызывает слишком много ограничений (и не может быть настроен для удаления этих ограничений, IIS имеет много настроек), тогда вы можете сделать хостинг для своих служб. Кроме того, если SOAP использует слишком большую полосу пропускания для ваших требований, попробуйте двоичные передачи. Если вы можете реализовать часть вашей системы заранее для выполнения этих тестов, то вы можете избежать некоторых переделок.

Answer 2

Хотите ли вы, чтобы API помогал вам быстро создавать уровень обслуживания, управлять уровнем обслуживания, легко переконфигурировать уровень обслуживания и т. Д., Или вам нужно создать высокопроизводительный уровень обслуживания, где нужно избегать всего ненужного?

WCFЭто универсальный (унифицированный), настраиваемый и расширяемый API для построения сервисного уровня.Но эти конфигурации, расширяемость, унификация имеют свои издержки.Первая стоимость - сложность API, что довольно забавно, потому что когда API не расширяемый, разработчики жалуются на него, а когда он расширяемый, разработчики жалуются на его сложность и влияние на производительность.

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

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

• система должна быть в состоянии обслуживать xxx одновременных запросов
• среднее времяобслуживание запроса должно быть xxx мс
• максимальное время обработки запроса должно быть xxx мс

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