Microservices - Do one thing well
0 gefällt mir378 aufrufe
Microservices sind kleine, autonome Dienste, die unabhängig voneinander funktionsfähig sind und ein hohes Maß an Modularität bieten. Sie haben sowohl Vor- als auch Nachteile, einschließlich höherer Komplexität und der Notwendigkeit robuster Überwachungsstrategien, während sie gleichzeitig die Skalierbarkeit und Flexibilität fördern. Der Übergang von monolithischen Architekturen zu Microservices erfordert eine sorgfältige Planung und Integration, einschließlich der Berücksichtigung von Datenbanken, Transaktionsmanagement und Kommunikationsprotokollen.
Microservices - Do one thing well
- 1. Microservices Do one thing well
- 2. Übersicht Was sind µServices? Nachteile / Vorteile Definitionen Voraussetzungen Integration Aufteilen des Monolithen + Datenbank Wie anfangen? Beispiel Zusammenfassung Quellen
- 3. Was sind µServices? Kleine, autonome Services (Dienste), die zusammen arbeiten. Do one thing well
- 4. Wie klein ist „klein“? Single Responsibility Principle nach Robert C. Martin „Gather together those things, that change together for the same reason.“ „small enough, but not smaller“
- 5. Autonom Selbständig deploybar Kann der Service deployed werden, ohne etwas anderes ändern zu müssen? Decoupling Auch auf Teamebene!
- 6. Nachteile Viele deploybare Einheiten Hohe Modularisierung erforderlich Latenzen Können ausfallen - Murphy’s Law Größere Infrastruktur
- 7. Vorteile Unabhängige Technologien verwenden (MySQL, ElasticSearch, Java, PHP,…) Fehler kaskadieren nicht Hochskalierbar Leichtes Deployment einzelner Einheiten Composability - Zusammensetzbar Austauschbar Entwicklung einzelner Komponenten
- 8. Voraussetzungen für µServices Struktur des Unternehmens lässt es zu Team ist verantwortlich für den µService Entwicklung neuer Features dauert, im Moment, lange Monitoring/Logging You build it, you run it, you panic Conway’s Law
- 10. Integration Orchestration Choreography Service 1 Service 2 Service 3 Service 4 Service 1 Event„Befehl“ „Befehl“ „Befehl“ Service 2 Service 3 Service 4 Veröffentlicht Subscribes Subscribes Subscribes
- 11. Integration Orchestration Choreography God-Classes Vorteile Nachteile Mehraufwand Monitoring Tracking Einfacher zu implementieren Weniger Abhängigkeiten Flexibler mehrere CRUD-Classes
- 12. Integration Synchron Asynchron Einfacher Wissen: erfolgreich? Blockiert Long running jobs Blockiert nicht annehmen, es hat funktioniert Request/Response Event-based
- 13. Integration - Request/Response RPC - gRPC REST HATEOAS gRPC Remote Procedure Calls, of course!
- 14. Integration - Event Based Message Queues RabbitMQ HTTP (ATOM)
- 15. Integration - Zusatz Service as State Machines Reactive Extensions Observables Semantic Versioning Koexistierende Endpoint-Versionen Migration zu neuen Endpunkten
- 16. Zusatz Immer davon ausgehen, dass der Service nicht funktioniert „Be conservative in what you do, be liberal in what you accept.“ Postel’s Law API Gateway Kein wildes Service->Service
- 17. Anfang Neue Features als µService SharedDB beibehalten Bounded contexts finden Stück-für-Stück in µServices auslagern Abhängigkeiten aufheben - Decoupling Business capabilities?
- 18. Aufteilen des Monolithen Abhängigkeiten erkennen modularisieren Jedes Modul (jeder bounded Context) Ein µService
- 20. Datenbank?
- 21. Datenbank Monolithischer Service Service Code 1 Service Code 2 monolithische Datenbank Monolithischer Service Service Code 1 Service Code 2 Datenbank Service 1 Datenbank Service 2
- 22. Service 1 Service 2 Datenbank Service 1 Datenbank Service 2 Foreign Keys? Weglassen - in den Services managen Transactions?
- 23. Transactions Transactional boundaries - pro Service Distributed transactions —> Transaction Manager Compensating transactions wenn eine fehlschlägt (Queue) Eventual consistency Transactions nicht aufteilen, wenn wirklich nötig
- 25. Schwer, den richtigen Service zu finden (viele!) Beispiel - Uber Wenn gefunden: wie ansprechen? REST? RPC? standardisierter Weg Services zu definieren IDL - Apache Thrift Strikte Regeln -> „Vertrag“ Interfaces ändern sich nicht plötzlich - Fehler auf Thrift-Ebene Interface definition language
- 26. Zusammenfassung No silver bullet Anfangs mehr Aufwand nötig Größere Infrastruktur Schnelleres Deployment Mehr Fehlerquellen Keine Abhängigkeiten
- 27. Quellen Building Microservices - Sam Newman http://microservices.io/ Zalando - https://www.youtube.com/watch?v=I9zpROdDf48 https://dzone.com/articles/microservices-in-practice-1 https://eng.uber.com/building-tincup/ Das Beispiel - https://eng.uber.com/soa/