Azure Integration Services som målarkitektur
Azure Integration Services är ingen enda ersättningsprodukt. Det är ett arkitekturval där Logic Apps, Service Bus, API Management och egen kod får separata ansvar när ett BizTalk-flöde behöver mer än orkestrering.
Ge varje tjänst ett ansvar
Låt Logic Apps bära workflow och kopplingar. Service Bus queues ger en konsument per meddelande, medan topics och subscriptions ger en kopia per prenumeration och kan filtrera med regler. API Management är gateway för API-anrop och kan kontrollera autentisering, kvoter, routing och transformation. Lägg inte in en tjänst om flödets krav inte behöver den.
Bestäm meddelandebeteendet
Service Bus Peek Lock kan leverera ett meddelande igen om konsumenten faller innan den slutför behandlingen. Receive and Delete kan i stället förlora meddelandet vid fel efter mottagning. Det innebär att dubbletthantering och idempotens är ett applikationsansvar, inte något som försvinner när MessageBox ersätts.
Gör fel synliga
Queues och subscriptions har en dead-letter queue, men den töms inte automatiskt. Definiera vem som läser den, hur orsaken visas och när ett korrigerat meddelande får skickas om. Workflowhistorik, Azure Monitor och Application Insights behöver kopplas till ett affärs-ID så att ett ärende kan följas över tjänstegränser.
Placera egen kod med avsikt
Standard-workflows kan köra lokal .NET-kod för bland annat parsing, validering och enklare transformation. Microsoft anger samtidigt att denna modell inte passar långa processer, stora transformationer, komplex batching eller strömmande BizTalk-pipelinekomponenter. Sådan kod behöver en separat tjänst eller ett annat mönster.
Undvik en ny central monolit
Gruppera resurser efter flöde, livscykel och ägarskap. Ett gemensamt API eller en loggningstjänst kan vara rationellt, men ett krav att allt passerar samma workflow skapar samma operativa koppling som migreringen skulle minska. Testa skalning, återställning och deployment som en hel kedja före första produktionsvågen.