micro services

download micro services

of 30

  • date post

    07-Nov-2014
  • Category

    Software

  • view

    1.842
  • download

    0

Embed Size (px)

description

Micro Service Architektur

Transcript of micro services

  • 1. Micro-Services Thomas Krille und Sebastian Mancke
  • 2. Warum sind monolithische Systeme evil? Wegen ihrer Abhngigkeiten! Warum sind Abhngigkeiten evil? Software ist schwer zu testen! Auswirkungen von nderungen lassen sich nicht sicher begrenzen! Arbeiten mit mehreren Teams ist schwierig! Systeme lassen sich nicht unabhngig skalieren! Individuelle Deploymentzyklen fr Features sind aufwndig! Unabhngige Skalierung ist nicht mglich! Wiederverwendung von fachlichen Teilen ist unmglich! Monolithische Software
  • 3. Monolithen entstehen durch schlechtes Design und den falschen Umgang mit Abhngigkeiten. Unabhngig von der Technologie: Auch mit Micro Service Frameworks lassen sich Monolithen bauen. Auch verteilte Systeme knnen zu einem Monolithen werden. Auch groe Systeme mit einem einzelnen .ear knnen eine interne gute Architektur haben (filigran und zerlegbar). Monolithen vermeiden
  • 4. Design der fachlichen Anwendung in unabhngigen Sulen Vertikale Teams (End-to-End) Maximale Reduktion von Abhngigkeiten Vertikal denken!
  • 5. Klassische Herangehensweise GUI -Layer Services Database/Persistance
  • 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. The micro service way ... GUI Service DB GUI Service DB GUI Service DB GUI Service DB
  • 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. Located in different VCS roots Each application is completelty seperate Domain Driven Design / Conways 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. Kleine Dienste
  • 11. Keine App-Server Service bringt Environment mit Wenig Code Wegwerf-Services Refactoring = neu Schreiben Der richtige Stack fr die Anforderung 1 Monolith -> 1 Stack, 100 Micro Services -> 100 Stacks Freie Wahl: OS, Sprache, Framework, Datenbank Implementierung
  • 12. Exklusive Datenbank Sonst keine lose Kopplung! Kann Duplizierung von Daten verursachen Source Code Management 1 Repo fr jeden Service Neues Feature, neuer Service Erst prfen, ob es eine neue fachliche Sule ist Dann erst vorhandenen Service erweitern Implementierung
  • 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. Asynchronous Messaging Leichtgewichtig: MQ, RabbitMQ High Performance: Apache Kafka, Vert.x Event Bus Resilience Toleranz gegenber Ausfllen, Wiederherstellung nach Fehlern Fehlerkaskaden vermeiden Testen! Tools: Hystrix, JRugged, Netflix Simian Army API-Versionierung vermeiden Schafft mehr Probleme als es lst 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: Abhngigkeiten (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 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. Docker LXC basierte Virtualisierungslsung hnlich chroot (aber viel besser) Schlank und schnell Inhalte mit Git versioniert -> nderungen an VMs ber git Gilliam Management Plattform fr Micro Services Basiert auf docker Vereinfacht Deklaration und Management Portverwaltung, Api-Mapping Deklarative Skalierung Deployment als Plattformen 1 Linux-System 1 Micro Service
  • 18. Deployment Komponententests Entwicklungs/ Testsystem Produktivsystem Integrationstests Dev- Repo Control-Center - Deployment Steuerung - Monitoring - Analytics Prod- Repo
  • 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 mglich Logging zentral aggregieren Filterung, Echtzeit-Auswertung mglich Historie sichtbar, Trends erkennbar Tools: Logstash, Apache Flume, fluentd Visualisierung Monitoring
  • 20. Problem: Security-Context ber 100 Services Security ist auch ein Service Lsung: IAMs Zentrale Verwaltung von Identitten und Berechtigungen Credentials: Tokens, Assertions, OAuth, SAML OSIAM, Shibboleth Security
  • 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 fhren Risiken und Probleme
  • 22. Frameworks und Tooling
  • 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 hinzufgen 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 fr alles Apps sind auch Module (Verteilter) Event-Bus Kommunikation aller Verticles nur darber Bis in Browser hinein Vert.x
  • 27. Vert.x - Web App
  • 28. Vert.x - Event Bus
  • 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. 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