Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Splitt og hersk: Fleksibel 
arkitektur med mikrotjenester! 
Henrik Schwarz – JavaZone 2014 
1
Om prosjektet 
• Prosjekt hos FLO/IKT: Modernisering av 
kjernetjenester 
– Informasjonsutveksling: SOA-infrastruktur 
– R...
Monolittisk arkitektur 
• Bygget og deployert som en enkelt 
enhet 
• Kjører i en enkelt prosess 
• Den minste endring kre...
Mikrotjeneste-arkitektur 
• Filosofi hentet fra UNIX: small & simple 
• Dele opp en løsning i små fokuserte tjenester 
• D...
Kommunikasjon mellom tjenester
Unngå kjede av synkrone kall 
oppdatere status 
Tjeneste A Tjeneste B 
hente status 
Tjeneste A Tjeneste B 
operasjon x 
o...
Utviklingsmiljø 
• Separat GIT-repository for hver tjeneste 
• Maven Archetype plugin 
• Egenutviklet Maven-plugin lager k...
Kjøremiljø og deployment 
• Standalone Java-applikasjoner (JAR) 
• Kjøres som services i Windows 
• Virtualisert miljø - V...
Hva skal man velge?
Fordeler 
• Kan velge mest egnet teknologi / persistens 
for den enkelte tjeneste 
• Små moduler gjør det lettere å få ove...
Utfordringer 
• Ingen Silver Bullet! 
• Høyere initiell kostnad 
• Ekstra kostnad for hver tjeneste 
• Distribuert system ...
Erfaringer og tips 
• Gjør det lett å lage nye tjenester! 
• Ikke del opp for mye 
• Fokus på fornuftig oppdeling i tjenes...
Konklusjon 
• Å dele opp et stort system kan være lurt! 
• Gir fleksibel arkitektur, men alt har sin pris 
• Tydelig buzz ...
Fortsett dialogen! 
@bouvet 
Facebook.com/bouvet Utbrudd.bouvet.no
Prochain SlideShare
Chargement dans…5
×

Splitt og hersk: Fleksibel arkitektur med mikrotjenester!

478 vues

Publié le

Lightning talk about micro service architecture presented on JavaZone 2014 in Oslo.

Publié dans : Logiciels
  • Soyez le premier à commenter

Splitt og hersk: Fleksibel arkitektur med mikrotjenester!

  1. 1. Splitt og hersk: Fleksibel arkitektur med mikrotjenester! Henrik Schwarz – JavaZone 2014 1
  2. 2. Om prosjektet • Prosjekt hos FLO/IKT: Modernisering av kjernetjenester – Informasjonsutveksling: SOA-infrastruktur – Registertjenester: Enterprisekatalog • Utviklet flere graderte løsninger basert på mikrotjeneste-arkitektur
  3. 3. Monolittisk arkitektur • Bygget og deployert som en enkelt enhet • Kjører i en enkelt prosess • Den minste endring krever bygg og deploy av hele applikasjonen • Enkelt å komme i gang, men kan bli krevende å vedlikeholde • Skalering krever duplisering av hele applikasjonen Applikasjon Database
  4. 4. Mikrotjeneste-arkitektur • Filosofi hentet fra UNIX: small & simple • Dele opp en løsning i små fokuserte tjenester • Deployeres som selvstendige prosesser • Kommuniserer over standard protokoll • Tjenester er løst koblet Tjeneste Tjeneste Tjeneste Tjeneste
  5. 5. Kommunikasjon mellom tjenester
  6. 6. Unngå kjede av synkrone kall oppdatere status Tjeneste A Tjeneste B hente status Tjeneste A Tjeneste B operasjon x operasjon x Push Pull 6 • ”Pull” er anbefalt over ”push” • Eventual consistency
  7. 7. Utviklingsmiljø • Separat GIT-repository for hver tjeneste • Maven Archetype plugin • Egenutviklet Maven-plugin lager kjørbar JAR-fil (embedder Jetty ved behov)
  8. 8. Kjøremiljø og deployment • Standalone Java-applikasjoner (JAR) • Kjøres som services i Windows • Virtualisert miljø - VMWare • Automatisert installasjon og deployment med Powershell-script
  9. 9. Hva skal man velge?
  10. 10. Fordeler • Kan velge mest egnet teknologi / persistens for den enkelte tjeneste • Små moduler gjør det lettere å få oversikt • Kan redeployere deler av systemet • Effektiv måte å skalere deler av systemet på • Lettere å skalere utviklingsteam
  11. 11. Utfordringer • Ingen Silver Bullet! • Høyere initiell kostnad • Ekstra kostnad for hver tjeneste • Distribuert system innfører kompleksitet • Vanskelig å finne riktig oppdeling i starten • Refaktorering på tvers av tjenester • Versjonering av tjenester • Følge tråden på tvers av tjenester • Kan koste mer å drifte
  12. 12. Erfaringer og tips • Gjør det lett å lage nye tjenester! • Ikke del opp for mye • Fokus på fornuftig oppdeling i tjenester og kvalitet på grensesnitt • Automatiser mest mulig (infrastruktur, deployment) • Sentralisert logging og overvåkning er viktig • Distribuerte transaksjoner skalerer ikke!
  13. 13. Konklusjon • Å dele opp et stort system kan være lurt! • Gir fleksibel arkitektur, men alt har sin pris • Tydelig buzz i markedet, vær skeptisk! • Krever prosjekter av en viss størrelse • Gode erfaringer så langt fra Forsvaret, men for tidlig med endelig konklusjon!
  14. 14. Fortsett dialogen! @bouvet Facebook.com/bouvet Utbrudd.bouvet.no

×