Micro-Services
Thomas Krille und Sebastian Mancke
Warum sind monolithische Systeme ‘evil’?
Wegen ihrer Abhängigkeiten!
Warum sind Abhängigkeiten ‘evil’?
• Software ist schw...
Monolithen entstehen durch schlechtes Design und den falschen
Umgang mit Abhängigkeiten.
Unabhängig von der Technologie:
•...
• Design der fachlichen Anwendung in
unabhängigen Säulen
• Vertikale Teams (End-to-End)
• Maximale Reduktion von Abhängigk...
Klassische Herangehensweise
GUI -Layer
Services
Database/Persistance
SOA Herangehensweise
GUI -Layer
Business
Service
DB
Business
Service
Business
Service
Persistence
Service
DB
Persistence
S...
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 servi...
Located in different VCS roots
• Each application is completelty seperate
• Domain Driven Design / Conway’s law
– Domains ...
Kleine Dienste
Keine App-Server
• Service bringt Environment mit
Wenig Code
• “Wegwerf-Services”
• Refactoring = neu Schreiben
Der richti...
Exklusive Datenbank
• Sonst keine lose Kopplung!
• Kann Duplizierung von Daten verursachen
Source Code Management
• 1 Repo...
Alles erlaubt
• Am besten: wenige Standards im gesamtem System
Lose Kopplung
• Services sollten nicht viel voneinander wis...
Asynchronous Messaging
• Leichtgewichtig: ØMQ, RabbitMQ
• High Performance: Apache Kafka, Vert.x Event Bus
Resilience
• To...
Unit-Tests
• Integrationstests ausreichend, weil Service sehr klein
• Micro Service selbst ist Unit under Test
• In Isolat...
Continous Deployment
• Deployment-Pipeline
Alles automatisieren!
• 1 Monolith leicht manuell deploybar, 100 Micro Services...
Docker
• LXC basierte Virtualisierungslösung
• Ähnlich chroot (aber viel besser)
• Schlank und schnell
• Inhalte mit Git v...
Deployment
Komponententests
Entwicklungs/
Testsystem
Produktivsystem
Integrationstests
Dev-
Repo
Control-Center
- Deployme...
Echtzeit-Metriken
• Wichtig ist, was jetzt passiert
• Auf Fehler schnell und automatisch reagieren
• Tools: Coda Hale Metr...
Problem: Security-Context über 100 Services
• Security ist auch ein Service
Lösung: IAMs
• Zentrale Verwaltung von Identit...
• Inventarisierung vieler Services
• Hohe Anforderungen an Deployment-Prozess
• Hohe Anforderungen an Operations
• Netzwer...
Frameworks und Tooling
Spring als Standalone-App
• Inhalt: Servlet Container, “Starter” POMs, Tooling
Ergebnis: Fat-Jar mit main-Methode
• java-j...
Spring Boot - Maven
Spring Boot - Java
Asynchrones Netzwerk-Framework
• Non-blocking, event-driven, actor-like
Polyglott
• Java, JavaScript, Groovy, Clojure, Pyt...
Vert.x - Web App
Vert.x - Event Bus
Einfaches, schlankes Java Micro Service Framework
Integration von
• Jetty
• Jackson/Jersey
• Metrics
• Hibernate
• Liquiba...
http://martinfowler.com/articles/microservices.html
https://speakerdeck.com/timmo/micro-services-die-verheissungen-
konnte...
Upcoming SlideShare
Loading in …5
×

micro services

4,067 views

Published on

Micro Service Architektur

Published in: Software
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,067
On SlideShare
0
From Embeds
0
Number of Embeds
2,483
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

micro services

  1. 1. Micro-Services Thomas Krille und Sebastian Mancke
  2. 2. 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! Monolithische Software
  3. 3. 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
  4. 4. • Design der fachlichen Anwendung in unabhängigen Säulen • Vertikale Teams (End-to-End) • Maximale Reduktion von Abhängigkeiten Vertikal denken!
  5. 5. Klassische Herangehensweise GUI -Layer Services Database/Persistance
  6. 6. SOA Herangehensweise GUI -Layer Business Service DB Business Service Business Service Persistence Service DB Persistence Service DB Persistence Service DB Persistence Service DB Persistence Service
  7. 7. The micro service way ... GUI Service DB GUI Service DB GUI Service DB GUI Service DB
  8. 8. 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:
  9. 9. 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 Micro-Service-Prinzipien nach James Lewis:
  10. 10. Kleine Dienste
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. Deployment Komponententests Entwicklungs/ Testsystem Produktivsystem Integrationstests Dev- Repo Control-Center - Deployment Steuerung - Monitoring - Analytics Prod- Repo
  19. 19. 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
  20. 20. 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
  21. 21. • 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
  22. 22. Frameworks und Tooling
  23. 23. 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
  24. 24. Spring Boot - Maven
  25. 25. Spring Boot - Java
  26. 26. 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
  27. 27. Vert.x - Web App
  28. 28. Vert.x - Event Bus
  29. 29. 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 Dropwizard
  30. 30. 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

×