Najlepsze rozwiązania dotyczące hostowania Internetowych usług informacyjnych
W tym temacie opisano niektóre najlepsze rozwiązania dotyczące hostowania usług Windows Communication Foundation (WCF).
Implementowanie usług WCF jako bibliotek DLL
Zaimplementowanie usługi WCF jako biblioteki DLL wdrożonej w katalogu \bin aplikacji sieci Web umożliwia ponowne użycie usługi poza modelem aplikacji sieci Web, na przykład w środowisku testowym, które może nie mieć wdrożonych usług Internet Information Services (IIS).
Hosty usług w aplikacjach hostowanych przez usługi IIS
Nie używaj imperatywnych interfejsów API samoobsługowych do tworzenia nowych hostów usług, które nasłuchują w transportach sieciowych, które nie są natywnie obsługiwane przez środowisko hostingu usług IIS (na przykład usługi IIS 6.0 do hostowania usług TCP, ponieważ komunikacja TCP nie jest natywnie obsługiwana w usługach IIS 6.0). Takie podejście nie jest zalecane. Hosty usług utworzone imperatywnie nie są znane w środowisku hostingu usług IIS. Krytycznym punktem jest to, że przetwarzanie wykonywane przez utworzone usługi imperatywne nie jest uwzględniane przez usługi IIS, gdy określa, czy pula aplikacji hostingu jest bezczynna. Wynika to z tego, że aplikacje, które mają tak utworzone hosty usług imperatywnie, mają środowisko hostingu usług IIS, które agresywnie usuwa procesy hosta usług IIS.
Identyfikatory URI i punkty końcowe hostowane przez usługi IIS
Punkty końcowe dla usługi hostowanej przez usługi IIS powinny być konfigurowane przy użyciu względnych identyfikatorów URI (Uniform Resource Identifiers), a nie adresów bezwzględnych. Gwarantuje to, że adres punktu końcowego mieści się w zestawie adresów URI należących do aplikacji hostingowej i gwarantuje, że aktywacja oparta na komunikatach odbywa się zgodnie z oczekiwaniami.
Zarządzanie stanami i odtwarzanie procesów
Środowisko hostingu usług IIS jest zoptymalizowane pod kątem usług, które nie utrzymują stanu lokalnego w pamięci. Usługi IIS odtwarzają proces hosta w odpowiedzi na różne zdarzenia zewnętrzne i wewnętrzne, co powoduje utratę stanu niestabilnego przechowywanego wyłącznie w pamięci. Usługi hostowane w usługach IIS powinny przechowywać swój stan poza procesem (na przykład w bazie danych) lub w pamięci podręcznej, którą można łatwo utworzyć ponownie, jeśli wystąpi zdarzenie recyklingu aplikacji.
Uwaga
Protokoły WCF korzystają z niestabilnego stanu w pamięci i niezawodności warstwy komunikatów oraz zabezpieczeń. Niezawodne sesje i sesje zabezpieczeń programu WCF mogą zostać nieoczekiwanie zakończone z powodu recyklingu aplikacji. Aplikacje hostowane przez usługi IIS, które korzystają z tych protokołów, powinny zależeć od innego klucza sesji niż klucz sesji dostarczonej przez usługę WCF w celu korelowania stanu warstwy aplikacji (na przykład konstrukcji warstwy aplikacji lub niestandardowego nagłówka korelacji) lub wyłączać odtwarzanie procesów usług IIS dla hostowanej aplikacji.
Optymalizowanie wydajności w scenariuszach warstwy środkowej
Aby uzyskać optymalną wydajność w scenariuszu warstwy środkowej — usługa, która wywołuje inne usługi w odpowiedzi na komunikaty przychodzące — tworzy wystąpienie klienta usługi WCF do usługi zdalnej raz i ponownie użyj go w wielu żądaniach przychodzących. Utworzenie wystąpienia klientów usługi WCF jest kosztowną operacją w porównaniu z wykonywaniem wywołania usługi w istniejącym wystąpieniu klienta, a scenariusze warstwy środkowej generują różne wzrosty wydajności przez buforowanie klientów zdalnych między żądaniami. Klienci usługi WCF są bezpieczni wątkowo, więc nie jest konieczne synchronizowanie dostępu do klienta między wieloma wątkami.
Scenariusze warstwy środkowej generują również wzrost wydajności przy użyciu asynchronicznych interfejsów API generowanych przez svcutil /a tę opcję. Opcja /a powoduje, że narzędzie ServiceModel Metadata Tool (Svcutil.exe) generuje BeginXXX/EndXXX metody dla każdej operacji usługi, co umożliwia potencjalnie długotrwałe wywołania usług zdalnych w wątkach w tle.
Usługa WCF w scenariuszach z wieloma nazwami lub wieloma nazwami
Usługi WCF można wdrożyć w farmie sieci Web usług IIS, gdzie zestaw komputerów ma wspólną nazwę zewnętrzną (na przykład http://www.contoso.com), ale są indywidualnie adresowane przez różne nazwy hosta (na przykład http://www.contoso.com mogą kierować ruch do dwóch różnych maszyn o nazwie http://machine1.internal.contoso.com i http://machine2.internal.contoso.com). Ten scenariusz wdrażania jest w pełni obsługiwany przez usługę WCF, ale wymaga specjalnej konfiguracji witryny sieci Web usług IIS hostowania usług WCF w celu wyświetlenia poprawnej (zewnętrznej) nazwy hosta w metadanych usługi (Język opisu usług sieci Web).
Aby upewnić się, że prawidłowa nazwa hosta jest wyświetlana w wygenerowanych metadanych usługi WCF, skonfiguruj domyślną tożsamość dla witryny sieci Web usług IIS, która hostuje usługi WCF, aby używać jawnej nazwy hosta. Na przykład komputery znajdujące się w www.contoso.com farmie powinny używać powiązania lokacji usług IIS *:80:www.contoso.com dla protokołu HTTP i *:443:www.contoso.com dla protokołu HTTPS.
Powiązania witryny sieci Web usług IIS można skonfigurować przy użyciu przystawki programu MICROSOFT Management Console (MMC) usług IIS.
Pule aplikacji uruchomione w różnych kontekstach użytkownika zastępują zestawy z innych kont w folderze tymczasowym
Aby upewnić się, że pule aplikacji działające w różnych kontekstach użytkownika nie mogą zastąpić zestawów z innych kont w folderze plików tymczasowych ASP.NET, użyj różnych tożsamości i folderów tymczasowych dla różnych aplikacji. Jeśli na przykład masz dwie aplikacje wirtualne /Application1 i / Application2, możesz utworzyć dwie pule aplikacji, A i B, z dwiema różnymi tożsamościami. Pula aplikacji A może działać w ramach jednej tożsamości użytkownika (użytkownik1), podczas gdy pula aplikacji B może działać w ramach innej tożsamości użytkownika (użytkownik2) i skonfigurować /Application1 do używania A i /Application2 do używania B.
W pliku Web.config można skonfigurować folder tymczasowy przy użyciu pliku <system.web/compilation/@tempFolder>. W przypadku /Application1 może to być "c:\tempForUser1", a dla aplikacji2 może to być "c:\tempForUser2". Przyznaj odpowiednie uprawnienie do zapisu do tych folderów dla tych dwóch tożsamości.
Następnie użytkownik user2 nie może zmienić folderu generowania kodu dla /application2 (w obszarze c:\tempForUser1).
Włączanie przetwarzania asynchronicznego
Domyślnie komunikaty wysyłane do usługi WCF hostowanej w usługach IIS 6.0 i starszych są przetwarzane w sposób synchroniczny. ASP.NET wywołania do programu WCF we własnym wątku (wątku procesu roboczego ASP.NET), a program WCF używa innego wątku do przetwarzania żądania. Program WCF trzyma się wątku roboczego ASP.NET, dopóki nie zakończy przetwarzania. Prowadzi to do synchronicznego przetwarzania żądań. Przetwarzanie żądań asynchronicznie umożliwia większą skalowalność, ponieważ zmniejsza liczbę wątków wymaganych do przetworzenia żądania — WCF nie jest utrzymywana w wątku ASP.NET podczas przetwarzania żądania. Użycie zachowania asynchronicznego nie jest zalecane w przypadku maszyn z uruchomionymi usługami IIS 6.0, ponieważ nie ma możliwości ograniczania żądań przychodzących, które otwierają serwer na ataki typu "odmowa usługi " (DOS). Począwszy od usług IIS 7.0 wprowadzono współbieżne ograniczenie żądań: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0]"MaxConcurrentRequestsPerCpu. Dzięki temu nowemu ograniczaniu można bezpiecznie używać przetwarzania asynchronicznego. Domyślnie w usługach IIS 7.0 program obsługi asynchronicznej i moduł są rejestrowane. Jeśli ta opcja została wyłączona, możesz ręcznie włączyć asynchroniczne przetwarzanie żądań w pliku Web.config aplikacji. Używane ustawienia zależą od ustawienia aspNetCompatibilityEnabled . Jeśli ustawiono aspNetCompatibilityEnabled wartość false, skonfiguruj element System.ServiceModel.Activation.ServiceHttpModule , jak pokazano w poniższym fragmencie konfiguracji.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="false" />
</system.serviceModel>
<system.webServer>
<modules>
<remove name="ServiceModel"/>
<add name="ServiceModel"
preCondition="integratedMode,runtimeVersionv2.0"
type="System.ServiceModel.Activation.ServiceHttpModule, System.ServiceModel,Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</modules>
</system.webServer>
Jeśli ustawiono aspNetCompatibilityEnabled wartość true, skonfiguruj element System.ServiceModel.Activation.ServiceHttpHandlerFactory , jak pokazano w poniższym fragmencie konfiguracji.
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>
<system.webServer>
<handlers>
<clear/>
<add name="TestAsyncHttpHandler"
path="*.svc"
verb="*"
type="System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
/>
</handlers>
</system.webServer>