Commit 0bfb2b8a authored by Jens Ehlers's avatar Jens Ehlers
Browse files

Added microservices chapter

parent 2f51509a
Pipeline #8866 passed with stage
in 1 minute and 19 seconds
<p>Der Begriff Microservice-Architektur ist in den letzten Jahren entstanden, um eine Entwurfsmethode für Anwendungen zu beschreiben, bei der die Anwendung aus mehreren, wiederverwendbaren, kleinteiligen Services, den <i>Microservices</i>, zusammengesetzt wird. Zur Verbreitung des Begriffs hat maßgeblich die folgende Definition von James Lewis und Martin Fowler beigetragen <a href="#cite-Fow19">[Fow19]</a>.</p>
<div class="cite"><a href="https://martinfowler.com/microservices/">"In short, the microservice architectural style is an approach to developing a single application as a <b>suite of small services</b>, each <b>running in its own process</b> and communicating with lightweight mechanisms, often an HTTP resource API. These services are <b>built around business capabilities</b> and <b>independently deployable</b> by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies." (James Lewis & Martin Fowler, 2014)</a></div>
<h4>Single-Responsibility-Prinzip eines Microservice</h4>
<p>Ein Microservice hat nur eine einzige fachliche Aufgabe, die er aber besonders gut beherrscht. Daher hat ein Microservice eine hohe Kohärenz und ändert sich nur dann, wenn seine fachliche Aufgabe inhaltlich angepasst werden muss. Die Reduktion auf eine klar abgegrenzte Aufgabe bringt nach <a href="#cite-Tak17">[Tak17]</a> weitere Vorteile mit sich:
<ul>
<li>Der Service ist einfach zu entwickeln, da die zu erfüllenden Anforderungen bekannt und abgegrenzt sind.</li>
<li>Der Service ist einfach zu benutzen, da seine API so überschaubar ist, dass sie jeder versteht. Die Bereitschaft den Service an verschiedenen Stellen wiederzuverwenden steigt.</li>
<li>Der Service ist einfach zu testen. Durch eine gute, automatisierte Testabdeckung wird die Qualität erhöht, und das Vertrauen der Anwender kann weiter gesteigert werden.</li>
<li>Der Service ist in Kombination mit einer Umgebung zur Containervirtualisierung einfach zu betreiben.</li>
</ul>
</p>
<h4>Vorteile einer Microservice-Architektur</h4>
<ul>
<li><b>Skalierbarkeit:</b> Bei einer Microservice-Architektur können einzelne Services gezielt skaliert werden. Dies erhöht die Ressourceneffizienz und reduziert ggf. die Kosten. Die folgende Abbildung skizziert links eine Anwendung, die aus 5 unterschiedlichen Microservices aufgebaut ist. Aufgrund der hohen Anzahl an Zugriffen von außen wird die Last auf 4 Server verteilt. Da die Microservices unterschiedlich häufig angefragt werden, unterscheidet sich auch die Anzahl ihrer replizierten Instanzen im verteilten System. Jeder Microservice läuft in einem eigenen Prozess/Container. Als Alternative ist rechts in der Abbildung eine monolitischen Architektur dargestellt, bei der zur Lastverteilung nur die gesamte Anwendung repliziert werden kann.</li>
<img src="media/architecture_microservices.png" style="width:800px">
<label>Microservice-Architektur vs. monolithische Architektur</label>
<li><b>Zuverlässigkeit:</b> Wenn ein Service in einer Microservice-Architektur ausfällt, ist die restliche Anwendung weiterhin lauffähig. Durch einen geschickten Entwurf der Kommunikationsbeziehungen (asynchron oder kurze Timeouts) kann die Widerstandsfähigkeit gegen Fehler in Teilen der Anwendung erhöht werden.</li>
<li><b>Vereinfachtes Deployment:</b> Ein in der Praxis verbreitetes Problem bei einer monolithischen Architektur ist das ganzheitliche Deployment, da die Anwendung nur als Ganzes gebaut, getestet und in einem Release veröffentlicht werden kann. Es haben sich daher elaborate Prozesse in der Qualitätssicherung und Versionskontrolle etabliert, um sicherzustellen, dass nur die richtigen Commits in ein Release einfließen. Da jeder Microservice unabhängig von anderen Microservices bereitgestellt werden kann, reduziert sich die Komplexität in der Release-Planung. Änderungen können grundsätzlich schneller veröffentlicht werden.</li>
<li><b>Technische Heterogenität und Innovation:</b> Eine Microservice-Architektur ermöglicht die sukzessive Einführung neuer Technologien (z.B. Programmiersprachen, Frameworks, Datenbanken), da die einzelnen Services diesbezüglich unabhängig voneinander sind. Eine innovative, noch risikobehaftete Technologie kann in einem weniger kritischen Service evaluiert werden. Es bleibt allerdings aus pragmatischen Gründen der organisatorischen Zusammenarbeit und Konsistenz zu empfehlen, möglichst dieselben oder mind. ähnliche Technologien für die Services einzusetzen.</li>
</ul>
<h4>Nachteile einer Microservice-Architektur</h4>
<ul>
<li><b>Latenz:</b> Durch die Dekomposition einer Anwendung in dediziert bereitgestellte Microservices ergibt sich deutlich mehr lokaler Netzwerkverkehr (i.d.R. mittels HTTP) innerhalb des verteilten Systems. Dadurch kann sich die Antwortzeit des Systems verschlechtern, wodurch ggf. ein negativer Einfluss auf die <a href="https://de.wikipedia.org/wiki/User_Experience"><i>User Experience</i></a> entsteht.</li>
<li><b>Anfälligkeit bei Netzwerkfehlern:</b> Ein funktionierendes, lokales Netzwerk ist Voraussetzung für eine Microservice-Architektur. Anders als bei einer monolithischen Architektur haben Störungen im Netzwerk erheblichen Einfluss auf die Funktion der Anwendung.</li>
<li><b>Referenzielle Integrität:</b> Dadurch dass ein Microservice nicht nur Teile der Anwendungslogik kapselt, sondern auch Teile des Datenmodells persistent speichert, können Mechanismen zur Einhaltung der referentiellen Integrität nicht wie in einem ganzheitlichen Datenbankschema genutzt werden. Es muss akzeptiert werden, dass Daten z.T. redundant von mehreren Services gespeichert werden. Die Implementierung von Transaktionen, die sich über mehrere Services erstrecken, ist aufwändig. Strikte Konsistenz wird häufig zu <a href="https://en.wikipedia.org/wiki/Eventual_consistency"><i>Eventual Consistency</i></a> abgeschwächt.</li>
<li><b>Paradigmenwechsel:</b> Es verringert sich durch eine Microservice-Architektur zwar die Komplexität der Integrationsphase vor einem Release, dafür erhöht sich aber die Komplexität in der Entwurfsphase, wenn schon frühzeitig die Komposition diverser Microservices zu einer später tatsächlich funktionierenden Anwendung durchdacht werden muss. Während des Betriebs müssen viele Services verwaltet werden, deren Aktualisierung, Ausfall, Neustart und Replikation überwacht werden muss. Der Architekturstil beinhaltet keine grundsätzliche Empfehlung, wie die Gesamtfunktionalität einer komplexen Anwendung in einzelne fachliche Aufgaben für die Microservices zu unterteilen ist. Entscheidend ist hierfür die Analyse und das Verständnis der fachlichen Domäne in einem strukturierten Prozess, z.B. mittels <a href="https://de.wikipedia.org/wiki/Domain-driven_Design"> domänengetriebenem Entwurf (engl. <i>Domain-Driven Design</i>)</a>. Derartige Ansätze sind für viele Projektleiter und Entwickler weiterhin neu und gewöhnungsbedürftig.</li>
</ul>
<h4>Conway's Law</h4>
<p>Im domänengetriebenen Entwurf werden die Microservices (bzw. ihre fachlichen Aufgaben) häufig nach Abteilungsgrenzen innerhalb der Organisation des Auftraggebers geschnitten. Für jeden Microservice entsteht dann ein kleines, crossfunktionales Team, das für die Entwicklung und den Betrieb des Microservice zuständig ist. Innerhalb eines Teams gibt es diverse unterschiedliche Kompetenzen, z.B. Fachexperten mit Domänenwissen, UI-Designer, Software-Entwickler, Administratoren. Microservice-Projekte richten also die Organisation nach der geplanten Architektur aus. Dahinter verbirgt sich die Wiederentdeckung von <i>Conway's Law</i> aus dem Jahr 1968, demzufolge eine Organisation nur ein System entwerfen kann, das ihren inhärenten Kommunikationsstrukturen entspricht.</p>
<div class="cite"><a href="http://www.melconway.com/Home/Conways_Law.html">"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." (Mel Conway, 1968)</a></div>
<p>Die Neuausrichtung der Organisation soll also sicherstellen, dass die Zielarchitektur wirklich eingehalten wird. Ein crossfunktionales Team soll möglichst autark und parallel zu anderen Teams arbeiten können. Die folgende Abbildung verdeutlicht, den Bezug zwischen den organisatorischen Teams und der erreichten Architektur.</p>
<img src="media/architecture_conways_law_microservices.png" style="width:800px">
<label>Conway's Law: Crossfunktionale Teams führen zu einer domänengetriebenen Architektur (Microservices).</label>
<p>Im Gegensatz dazu zeigt die nächste Abbildung die technisch-orientierte Einteilung von Teams, in der Mitarbeiter mit gleichen Kompetenzen innerhalb einer Gruppe oder eines Teams angesiedelt sind – z.B. (vereinfacht) Fachabteilung, Entwicklung, Betrieb. Entsprechend Conway's Law entsteht eine Architektur, deren Schnittstellen sich durch die organisatorischen Teamgrenzen ergeben. Kleinste Änderungen eines Services betreffen jeweils alle Teams, deren Absprache untereinander in der Praxis häufig nicht effizient ist, wodurch der Entwicklungsprozess sehr träge werden kann.</p>
<img src="media/architecture_conways_law_layers.png" style="width:800px">
<label>Conway's Law: Technisch-orientierte Teams führen i.d.R. zu einer technischen Schichtenarchitektur.</label>
\ No newline at end of file
......@@ -261,7 +261,7 @@
<li><a class="dropdown-item" id="unit-tiers">Schichtenarchitektur</a></li>
<li><a class="dropdown-item" id="unit-mvc">Model-View-Controller</a></li>
<li><a class="dropdown-item" id="unit-mvc-mvvm-javafx">MVC und MVVM in JavaFX</a></li>
<!-- <li><a class="dropdown-item" id="unit-microservices">Microservices</a></li> -->
<li><a class="dropdown-item" id="unit-microservices">Microservices</a></li>
</ul>
</li>
<li class="nav-item dropdown">
......@@ -371,9 +371,9 @@
<div class="unit-part" id="architecture-mvc-mvvm-javafx"></div>
</div>
<!-- <div id="content-unit-microservices">
<div id="content-unit-microservices">
<div class="unit-part" id="architecture-microservices"></div>
</div> -->
</div>
<div id="content-unit-distributed-communication">
<div class="unit-part" id="distributed-communication"></div>
......
......@@ -28,6 +28,7 @@ Die Studierenden lernen bewährte Entwurfs- und Architekturmuster sowie aktuelle
<li><a id="cite-Blo17">[Blo17] Joshua Bloch: Effective Java, Addison-Wesley, 3. Aufl., 2017.</a></li>
<li><a id="cite-Fow02">[Fow02] Martin Fowler: Patterns of Enterprise Application Architecture, Addison-Wesley, 2002.</a></li>
<li><a id="cite-Fow04">[Fow04] Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern, https://martinfowler.com/articles/injection.html, 2004.</a></li>
<li><a id="cite-Fow19">[Fow19] Martin Fowler: Microservices Guide, https://martinfowler.com/microservices/, 2019.</a></li>
<li><a id="cite-FRS+15">[FRS+15] Eric Freeman, Elisabeth Robson, Kathy Sierra, Bert Bates: Entwurfsmuster von Kopf bis Fuß, O'Reilly, 2. Aufl. 2015.</a></li>
<li><a id="cite-Gei15">[Gei15] Matthias Geirhos: Entwurfsmuster - Das umfassende Handbuch, Rheinwerk Computing, 2015.</a></li>
<li><a id="cite-GHJ+10">[GHJ+10] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster - Elemente wiederverwendbarer objektorientierter Software, Addison-Wesley, 6. Aufl., 2010.</a></li>
......@@ -45,6 +46,7 @@ Die Studierenden lernen bewährte Entwurfs- und Architekturmuster sowie aktuelle
<li><a id="cite-RQ12">[RQ12] Chris Rupp, Stefan Queins: UML 2 glasklar - Praxiswissen für die UML-Modellierung, Hanser, 4. Auflage, 2012.</a></li>
<li><a id="cite-SGM02">[SGM02] Clemens Szyperski, Dominik Gruntz, Stephan Murer: Component Software - Beyond Object-Oriented Programming, Addison Wesley, 2nd ed., 2002.</a></li>
<li><a id="cite-Spi19">[Spi19] Kai Spichale: API-Design: Praxishandbuch für Java- und Webservice-Entwickler, dpunkt, 2. Aufl., 2019.</a></li>
<li><a id="cite-SW01">[SW01] Connie Smith, Lloyd Williams: Performance Solutions - A Practical Guide to Creating Responsive, Scalable Software, Addison-Wesley, 2001.</a></li>
<li><a id="cite-SW01">[SW01] Connie Smith, Lloyd Williams: Performance Solutions - A Practical Guide to Creating Responsive, Scalable Software, Addison-Wesley, 2001.</a></li>
<li><a id="cite-Tak17">[Tak17] Daniel Takai: Architektur für Websysteme - Serviceorientierte Architektur, Microservices, Domänengetriebener Entwurf, Hanser, 2017.</a></li>
<li><a id="cite-TvS16">[TvS16] Andrew Tanenbaum, Maarten van Steen: Distributed Systems - Principles and Paradigms, CreateSpace, 2nd ed., 2016.</a></li>
</ul>
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment