Upload
smancke
View
1.853
Download
0
Embed Size (px)
DESCRIPTION
Micro Service Architektur
Citation preview
Micro-ServicesThomas Krille und Sebastian Mancke
Warum sind monolithische Systeme ‘evil’?
Wegen ihrer Abhängigkeiten!
Warum sind Abhängigkeiten ‘evil’?
• Software ist schwer zu testen!
• Auswirkungen von Änderungen lassen sich nicht sicher begrenzen!
• Arbeiten mit mehreren Teams ist schwierig!
• Systeme lassen sich nicht unabhängig skalieren!
• Individuelle Deploymentzyklen für Features sind aufwändig!
• Unabhängige Skalierung ist nicht möglich!
• Wiederverwendung von fachlichen Teilen ist unmöglich!
• Systemumbauten sind sehr aufwändig!
Monolithische Software
Monolithen entstehen durch schlechtes Design und den falschen Umgang mit Abhängigkeiten.
Unabhängig von der Technologie:
• Auch mit Micro Service Frameworks lassen sich Monolithen bauen.
• Auch verteilte Systeme können zu einem Monolithen werden.
• Auch große Systeme mit einem einzelnen .ear können eine interne
gute Architektur haben (filigran und zerlegbar).
Monolithen vermeiden
• Design der fachlichen Anwendung in unabhängigen Säulen
• Vertikale Teams (End-to-End)
• Maximale Reduktion von Abhängigkeiten
Vertikal denken!
Klassische Herangehensweise
GUI -Layer
Services
Database/Persistance
SOA Herangehensweise
GUI -Layer
BusinessService
DB
Business Service
BusinessService
Persistence Service
DB
Persistence Service
DB
Persistence Service
DB
Persistence Service
DB
Persistence Service
The micro service way ...
GUI
Service
DB
GUI
Service
DB
GUI
Service
DB
GUI
Service
DB
Small with a single responsibility
• Each application only does one thing
• Small enough to fit in your head
– “If a service is bigger than your head, than it is too big”
• Small enough that you can throw them away
– Rewrite or Maintain
Micro-Service-Prinzipien
nach James Lewis:
Located in different VCS roots
• Each application is completelty seperate
• Domain Driven Design / Conway’s law
– Domains in different bounded contexts shoud be distinct - and it is ok
to have duplication
– Use physical separation to enforce this
• There will be common code, but it should be library and
infrastructure code
– Treat it as you would any other open source library
– Stick it in a nexus repo somewhere and treat it as a binary
dependency
• Small enough to fit in your head
– “If a service is bigger than your head, than it is too big”
• Small enough that you can throw them away
– Rewrite or Maintain
Micro-Service-Prinzipien
nach James Lewis:
Kleine Dienste
Keine App-Server• Service bringt Environment mit
Wenig Code• “Wegwerf-Services”
• Refactoring = neu Schreiben
Der richtige Stack für die Anforderung• 1 Monolith -> 1 Stack, 100 Micro Services -> 100 Stacks
• Freie Wahl: OS, Sprache, Framework, Datenbank
Implementierung
Exklusive Datenbank• Sonst keine lose Kopplung!
• Kann Duplizierung von Daten verursachen
Source Code Management• 1 Repo für jeden Service
Neues Feature, neuer Service• Erst prüfen, ob es eine neue fachliche Säule ist
• Dann erst vorhandenen Service erweitern
Implementierung
Alles erlaubt• Am besten: wenige Standards im gesamtem System
Lose Kopplung• Services sollten nicht viel voneinander wissen
• Am besten: auch nichts über deren Existenz
Smart Endpoints, Dumb Pipes• Kommunikationskanal hat keine Intelligenz
• Kein ESB (Verstoß gegen Micro-Services-Prinzipien)
Bevorzugt: Web-Standards• REST, kein SOAP
Kommunikation
Asynchronous Messaging• Leichtgewichtig: ØMQ, RabbitMQ
• High Performance: Apache Kafka, Vert.x Event Bus
Resilience• Toleranz gegenüber Ausfällen, Wiederherstellung nach Fehlern
• Fehlerkaskaden vermeiden
• Testen!
• Tools: Hystrix, JRugged, Netflix Simian Army
API-Versionierung vermeiden• Schafft mehr Probleme als es löst
• Besser: tolerant bei Annahme von Daten, konservativ beim Senden
Kommunikation
Unit-Tests• Integrationstests ausreichend, weil Service sehr klein
• Micro Service selbst ist Unit under Test
• In Isolation: Abhängigkeiten (andere Services) mocken
Consumer Driven Tests• Gut: Service definiert Tests, die API verifizieren
• Besser: API-Konsumenten definieren Tests des Services
• Tests gegen erwartete API, nicht nur behauptete
Testen
Continous Deployment• Deployment-Pipeline
Alles automatisieren!• 1 Monolith leicht manuell deploybar, 100 Micro Services nicht
Paketierung• Auf etablierte Standards setzen
• Init Skripte!
• Tools: DEB, RPM, ...
Installation• Tools: Puppet, Chef, etc.
Deployment
Docker• LXC basierte Virtualisierungslösung
• Ähnlich chroot (aber viel besser)
• Schlank und schnell
• Inhalte mit Git versioniert -> Änderungen an ‘VMs’ über git
Gilliam• Management Plattform für Micro Services
• Basiert auf docker
• Vereinfacht Deklaration und Management
• Portverwaltung, Api-Mapping
• Deklarative Skalierung
Deployment als Plattformen
1 Linux-System <-> 1 Micro Service
Deployment
Komponententests
Entwicklungs/Testsystem
Produktivsystem
Integrationstests
Dev-Repo
Control-Center- Deployment Steuerung- Monitoring- Analytics
Prod-Repo
Echtzeit-Metriken• Wichtig ist, was jetzt passiert
• Auf Fehler schnell und automatisch reagieren
• Tools: Coda Hale Metrics, Spring Boot Actuator
Logging• Logs von 100 Services manuell durchforsten nicht möglich
• Logging zentral aggregieren
• Filterung, Echtzeit-Auswertung möglich
• Historie sichtbar, Trends erkennbar
• Tools: Logstash, Apache Flume, fluentd
Visualisierung
Monitoring
Problem: Security-Context über 100 Services• Security ist auch ein Service
Lösung: IAMs• Zentrale Verwaltung von Identitäten und Berechtigungen
• Credentials: Tokens, Assertions,
• OAuth, SAML
• OSIAM, Shibboleth
Security
• Inventarisierung vieler Services
• Hohe Anforderungen an Deployment-Prozess
• Hohe Anforderungen an Operations
• Netzwerklast
• Neue Art zu Denken und zu entwickeln
• Freiheit der Technologiewahl darf nicht zu Wildwuchs führen
Risiken und Probleme
Frameworks und Tooling
Spring als Standalone-App• Inhalt: Servlet Container, “Starter” POMs, Tooling
Ergebnis: Fat-Jar mit main-Methode• java-jar my-spring-boot-app.jar
Automatische Konfiguration• Dependency hinzufügen reicht
Production-ready Services• Actuator: Metriken, Healthchecks, Security Auditing
• Abfrage: JMX, REST, CRaSH
Spring Boot
Spring Boot - Maven
Spring Boot - Java
Asynchrones Netzwerk-Framework• Non-blocking, event-driven, actor-like
Polyglott• Java, JavaScript, Groovy, Clojure, Python, Ruby, Scala, …
Modular• Module für alles
• Apps sind auch Module
(Verteilter) Event-Bus• Kommunikation aller Verticles nur darüber
• Bis in Browser hinein
Vert.x
Vert.x - Web App
Vert.x - Event Bus
Einfaches, schlankes Java Micro Service Framework
Integration von
• Jetty
• Jackson/Jersey
• Metrics
• Hibernate
• Liquibase
Haupt Features
• Single-jar deplyoment
• Einfache Konfiguration
• REST Support
• Health Checks
• SSL out of the box
• Absicherung von Ressourcen
Vortrag von Martin Ley am 12.05.
Dropwizard
http://martinfowler.com/articles/microservices.html
https://speakerdeck.com/timmo/micro-services-die-verheissungen-konnten-eintreten
http://oredev.org/2013/wed-fri-conference/implementing-micro-service-architectures
http://www.infoq.com/presentations/Micro-Services
http://projects.spring.io/spring-boot/
http://vertx.io/
https://dropwizard.github.io
http://gilliam.github.io/
Referenzen