Kø-øvelse

Her er en lille, aktuel og konkret øvelse fra min hverdag. Forestil dig at du skal lave en arkitektur for anskaffelse og integration af en fem-seks forskellige produktionssystemer over de næste par år. Hvert system skal løbende rapportere transaktions-data til ét fælles datavarehus. Disse transaktions-data skal leveres på under et sekund og med leverance-garanti, helst i en garanteret rækkefølge. Både datavarehus og hvert produktionssystem skal kunne have service-vinduer eller mindre udfald uden at skulle ind i en større catch-up eller udrednings-proces af den grund. Utilgængelighed af datavarehuset må ikke bremse det enkelte produktionssystem lige som manglende data fra produktionssystemet må bremse datavarehuset. Produktionssystemerne og datavarehuset skal med andre ord være afkoblede.

Asynkron kommunikation er svaret på kravet om afkobling, men det er ikke helt nok. Filflytning af forskellig art som fx FTP er svær at gøre hurtigt nok og mit gæt er, at der skal kodes og testes en del for at sikre robusthed i løsningen når begge parter kan risikere at være utilgængelige på forskellige tidspunkter. Når vi smider garanti for leverance med i kurven af krav, er en kø-mekanisme med persistens oplagt som løsning.

Men hvilket kø-produkt skal anvendes til formålet?

Her har du brug for følgende ekstra information: Formålet er at gøre arkitekturen parat til at servicere de forretningsmæssigt bedste produktionssystemer på markedet inden for hver deres område. Du har derfor ikke løst din opgave hvis du kræver, at systemerne bygger på fx. Java da du ad den vej risikerer at diskvalificerer de i øvrigt bedste løsninger derude. Da hvert system vedligeholdes af leverandørerne og bliver hostet forskellige steder ude i byen har du i øvrigt heller ikke specielle interesser i at stille krav til teknologien bag produktionssystemerne. Forudsat at prisen ikke bliver mange hundredetusinder, vil det bedste snarere end det billigste integrationsprodukt være at foretrække.

Mit eget bud er IBM Websphere MQ – det er i hvert fald et ret solidt produkt som er tilgængeligt på flere platforme. Hvilke andre produkter derude kan løfte opgaven?

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Krogh Andersen

Der findes flere open source MQ projekter, som er enterprise grade, og som ikke koster en formue, og en gigantisk IBM server, for at komme i gang.
RabbitMQ er en af dem.

Øvrige jeg kan huske:
ActiveMQ
HornetQ
Fuse Message Broker (ActiveMQ baseret afair)

  • 0
  • 0
Svenne Krap

Jeg er blevet stærkt betaget af ZeroMQ (http://www.zeromq.org/), der udmærker sig ved at være brokerless. Desværre har jeg ikke rigtigt har noget projekt her på de sidste der var oplagt til kø-brug, så jeg venter stadig på at få praktiske erfaringer med det...

Systemet er efter sigende udviklet til finanskvarteret i London....

  • 0
  • 0
Claus Nielsen

RabbitMQ fungerer fint og vi anvender det som grundlag for et 23x6 handelssystem der håndterer værdier til 500 mia DKK. Fra et administrator perspektiv har RabbitMQ det problem at produktet udvikler sig meget hurtigt og hver måned bringer en ny version. Det er ikke alle versioner som er lige stabile så vi skal bruge en del tid på at teste og lave life-cycle management. Tilgengæld elsker udviklerne RabbitMQ :-)

Jeg har også tilbragt et par år med IBM MQ og her er situationen modsat.
Produktet udvikler sig langsomt, er meget stabilt men både udviklerne og administratorne hader det hvis ikke de har en baggrund i mainframeverdenen.

Til et nyt projekt uden bindinger til allerede anskaffet infrastructur vil jeg aldrig anbefale IBM MQ

  • 0
  • 0
Peter Nørregaard Blogger

Jeg har skimmet ZeroMQ og det lader til at være relativt low-level og min bekymring er, at der skal en del til at få en fiks og færdig service med de krævede kvaliteter ud af det. Er du enig i det, Svenne?

Praktiske erfaringer, høj modning og ikke mindst stærk support 24/7 er et krav til kø-teknologi, der er brug for her.

  • 0
  • 0
Peter Nørregaard Blogger

