Orsaken till att vi valde att börja jobba med NServiceBus för ett antal år sedan är att vi alltid har ganska krävande integrationer i e-handelssystem där nära realtid i kombination med frikoppling mellan olika system är viktigt för så väl kundupplevelse som krav på upptid och stabilitet. Fördelarna vi sett med NServiceBus är enkelheten i att få grundstrukturen att bara fungera och att fokus i stället kan läggas på design av meddelanden och mappning av dessa mot respektive system. Hanteringen av den lokala lagringen av meddelande och distributionen till övriga noder i systemet bara fungerar. Vi tycker även att bussmodellen passar väldigt bra till våra tillämpningar, då vi ofta har samma meddelande som ska konsumeras och skapas av olika system där respektive system har ansvar för olika delar av meddelandet. Att undvika många direktkopplingar mellan respektive system utan i stället kunna lägga ut ett meddelande på bussen är därför värt mycket.
Just inbyggd felhantering med omsändningar och att köer byggs upp lokalt på respektive nod för att sedan överföras till övriga noder gör systemen mycket tåliga för avbrott i nätverk eller till följd av att ett mottagarsystem ligger nere för underhåll eller till och med oplanerat. När alla system fungerar som det är tänkt sker uppdateringarna mellan systemen väldigt fort, vilket gör att effekten blir väl så bra som realtidskopplingar.
I och med att utbytet mellan system sker via meddelanden så möjliggör detta även att hanteringen kan parallelliseras på ett bra sätt. Om tiden för bearbetning blir ett problem i en nod kan man enkelt utöka med ytterligare en nod för att läsa in samma meddelandetyp och dessa delar då på arbetsbördan. Detta är något som är extra viktigt för att få ut all kraft ur dagens CPUer med många kärnor.
Några tips som vi delade med oss under seminariet var:
- Tänk på att skapa ”optimala business” meddelanden.
Med detta menar vi att utformning av meddelande inte ska göras utifrån något visst system utan snarare baserat på hur man optimalt beskriver ett objekt i er verksamhet. T ex vad behövs för att beskriva en order, en kund eller en produkt i er verksamhet. Utgå från detta när meddelande görs. Varje nod behöver sedan ”mappa” detta mot sitt målsystem. Fördelen med att göra design på detta sätt är att systemen blir mer utbytbara över tiden utan att övriga system/noder behöver förändras.
- Tänk på att göra minimalt med beroenden mellan meddelanden eller sekvens mellan dem.
I och med att meddelanden inte behöver komma fram i den ordning de skickas, till följd av parallellisering eller felhantering enligt ovan, så är det viktigt att undvika att inläsning av ett meddelande bara kan göras om ett föregående meddelande redan gjorts. Där det ändå finns beroenden så är det viktigt att fallen där meddelanden kommer ur sekvens hanteras på ett bra sätt.
Har ni funderingar kring hur ni ska börja jobba med denna typ av bussintegrationer så får ni gärna höra av er för att prata mer om detta.
