Scenariusze routingu

Artykuł
03/02/2024

Chociaż usługa routingu jest wysoce dostosowywalna, może być wyzwaniem dla projektowania wydajnej logiki routingu podczas tworzenia nowej konfiguracji od podstaw. Istnieje jednak kilka typowych scenariuszy, które należy wykonać w większości konfiguracji usługi routingu. Chociaż te scenariusze mogą nie być stosowane bezpośrednio do określonej konfiguracji, zrozumienie sposobu konfigurowania usługi routingu w celu obsługi tych scenariuszy pomoże Ci zrozumieć usługę routingu.

Typowe scenariusze

Najbardziej podstawowym zastosowaniem usługi routingu jest agregowanie wielu docelowych punktów końcowych w celu zmniejszenia liczby punktów końcowych uwidocznionych dla aplikacji klienckich, a następnie użycie filtrów komunikatów do kierowania każdego komunikatu do poprawnego miejsca docelowego. Komunikaty mogą być kierowane na podstawie wymagań dotyczących przetwarzania logicznego lub fizycznego, takich jak typ komunikatu, który musi być przetwarzany przez określoną usługę lub na podstawie dowolnych potrzeb biznesowych, takich jak zapewnienie priorytetowego przetwarzania komunikatów z określonego źródła. W poniższej tabeli wymieniono niektóre typowe scenariusze i sytuacje, w których występują:

Scenariusz	Użyj, kiedy
Przechowywanie wersji usługi	Musisz obsługiwać wiele wersji usługi lub wdrożyć zaktualizowaną usługę w przyszłości
Partycjonowanie danych usługi	Musisz podzielić usługę na wiele hostów
Aktualizacja dynamiczna	Aby obsługiwać zmieniające się wdrożenia usług, należy dynamicznie ponownie skonfigurować logikę routingu w czasie wykonywania
Multiemisji	Musisz wysłać jeden komunikat do wielu punktów końcowych
Mostkowanie protokołu	Komunikaty są odbierane za pośrednictwem jednego protokołu transportowego, a docelowy punkt końcowy używa innego protokołu
Obsługa błędów	Należy zapewnić odporność na awarie sieci i błędy komunikacji

Uwaga

Chociaż wiele przedstawionych scenariuszy jest specyficznych dla określonych potrzeb biznesowych lub wymagań dotyczących przetwarzania, planowanie obsługi aktualizacji dynamicznych i obsługi błędów często może być uważane za najlepsze rozwiązania, ponieważ umożliwiają modyfikowanie logiki routingu w czasie wykonywania i odzyskiwanie po przejściowych awariach sieci i komunikacji.

Przechowywanie wersji usługi

Podczas wprowadzania nowej wersji usługi należy często utrzymywać poprzednią wersję, dopóki wszyscy klienci nie przejdą do nowej usługi. Jest to szczególnie ważne, jeśli usługa jest długotrwałym procesem, który trwa kilka dni, tygodni, a nawet miesięcy. Zwykle wymaga to zaimplementowania nowego adresu punktu końcowego dla nowej usługi przy zachowaniu oryginalnego punktu końcowego dla poprzedniej wersji.

Korzystając z usługi routingu, można uwidocznić jeden punkt końcowy w celu odbierania komunikatów z aplikacji klienckich, a następnie kierować każdy komunikat do poprawnej wersji usługi na podstawie zawartości komunikatu. Najbardziej podstawowa implementacja polega na dodaniu nagłówka niestandardowego do komunikatu wskazującego wersję usługi, przez którą ma zostać przetworzony komunikat. Usługa routingu może użyć klasy XPathMessageFilter do sprawdzenia każdego komunikatu pod kątem obecności nagłówka niestandardowego i kierowania komunikatu do odpowiedniego punktu końcowego docelowego.

Aby zapoznać się z krokami użytymi do utworzenia konfiguracji przechowywania wersji usługi, zobacz How To: Service Versioning (Instrukcje: przechowywanie wersji usługi).

Partycjonowanie danych usługi

