![Dønn robuste batch-systemer ,[object Object]](https://image.slidesharecdn.com/javazone2010-4-100913053236-phpapp02/85/donn-robuste-batchsystemer-JavaZone2010-1-320.jpg)
![Dønn robuste batch-systemer ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Semelhante a dønn robuste batchsystemer (JavaZone2010)
Semelhante a dønn robuste batchsystemer (JavaZone2010) (6)
dønn robuste batchsystemer (JavaZone2010)
- 3. Det finnes ikke dønn robuste systemer
- 10. Noe failover greier.. s.
- 11. Apache-Camel s.
- 12. Camel DSL in 1 slide s.
- 16. Disclaimer: Alt herfra og ut vil inneholde feil Ikke stol på at koden min gjør det jeg sier. Test!
- 18. Polling consumer
- 20. Comepting consumer med move/rename på filsystem
- 24. Feilhåndtering og transaksjoner for «hele» jobben
- 27. Behandlingsstatus og optimistisk låsing (versionering)
- 32. DEMO?
Notas do Editor
- Jeg legger i dette at systemet skal tåle strømstans, utilsiktede feil fra kunde, feil i data, brann, bombe... Listen går så langt du vil. Du skal plassere deg et sted på aksen fra strømstans til atombombe. Hvor mye er du villig til å investere i infrastruktur, den arkitekturen jeg legger opp til skal ikke begrense deg, men utnytte infrastrukturen du har.
- Jeg har begrenset dette til batch systemer, mest fordi det er det jeg jobber mest med, og her jeg har hentet eksempelet og eksempelkoden fra, men jeg tror det meste jeg snakket om gjelder systemer generellt! Batch processing is execution of a series of programs (" jobs ") on a computer without manual intervention. Også kalt en workflow. Systemet tar typisk et sett av data filer som input, prosesserer data, og produserer et set av output data. Dette Typisk oppsamling av ”batcher” av jobber som kjører asynkront på tid. Dette i motsetning til ”online” eller interaktive systemer. Dette blir kalt batch prosessering fordi input data er samlet i batcher på filer og prosessert som batcher av programmene.
- Jeg har tenkte å lage et lite batch system i løpet av presentasjonen, og har delt opp i 10 stort sett konkrete steg eller råd, som blir beskrevet, og så implementert i java. Vi har kun en veldig kort overordnet beskrivelse av systemet vi skal lage: vi skal lage et nytt bbs banksystem som skal oppdatere alle banker med kvitteringer. Det er sånn at det er flere datasentraler som sender inn betalingsbestillinger til bbs, som så vi utfører. Dette systemet skal rett og slett rapportere til bankene hva som betales. Vårt system kommer til å få filer med betalingstransaksjomer fra flere systemer på bbs via scp til en katalog på delt filserver. 3 ganger i døgnet skal vi sortere inkomne transaksjoner pr bank og sende de i filer til denne banken. Dette er overordnet de funksjonelle kravene, men som dere kanskje skjønner er fokuset her ikke de funksjonelle, men de ikkefunksjonelle kravene som dreier seg om robusthet.
- Vi skisser raskt opp en tenkt overordnet arkitektur for dette systemet..
- Til dette tenkte systemet har vi noen veldig strenge ikke-funksjonelle krav. La oss tenke oss at dette er et av de mest kritiske systemene i norge!
- Det virker som vi trenger noe failover på applikasjon, disk og database i det minste... Det vil i enkleste forstand si backup av alle data på to noder, og mulighet til å skifte til backup node. Så kan man legge mer automatikk ettersom man trenger, men vær ops på at det medfører kompleksitet. Jeg ønsker å kunne skalere opp og ned infrastrukturen etter behov. Dvs at applikasjonen skal kunne kjøre også på en lokal maskin uten failover, for eksempel for funksjonell testing.
- integration framework - open source - Lettvekts Hvorfor Camel? Utrolig god syntax for ruting, perfekt for å illustrere mine eksempler. Kort, konsis og lesbar kode. Du kan velge å implementere komponenter selv og kun bruke ruting språket. Core components fungerer veldig bra. Vær forsiktig med ikke-core components Camel er ikke en ESB Er camel svaret? Rammeverk som camel virker veldig bra.... .... nesten.. Problemet er som med alle andre rammeverk i denne kategorien er at man bruker så mye tid og krefter på det lille som ikke fungerer, samt at man mister litt kontroll på hva som skjer, så: Jeg tror ikke du bør bruke det
- Hvis dere har lest sammendraget i programmet så dere at jeg skal benytte camel for å illustrere poengene i denne presentasjonen. Jeg må understreke at vi ikke kjører camel i produksjon på BBS, men det er historiske grunner til det. Jeg har valgt camel her fordi det ikke påvirker de 10 prinsippene mine, men understøtter disse godt, og camel har en god DSL som gjør eksemplene svært lesbare og forståelige for dere. Jeg har utvidet camel med noen egne komponenter for å gjøre det helt likt måten vi har gjort det på i produksjonssystemer i BBS.
- Ikke checked exceptions, kast alle exceptions helt ut og catch alle på et sted – der du har transaksjonsgrensen. Men ikke glem å catch dem helt da!