Your SlideShare is downloading. ×
dønn robuste batchsystemer (JavaZone2010)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

dønn robuste batchsystemer (JavaZone2010)

490
views

Published on

Talk from javaZone 2010

Talk from javaZone 2010


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
490
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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!
  • Transcript

    • 1. Dønn robuste batch-systemer
      • Bjørn Nordlund
    • 2. Dønn robuste batch-systemer
      • Bjørn Nordlund
    • 3. Det finnes ikke dønn robuste systemer
    • 4. Bjørn Nordlund
      • ”My main goal with programming and system development is to make things simpler and more managable”
      s.
    • 5. Hva er robust(het)
      • Wikipedia definisjon av robusthet:
      • Robustness is the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance. A system, organism or design may be said to be "robust" if it is capable of coping well with variations (sometimes unpredictable variations) in its operating environment with minimal damage, alteration or loss of functionality.
      s.
    • 6. Batch systemer s.
    • 7. eksempelsystem
      • Banken vil ha rapporter om alle sine transaksjoner for avstemming med det de tror de har sendt.
      • Vårt batchsystem skal kunne:
      • Ta i mot filer med transaksjonsdata på et recordformat fra alle betalingssystemer
      • Lagre disse i database
      • På klokkeslett plukke ut data, grupper pr bank og lage filer som sendes til disse bankene
      s.
    • 8. System skisse s.
    • 9. Ytterlige krav
      • Ikke miste data
      • Ikke lese inn data dobbelt
      • Høy oppetid
      • Tåle å tryne
      s.
    • 10. Noe failover greier.. s.
    • 11. Apache-Camel s.
    • 12. Camel DSL in 1 slide s.
    • 13. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 14. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 15. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 16. Disclaimer: Alt herfra og ut vil inneholde feil Ikke stol på at koden min gjør det jeg sier. Test!
    • 17. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 18. Polling consumer
    • 19. Competing consumer
    • 20. Comepting consumer med move/rename på filsystem
    • 21. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 22.  
    • 23. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 24. Feilhåndtering og transaksjoner for «hele» jobben
    • 25. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 26. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 27. Behandlingsstatus og optimistisk låsing (versionering)
    • 28. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 29.  
    • 30. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 31. Let’s begin – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 32. DEMO?
    • 33. NICS- Norwegian Interbank Clearing System
      • Høy viktighet
        • Antall transaksjoner i 2009: 1 635 969 599
        • Beløp i 2009: 53 316 430 238 816
      • Høyt volum
        • antall transaksjoner inn skal også ut
        • onlinegrensesnitt for enkelt transaksjoner
      • Høy ytelse
        • Korte frister for mottak/formidling og oppgjør
        • 40 dager med historikk
      s.
    • 34. Oppsummering – Bjørns 10 steg:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 35. Hvis dere skal huske 2 ting:
      • Steg #1: Embedded
      • Steg #2: Teste
      • Steg #3: Lese
      • Steg #4: Persistent tilstand
      • Steg #5: Feile
      • Steg #6: Idempotens
      • Steg #7: Schedulere
      • Steg #8: Sende
      • Steg #9: Applikasjonskonsoll
      • Steg #10: Overvåke
      s.
    • 36. www.bbs.no
      • git clone git://github.com/bjornno/batchserver.git
      • Spørsmål?
      s.