Podczas projektowania środowiska rozproszonego często pożądane jest rozłożenie obciążenia przetwarzania na wielu komputerach w celu zapewnienia wysokiej dostępności, zmniejszenia obciążenia przetwarzania na poszczególnych komputerach lub zapewnienia dedykowanych zasobów dla określonego podzestawu komunikatów. Chociaż usługa routingu nie zastępuje dedykowanego rozwiązania do równoważenia obciążenia, jego możliwość wykonywania routingu opartego na zawartości może służyć do kierowania w inny sposób podobnych komunikatów do określonych miejsc docelowych. Na przykład może istnieć wymóg przetwarzania komunikatów od określonego klienta niezależnie od komunikatów odebranych od innych klientów.

Aby zapoznać się z krokami użytymi do utworzenia konfiguracji partycjonowania danych usługi, zobacz How To: Service Data Partitioning (Instrukcje: partycjonowanie danych usługi).

Routing dynamiczny

Często pożądane jest zmodyfikowanie konfiguracji routingu w celu zaspokojenia zmieniających się potrzeb biznesowych, takich jak dodanie trasy do nowszej wersji usługi, zmiana kryteriów routingu lub zmiana docelowego punktu końcowego określony komunikat, do którego filtruje trasy. Usługa routingu umożliwia wykonanie tej czynności za pomocą RoutingExtensionpolecenia , który umożliwia udostępnienie nowej konfiguracji routingu w czasie wykonywania. Nowa konfiguracja zaczyna obowiązywać natychmiast, ale ma wpływ tylko na wszystkie nowe sesje przetwarzane przez usługę routingu.

Aby zapoznać się z krokami używanymi do implementowania routingu dynamicznego, zobacz Instrukcje: aktualizacja dynamiczna.

Multiemisji

Podczas routingu komunikatów zazwyczaj każdy komunikat jest przekierowywany do jednego konkretnego punktu końcowego docelowego. Jednak czasami może być konieczne kierowanie kopii komunikatu do wielu docelowych punktów końcowych. Aby wykonać routing multiemisji, muszą być spełnione następujące warunki:

Kształt kanału nie może być odpowiedzią na żądanie (choć może to być jednokierunkowe lub dwukierunkowe), ponieważ żądanie-odpowiedź nakazuje odbieranie tylko jednej odpowiedzi przez aplikację kliencą w odpowiedzi na żądanie.
Podczas oceniania komunikatu wiele filtrów musi zwracać wartość true .

Jeśli te warunki zostaną spełnione, każdy docelowy punkt końcowy skojarzony z filtrem, który zwraca wartość true, otrzyma kopię komunikatu.

Mostkowanie protokołu

W przypadku routingu komunikatów między różnymi protokołami PROTOKOŁU SOAP usługa routingu używa interfejsów API programu WCF do konwertowania komunikatu z jednego protokołu na drugi. Dzieje się tak automatycznie, gdy punkty końcowe usługi uwidocznione przez usługę routingu używają innego protokołu niż punkty końcowe klienta, do których są kierowane komunikaty. To zachowanie można wyłączyć, jeśli używane protokoły nie są standardowe; należy jednak podać własny kod pomostowy.

Obsługa błędów

W środowisku rozproszonym nie zdarza się, aby napotkać przejściowe błędy sieci lub komunikacji. Bez pośredniczącej usługi, takiej jak usługa routingu, obciążenie obsługi takich awarii spada na aplikację kliencą. Jeśli aplikacja kliencka nie zawiera określonej logiki, aby ponowić próbę w przypadku awarii sieci lub komunikacji i znajomości alternatywnych lokalizacji, użytkownik może napotkać scenariusze, w których komunikat musi zostać przesłany wiele razy, zanim zostanie pomyślnie przetworzony przez usługę docelową. Może to prowadzić do niezadowolenia klientów z aplikacji, ponieważ może być postrzegana jako zawodna.

Usługa routingu próbuje rozwiązać ten scenariusz, zapewniając niezawodne możliwości obsługi błędów dla komunikatów, które napotykają błędy związane z siecią lub komunikacją. Tworząc listę możliwych docelowych punktów końcowych i kojarząc tę listę z każdym filtrem komunikatów, usuwasz pojedynczy punkt awarii, mając tylko jedno możliwe miejsce docelowe. W przypadku awarii usługa routingu podejmie próbę dostarczenia komunikatu do następnego punktu końcowego na liście do momentu dostarczenia komunikatu, wystąpienia niepowodzenia komunikacji lub wyczerpania wszystkich punktów końcowych.

Aby zapoznać się z krokami używanymi do konfigurowania obsługi błędów, zobacz Instrukcje: obsługa błędów.