14-mal heruntergeladen
micro services
- 1. Micro-Services Thomas Krille undSebastian Mancke
- 2. Warum sind monolithischeSysteme ‘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. Monolithen entstehen durchschlechtes 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. • Design derfachlichen Anwendung in unabhängigen Säulen • Vertikale Teams (End-to-End) • Maximale Reduktion von Abhängigkeiten Vertikal denken!
- 5.
- 6.
- 7. The micro serviceway ... GUI Service DB GUI Service DB GUI Service DB GUI Service DB
- 8. Small with asingle 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. Located in differentVCS 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.
- 11. Keine App-Server • Servicebringt 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. Exklusive Datenbank • Sonstkeine 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. Alles erlaubt • Ambesten: 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. 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. 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. Continous Deployment • Deployment-Pipeline Allesautomatisieren! • 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. Docker • LXC basierteVirtualisierungslö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.
- 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. Problem: Security-Context über100 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. • Inventarisierung vielerServices • 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.
- 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. Spring Boot -Maven
- 25. Spring Boot -Java
- 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. Vert.x - WebApp
- 28.
- 29. Einfaches, schlankes JavaMicro 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.