Splitt og hersk: Fleksibel arkitektur med mikrotjenester!
1. Splitt og hersk: Fleksibel
arkitektur med mikrotjenester!
Henrik Schwarz – JavaZone 2014
1
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. 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. 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
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. Utviklingsmiljø
• Separat GIT-repository for hver tjeneste
• Maven Archetype plugin
• Egenutviklet Maven-plugin lager kjørbar
JAR-fil (embedder Jetty ved behov)
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
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. 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. 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. 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!
Konsulent i Bouvet og jobber som Java-utvikler og arkitekt.
<number>
<number>
Det tradisjonelle er en monolottisk arkitektur, kan være en spring-basert webapplikasjon.
Kan bli krevende å vedlikeholde:
vanskelig for nye utviklere å få oversikt over koden
krever valg av teknologistack ved starttidspunktet
<number>
Løst koblet: tjenester er kun avhengig av publisert kontrakt til andre tjenester.
Tjenesten er informasjonseier. Ikke lov å gå rett i basen!
<number>
<number>
<number>
<number>
<number>
<number>
<number>
<number>
<number>
HVIS DET ER SPØRSMÅL STÅR JEG PÅ BOUVET STANDEN ETTERPÅ!!
<number>