27. marts 2012 - 14:42Der er
7 kommentarer og 1 løsning
WCF service - Placeret centralt og på slaver
Hej eksperter,
Jeg er igang med at skulle opbygge en helt ny serverstruktur, hvor jeg har følgende problemstilling:
Jeg har 8 servere i alt: - 1 central server (med database) - 7 slaver, der skal kunne udføre jobs
Tanken er, at central-serveren, skal kunne forespørge de 7 servere én efter én, for at finde ud af, om der i øjeblikket kører jobs på dem - Gør der det, forespørges den næste i rækken, indtil der er frit. Når der er en ledig plads, skal et specielt job kunne startes på serveren, hvor et givent ID definerer hvilket osv. Efter jobbet er fuldført, skal den pågældende slave svare tilbage til centralen og fortælle at jobbet er færdigt - Hvorefter det data som er hentet ind, kan processeres.
Det er meningen, at jeg skal bruge WCF til dette, for at holde det på et teknisk niveau, hvor det hele kan køre stabilt og jeg med tiden vil kunne tilføje/fjerne servere uden det store besvær.
Som det er lavet pt., så har jeg én applikation, hvor den pågældende applikation startes op, når serveren kører (slave eller central, pt. defineret i app.config). Det er meningen, at der skal være én WCF-service på alle serverne, som så er tilknyttet så de alle kan tilgå hinandens.
Mit spørgsmål er derfor, hvordan kan jeg bedst lave det sådan, at central-serveren for det første kan spørge på status, og få svar, og hvordan kan central-serveren "diktere" hvad der skal startes op, på en slave? Jeg formoder, at det må være noget med at subscribe på nogle events på WCF-servicen, men hvordan det lige kan lade sig gøre på den bedste måde, det ved jeg ikke.
Hvis I kan komme med nogle pinpointers, guides eller bare kommentarer, så er jeg mere end glad.
Hvad med at lave det sådan at slaven poller mainserver efter job istedet med et tidsinterval?
Så behøver du ikke lave en liste over slaveservere som skal itereres igennem på mainserveren.
På mainserveren laver du så en kø af jobs over hvad der skal startes op, du kan evt. bruge Sql Service Broker til det, så har du en styring og kan bare sætte jobs i kø som så afvikles i samme rækkefølge og såsnart der er en ledig slave.
Og udover det, hvordan får jeg så listen af jobs? Hvis jeg poller en service, skal den have listen af jobs fra serveren, dvs. databasen/applikationen. Det må umiddelbart stadigvæk kræve et kald fra servicen til applikationen.
Du skriver "Efter jobbet er fuldført, skal den pågældende slave svare tilbage til centralen og fortælle at jobbet er færdigt - Hvorefter det data som er hentet ind, kan processeres."
Dvs. når jobbet på slaven er færdig så kalder du en WCF på centralen med det pågældende data. Enten igennen WCF.
Listen af jobs findes jo på centralen, så slaven skal blot kalde til centralen "giv mig et job".
Det er del af et kæmpe system, som vi kører - Derfor skal det være én central som sender opgaverne ud, for at der ikke skal spørges på den konstant.
Umiddelbart, så er mit problem at se hvordan jeg kan subscribe på et event, som sker i servicen - Og dermed udføre det valgte job, på den pågældende slave.
Jeg har i mit tidligere job siddet i en lignende problemstilling, der havde vi nogle lokale sql-servere som modtog data fra den respektive "slave", "slaven" spurgte så på localsql og eksekverede herefter. Mainserveren kunne kommunikere med "slave-sql'erne" igennem linked servers. Måske det inspirerer lidt :)
At sende opgaverne ud kræver jo at centralserveren ved om slaverne arbejder, ik sandt? Så alligevel skal der polles(en efter en, skriver du selv) fra serveren og ud. Derfor er arkitekturen med at slaven spørger lidt bedre imho, når den kører spørger den jo ikke. Det er også risikabelt at forvente at slaven kan skrive en status til mainserveren om at den er klar, meget kan gå galt og du kan stå med 7 slaver som serveren opfatter som kørende men i virkeligheden holder stille.
Jeg synes selv arkitekturen med en kø (service broker) på mainserveren og så de 7 slaver som spørger, virker som det mest stabile og nemmeste at udvide. Hvad kan du ikke li ved det?
Hvis du vil bruge modellen med push fra central til slave, saa vil jeg mene at du skal: 1) koere job paa slaver asynkront (egen traad eller lignende) 2) have slave expose nogle web services: bool ReadyForNext() void StartNewWork(Data obj) som begge returnerer med det samme. 3) central maintainer liste over jobs 4) to muligheder for at maintaine liste med slaver a) hardcoded (hvis det sjaldent aendrer sig saa kan det vaere helt fint) b) client selv registrerer sig ved start via web service paa central og central fjerner dem ved fejl i kald under #2
Men jeg synes nu ogsaa at pull modellen lyder tiltraekkende.
1) central sender til en "out" message queue (hvis det ikke er SQLServer centric saa vil jeg ikke bruge service broker, men en standard message queue) 2) clients receiver fra den message queue 3) client koerer job 4) client sender done til "in" message queue 5) central receiver status fra den message queue
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
