Routningsscenarier
Routningstjänsten är mycket anpassningsbar, men det kan vara en utmaning att utforma effektiv routningslogik när du skapar en ny konfiguration från grunden. Det finns dock flera vanliga scenarier som de flesta routningstjänstkonfigurationer följer. Även om de här scenarierna kanske inte gäller direkt för din specifika konfiguration kan du förstå hur routningstjänsten kan konfigureras för att hantera dessa scenarier.
Vanliga scenarier
Den mest grundläggande användningen av routningstjänsten är att aggregera flera målslutpunkter för att minska antalet slutpunkter som exponeras för klientprogrammen och sedan använda meddelandefilter för att dirigera varje meddelande till rätt mål. Meddelanden kan dirigeras baserat på logiska eller fysiska bearbetningskrav, till exempel en meddelandetyp som måste bearbetas av en specifik tjänst eller baseras på godtyckliga affärsbehov, till exempel att prioritera bearbetning av meddelanden från en specifik källa. I följande tabell visas några vanliga scenarier och när de påträffas:
| Scenario | Använd när |
|---|---|
| Versionshantering av tjänster | Du måste ha stöd för flera versioner av en tjänst eller distribuera en uppdaterad tjänst i framtiden |
| Partitionering av tjänstdata | Du måste partitioneras över flera värdar |
| Dynamisk uppdatering | Du måste konfigurera om routningslogik dynamiskt vid körning för att hantera ändrade tjänstdistributioner |
| Multicast | Du måste skicka ett meddelande till flera slutpunkter |
| Protokollbryggning | Du får meddelanden via ett transportprotokoll och målslutpunkten använder ett annat protokoll |
| Felhantering | Du måste ge motståndskraft mot nätverksfel och kommunikationsfel |
Kommentar
Även om många av de scenarier som presenteras är specifika för vissa affärsbehov eller bearbetningskrav, kan planering för att stödja dynamiska uppdateringar och användning av felhantering ofta betraktas som bästa praxis eftersom de gör att du kan ändra routningslogik vid körning och återställa från tillfälliga nätverks- och kommunikationsfel.
Versionshantering av tjänster
När du introducerar en ny version av en tjänst måste du ofta behålla den tidigare versionen tills alla klienter har övergått till den nya tjänsten. Detta är särskilt viktigt om tjänsten är en tidskrävande process som tar dagar, veckor eller till och med månader att slutföra. Detta kräver vanligtvis att du implementerar en ny slutpunktsadress för den nya tjänsten samtidigt som den ursprungliga slutpunkten för den tidigare versionen bibehålls.
Genom att använda routningstjänsten kan du exponera en slutpunkt för att ta emot meddelanden från klientprogram och sedan dirigera varje meddelande till rätt tjänstversion baserat på meddelandeinnehållet. Den mest grundläggande implementeringen innebär att lägga till en anpassad rubrik i meddelandet som anger vilken version av tjänsten som meddelandet ska bearbetas av. Routningstjänsten kan använda XPathMessageFilter för att inspektera varje meddelande för förekomsten av det anpassade huvudet och dirigera meddelandet till rätt målslutpunkt.
De steg som används för att skapa en konfiguration av tjänstversioner finns i How To: Service Versionsing (Så här gör du: Tjänstversioner).
Partitionering av tjänstdata
När du utformar en distribuerad miljö är det ofta önskvärt att sprida bearbetningsbelastningen över flera datorer för att ge hög tillgänglighet, minska bearbetningsbelastningen på enskilda datorer eller för att tillhandahålla dedikerade resurser för en specifik delmängd av meddelanden. Routningstjänsten ersätter inte en dedikerad belastningsutjämningslösning, men dess möjlighet att utföra innehållsbaserad routning kan användas för att dirigera meddelanden som annars liknar specifika mål. Du kan till exempel ha ett krav på att bearbeta meddelanden från en specifik klient separat från meddelanden som tas emot från andra klienter.
De steg som används för att skapa en konfiguration för tjänstdatapartitionering finns i How To: Service Data Partitioning (Så här gör du: Partitionering av tjänstdata).
Dynamisk routning
Ofta är det önskvärt att ändra routningskonfigurationen för att uppfylla föränderliga affärsbehov, till exempel lägga till en väg till en nyare version av en tjänst, ändra routningsvillkor eller ändra målslutpunkten ett specifikt meddelande som filtret dirigerar till. Med routningstjänsten kan du göra detta via RoutingExtension, som gör att du kan ange en ny RoutingConfiguration under körningstiden. Den nya konfigurationen börjar gälla omedelbart, men påverkar bara alla nya sessioner som bearbetas av routningstjänsten.
De steg som används för att implementera dynamisk routning finns i How To: Dynamic Update (Så här gör du: Dynamisk uppdatering).
Multicast
När du dirigerar meddelanden dirigerar du vanligtvis varje meddelande till en specifik målslutpunkt. Du kan dock ibland behöva dirigera en kopia av meddelandet till flera målslutpunkter. För att utföra multicast-routning måste följande villkor vara uppfyllda:
Kanalformen får inte vara begärandesvar (även om den kan vara enkelriktad eller duplex) eftersom begärandesvar kräver att endast ett svar kan tas emot av klientprogrammet som svar på begäran.
Flera filter måste returnera true när meddelandet utvärderas.
Om dessa villkor uppfylls får varje målslutpunkt som är associerad med ett filter som returnerar true en kopia av meddelandet.
Protokollbryggning
När du dirigerar meddelanden mellan olika SOAP-protokoll använder routningstjänsten WCF-API:er för att konvertera meddelandet från ett protokoll till det andra. Detta inträffar automatiskt när tjänstslutpunkterna som exponeras av routningstjänsten använder ett annat protokoll än de klientslutpunkter som meddelanden dirigeras till. Det går att inaktivera det här beteendet om de protokoll som används inte är standard. Du måste dock ange din egen bryggningskod.
Felhantering
I en distribuerad miljö är det inte ovanligt att det uppstår tillfälliga nätverks- eller kommunikationsfel. Utan en mellanliggande tjänst, till exempel routningstjänsten, faller ansvaret för att hantera sådana fel på klientprogrammet. Om klientprogrammet inte innehåller specifik logik för att försöka igen i händelse av nätverks- eller kommunikationsfel och kunskap om alternativa platser, kan användaren stöta på scenarier där ett meddelande måste skickas flera gånger innan det bearbetas av måltjänsten. Detta kan leda till kundens missnöje med programmet, eftersom det kan uppfattas som opålitligt.
Routningstjänsten försöker åtgärda det här scenariot genom att tillhandahålla robusta funktioner för felhantering för meddelanden som påträffar nätverks- eller kommunikationsrelaterade fel. Genom att skapa en lista över möjliga målslutpunkter och associera den här listan med varje meddelandefilter tar du bort den enda felpunkten som uppstår genom att bara ha ett möjligt mål. I händelse av ett fel försöker routningstjänsten leverera meddelandet till nästa slutpunkt i listan tills meddelandet har levererats, ett icke-kommunikationsfel inträffar eller alla slutpunkter har uttömts.
De steg som används för att konfigurera felhantering finns i Så här: Felhantering.
I det här avsnittet
Anvisningar: Versionshantering av tjänster
Anvisningar: Partitionering av tjänstdata
Anvisningar: Dynamisk uppdatering