Cum pot crea o instanță a fluxului de lucru în mod fiabil pe baza unui eveniment extern?

un pic nou pentru lucrurile fluxului de lucru Windows așa merge ușor :)

Doresc să proiectez un mediu gazdă de flux de lucru care să aibă o disponibilitate ridicată - un minim de 2 host-uri runtime WF pe hardware separat, care să indice aceeași persistență sau aceeași bază de date SQL.

Caut un model prin care să pot crea în mod asincron o nouă instanță a fluxului de lucru bazată pe un anumit eveniment extern (adică o anumită piesă de date este actualizată în DB printr-o aplicație diferită). Pentru fiecare eveniment trebuie să creez exact o instanță de flux de lucru și nu contează ce gazdă este creată instanța. Există, de asemenea, o anumită flexibilitate în ceea ce privește durata de timp dintre eveniment și momentul în care instanța fluxului de lucru este creată efectiv.

O soluție pe care o iau este să aveți o interfață WCF pe gazdele WF și să le plasați în spatele unui balancer de sarcină. Ar fi atunci la orice parte a sistemului care arde "evenimentul" să facă apelul WCF.

Nu sunt foarte mulțumit de acest lucru, deoarece dacă ambele \ toate gazdele WF sunt în jos sau altfel indisponibile, evenimentul ar putea fi "pierdut". De asemenea, nu voi fi capabil să gestionez sarcina așa cum aș vrea. Mă gândesc la o situație în care ar putea exista o mulțime de evenimente într-o perioadă mică de timp, dar este perfect acceptabil să se ocupe de acele evenimente ceva mai târziu.

Așadar, cred că trebuie să persistăm evenimentele într-un fel și să decuplam crearea evenimentului de la manipularea evenimentului.

Este plasarea acestor evenimente în MSMQ sau un tabel de eveniment simplu în SQL Server și având gazdă WF doar sondaj coadă de așteptare periodic o soluție viabilă? Polling pare să fie un cuvânt atât de murdar deși ...

Ar fi util NServiceBus și mesageria durabilă aici?

Orice intuiție ar fi mult apreciată.

Act adițional

Baza de date va fi grupată cu spațiu de stocare a canalelor de fibre partajate. De asemenea, rețeaua va fi redundantă. Pentru ca instanțele runtime WF să nu aibă succes, trebuie să indice un serviciu comun de persistență, care în acest caz este un backend SQL. Disponibilitatea ridicată, nu Total Availabilty :)

Articol MSDN despre fiabilitatea și disponibilitatea ridicată a WF

De asemenea, fiecare instanță a runtime-ului WF trebuie să ruleze exact aceleași biți, astfel încât actualizarea va necesita scoaterea acestora în același timp. Îmi place ideea de a putea face acest lucru, dacă este necesar, fără a scoate întregul sistem.

0
fr hi bn

2 răspunsuri

M-aș duce cu masă MSMQ/eveniment. Pollingul este murdar numai dacă faceți greșit.

Un lucru pe care să-l aveți în vedere: spuneți că doriți ca mai multe servere WF să aibă o disponibilitate ridicată, dar ambele utilizează același backend SQL ? Disponibilitatea ridicată funcționează numai dacă eliminați toate punctele unice de eșec, nu doar câteva dintre ele.

0
adăugat

Dacă utilizați un serviciu WCF cu un netMsmqBinding, puteți primi mesaje în coadă fără a fi nevoie să faceți o sondaj. Mesajele vor aștepta dacă nu rulează niciun serviciu pentru a le ridica. Ați dori să vă asigurați că utilizați o coadă de coadă pentru fiabilitate în cazul în care mașina principală de așteptare coboară.

De asemenea, aveți grijă atunci când actualizați că nu puteți resuscita instanțe dintr-o versiune veche a serviciului. Deci, pentru a actualiza fluxurile de lucru pe termen lung, trebuie să le opriți să primească noi cereri și să aștepte până când toate instanțele sunt terminate înainte de a schimba biții sau vechile instanțe vor fi blocate în magazinul de persistență pentru totdeauna.

0
adăugat