Det lyder godt og prisen er ikke afskrækkende selvom løbende afregning jo løber op ved intensiv brug 24/7 over 3-5 år. Jeg har dog tre reservationer med Amazon SQS:

1) Et ekstra hosting-led i kæden: Aftalemæssigt skal det være klokkeklart hvem, der har ansvaret for at beskeder når frem til kø-modtageren i tide og der skal være et incitament for at holde service-niveauet oppe, gerne med bod. Med en 3.part i ligningen bliver det sværere at placere ansvaret præcist.

2) Service-level. Amazon giver ingen garantier på service-levels, herunder svartider, tilgængelighed eller afhjælpning. En god tommelfinger-regel er i øvrigt, at der skal være et ligeværdigt forhold mellem leverandør og kunde - her er Amazon alt for stor og alt for uforpligtet. Et nedbrud på fx et døgn på en infrastruktur-komponent er uacceptabel og indkøberen af løsningen betaler gerne en præmie for en garanti for service-level, men det tilbyder Amazon ikke.

3) Polling! Datavarehuset skal polle efter nye beskeder, da det ikke bliver notificeret automatisk. Så kunne vi næsten lige så godt bruge webservices direkte mod produktionssystemerne. En overførselstid på under ét sekund bliver svært når man skal polle en 3.parts service.

Amazon SQS er god når man i forvejen er på EC2, men som ren back-end til back-end integration mellem systemer som ikke bor i EC2 synes jeg der er nogle issues.

  • 0
  • 0
Peter Nørregaard Blogger

@Claus, stabilitet er naturligvis vigtig - specielt hvis to (eller flere) aftaleparter skal opdatere versioner samtidigt før at de kan tale sammen. Men det kan man vel organisere sig ud af ved at køre på en ældre, men stabil release (det er jo ikke rocket-science, vi er ude efter, men driftsikker performance)

Er din implementering af RabbitMQ en intern kø-infrastruktur eller går den også på tværs af systemer/hosting-miljøer/parter (og dermed også kontrakter...)?

  • 0
  • 0
Morten Wegelbye Nissen

Jeg har selv introduceret redis[1] for at løse en ligende opgave.

Egentligt en udspringer af NoSQL bevægelsen. Bemærk dog at redis garantere kun konsistens hvis den kun bliver afsluttet gracefull (Hvilket i mine øjne gælder for alle database produkter) - man her har man valgt det som en del af arkitekturen, performance at sat højt.

Redis giver også en del andre features for distribueret set af data osv. For mig blev det en kærligheds historie.

DISCLAIMER: Har ikke selv set efter kommercielt support.

[1] http://redis.io/

  • 0
  • 0
Svenne Krap

Som jeg skrev, så har jeg ikke haft noget rigtigt projekt hvor en god kø skal bruges siden jeg opdagede zmq - så jeg har kun et par håndfulde timers "leg" med det som praktisk erfaring... Jeg vil dog sige, at det imponerer mig nok til at det indgår i overvejelserne til mere end et fremtidigt projekt, der pt. er i støbeskeerne.

Jeg vil give dig ret i, at det er relativt low-level.

Hvis du kigger på deres site, er der et punkt, der hedder paid support (en af dem er firmaet bag zmq- som er bosat i Belgien hvis jeg husker rigtigt). Prøv evt. at kontakte dem (eller se nogle af de mange videoer).

Det er min opfattelse at zmq bliver brugt i særdeles mission-critical løsninger (dog uden at jeg har direkte kendskab).

  • 0
  • 0
Per Steffensen

Yes FUSE MB er bare ActiveMQ med support og hurtig løsning/release af bugs - derefter gives ændringerne tilbage til OpenSource AMQ. Har selv erfaring med det. Det virker og har nogle ok fede features - bl.a. fuldt integreret med Camel til routing etc.

  • 0
  • 0
Jon Carlsen

nServicebus er gået fra opensource til købe produkt, men er rigtigt stærkt til MSMQ. De kigger også på at understøtte andre kø'er som MQ.

Men det er produkt der er værd at kigge på for at lave afkoblet system. Det er dog blevet meget stort produkt og efterhånden også dyrt i forhold til det var opensource.

nServicebus giver muligheden for at bruge MSMQ til afkoble din arkitektur til et distribueret system og er efter min mening meget stærkt i .net verden

  • 0
  • 0
Log ind eller Opret konto for at kommentere