Рабочая роль WCF Производительность

Question

Я пытаюсь определить наилучший из возможных сценариев размещения услуг WCF.Я собираю локальное веб-приложение очень большого объема (которое в конечном итоге будет размещено в Azure).Приложение ASP.Net будет взаимодействовать со службами WCF, размещенными в рабочих ролях, с помощью NetTcpBinding.Я хотел бы проверить следующие предположения:

1) Размещение служб в рабочих ролях, затем использование служебной шины (с использованием ACS для безопасности) для подключения клиента и службы всегда будет медленнее, чем размещение служб WCF в работнике.ролей, подключающихся напрямую к конечной точке и использующих подход имени пользователя / пароля.

2) Службы REST всегда будут работать медленнее, чем службы NetTcpBinding, поскольку они используют HTTP вместо двоичного.

Изначально яЯ выбрал подход ServiceBus, потому что мне нравится, насколько чист механизм защиты, но если текущее соединение не может быть прямым, ретрансляция вызовет значительные издержки.

Исходя из этих предположений, я выбрал: -WCF-сервисы, размещенные в рабочих ролях -спользовательское имя пользователя / пароль или использовать имя пользователя / пароль ACS ??????-NetTcpBinding

Это звучит правильно?Другим требованием является наименьшее количество кода безопасности, который мне нужно создать.Так что, если я буду использовать модель имени пользователя и пароля ACS или ????

, то любая идея о том, как настроить наиболее эффективную, наименее настраиваемую защиту кода, будет отличной!

спасибо

Answer 1

Первое: эталон, эталон, эталон. Мы были весьма удивлены эксплуатационными характеристиками Azure; в частности, SQL Azure работал медленнее, чем наша система Rackspace, в два-три раза. Задержка между базой данных и сервером затмила все остальное.

Тем не менее: теоретически я бы подтвердил ваше предположение, что использование имен пользователей / паролей между клиентом и службой будет быстрее, чем ACS.

Но нужно ли вообще проверять учетные данные? Можете ли вы использовать частные внутренние конечные точки (как здесь: http://msdn.microsoft.com/en-us/library/windowsazure/gg432980.aspx) - если так, то нет никакой необходимости в проверке учетных данных.

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

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

Но, опять же: я бы создал несколько примеров приложений и протестировал бы для себя. (И вернитесь и опубликуйте ссылку на ваш блог, где вы публикуете результаты, а?)

Answer 2

Я бы не использовал ACL, если он вам действительно не нужен, но я не думаю, что это ваш сценарий. Добавление дополнительного брокера только для аутентификации клиентов добавит ненужную задержку. Во-вторых, вам не нужна рабочая роль для использования NetTcp, вы можете просто настроить веб-роль с конечной точкой tcp. Это позволит разместить ваш сервис в IIS с использованием WAS и TCP. Вы даже можете настроить службы WCF в частной конечной точке в Azure, которую может видеть только веб-приложение, также размещенное в Azure, поэтому аутентификация не требуется.