Produktionsfähige Microservices

Kapitel 4. Skalierbarkeit und Leistung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Ein produktionsreifer Microservice ist skalierbar und performant. Ein skalierbarer, performanter Microservice ist ein Microservice, der auf Effizienz ausgerichtet ist, der nicht nur eine große Anzahl von Aufgaben oder Anfragen gleichzeitig bewältigen kann, sondern diese auch effizient bearbeitet und darauf vorbereitet ist, dass die Aufgaben oder Anfragen in Zukunft zunehmen. In diesem Kapitel werden die wesentlichen Komponenten der Skalierbarkeit und Leistung von Microservices behandelt. Dazu gehören das Verständnis der qualitativen und quantitativen Wachstumsskalen, die Hardware-Effizienz, die Identifizierung von Ressourcenanforderungen und Engpässen, das Kapazitätsbewusstsein und die Kapazitätsplanung, die skalierbare Abwicklung des Datenverkehrs, die Skalierung von Abhängigkeiten, die Aufgabenbearbeitung und -verarbeitung sowie die skalierbare Speicherung von Daten.

Grundsätze der Skalierbarkeit und Leistung von Microservices

Effizienz ist in der realen Welt der verteilten Großsysteme von größter Bedeutung, und Microservice-Ökosysteme bilden hier keine Ausnahme. Die Effizienz eines einzelnen Systems (z. B. einer monolithischen Anwendung) lässt sich leicht quantifizieren, aber die Bewertung der Effizienz und das Erreichen einer höheren Effizienz in einem großen Ökosystem von Microservices, in dem die Aufgaben auf Hunderte (wenn nicht Tausende) von kleinen Services verteilt sind, ist unglaublich schwierig. Auch die Gesetze der Computerarchitektur und verteilter Systeme setzen der Effizienz großer, komplexer verteilter Systeme Grenzen: Je verteilter dein System ist und je mehr Microservices du in diesem System einsetzt, desto weniger Einfluss hat die Effizienz eines einzelnen Microservices auf das gesamte System. Die Standardisierung von Prinzipien, die die Gesamteffizienz erhöhen, wird zu einer Notwendigkeit. Zwei unserer Standards für die Produktionsreife - Skalierbarkeit und Leistung - helfendabei, diese Gesamteffizienz zu erreichen und die Verfügbarkeit des Microservice-Ökosystems zu erhöhen.

Skalierbarkeit und Leistung sind eng miteinander verknüpft, da sie sich auf die Effizienz der einzelnen Microservices und des gesamten Ökosystems auswirken. Wie wir in Kapitel 1, Microservices, gesehen haben, müssen wir, um eine skalierbare Anwendung zu erstellen, für Gleichzeitigkeit und Partitionierung sorgen: Die Gleichzeitigkeit ermöglicht es, jede Aufgabe in kleinere Teile aufzuteilen, während die Partitionierung entscheidend dafür ist, dass diese kleineren Teile parallel verarbeitet werden können. Während die Skalierbarkeit also damit zusammenhängt, wie wir die Bearbeitung von Aufgaben aufteilen und bewältigen, ist die Leistung das Maß dafür, wie effizient die Anwendung diese Aufgaben bearbeitet.

In einem wachsenden, florierenden Microservice-Ökosystem, in dem der Datenverkehr stetig zunimmt, muss jeder Microservice in der Lage sein, mit dem gesamten System zu skalieren, ohne unter Leistungsproblemen zu leiden. Um sicherzustellen, dass unsere Microservices skalierbar und leistungsfähig sind, müssen wir von jedem Microservice mehrere Dinge verlangen. Wir müssen sein Wachstum verstehen, sowohl quantitativ als auch qualitativ, damit wir uns auf das erwartete Wachstum vorbereiten können. Wir müssen unsere Hardwareressourcen effizient nutzen, uns über Ressourcenengpässe und -anforderungen im Klaren sein und eine angemessene Kapazitätsplanung vornehmen. Wir müssen sicherstellen, dass die Abhängigkeiten eines Microservices mit ihm skalieren. Wir müssen den Datenverkehr auf skalierbare und performante Weise verwalten. Wir müssen Aufgaben auf eine performante Weise bearbeiten und verarbeiten. Und nicht zuletzt müssen wir die Daten skalierbar speichern.

Ein produktionsfähiger Dienst ist skalierbar und leistungsfähig

• Seine qualitativen und quantitativen Wachstumsskalen sind bekannt.

• Es nutzt die Hardware-Ressourcen effizient.

• Die Ressourcenengpässe und -anforderungen wurden ermittelt.

• Die Kapazitätsplanung ist automatisiert und wird nach einem festen Zeitplan durchgeführt.

• Seine Abhängigkeiten werden mit ihm skalieren.

• Es wird mit seinen Kunden mitwachsen.

• Seine Verkehrsmuster sind bekannt.

• Der Verkehr kann im Falle von Ausfällen umgeleitet werden.

• Sie ist in einer Programmiersprache geschrieben, die es ermöglicht, skalierbar und performant zu sein.

• Es bearbeitet und verarbeitet Aufgaben auf performante Weise.

• Es verarbeitet und speichert Daten auf eine skalierbare und performante Weise.

Die Wachstumsskala kennen

Zu wissen, wie ein Microservice skaliert (auf einer sehr hohen Ebene), ist der erste Schritt, um zu verstehen, wie man einen skalierbaren Microservice aufbaut und wartet. Es gibt zwei Aspekte bei der Bestimmung der Wachstumsskala eines Microservices, die beide eine wichtige Rolle für das Verständnis und die Planung der Skalierbarkeit eines Dienstes spielen. Der erste ist die qualitative Wachstumsskala, die sich aus dem Verständnis ergibt, wo der Service in das gesamte Microservice-Ökosystem passt und von welchen wichtigen Geschäftskennzahlen er betroffen sein wird. Die zweite ist die quantitative Wachstumsskala, die, wie der Name schon sagt, ein genau definiertes, messbares und quantitatives Verständnis davon vermittelt, wie viel Verkehr ein Microservice bewältigen kann.

Die Qualitative Wachstumsskala

Die natürliche Tendenz bei dem Versuch, die Wachstumsskala eines Microservices zu bestimmen, besteht darin, die Wachstumsskala in Form von Anfragen pro Sekunde (RPS) oder Abfragen pro Sekunde (QPS) zu formulieren, die der Service unterstützen kann, und dann vorherzusagen, wie viele RPS/QPS in Zukunft an den Service gestellt werden. Der Begriff "Anfragen pro Sekunde" wird in der Regel verwendet, wenn es um Microservices geht, und "Abfragen pro Sekunde", wenn es um Datenbanken oder Microservices geht, die Daten an Kunden zurückgeben, obwohl sie in vielen Fällen austauschbar sind. Das sind sehr wichtige Informationen, aber sie sind ohne zusätzlichen Kontext nutzlos - insbesondere ohne den Kontext, in den der Microservice im Gesamtbild passt.

In den meisten Fällen werden die Informationen über die RPS/QPS, die ein Microservice unterstützen kann, durch den Zustand des Microservices zum Zeitpunkt der ursprünglichen Berechnung der Wachstumsskala bestimmt: Wenn die Wachstumsskala nur anhand des aktuellen Verkehrsaufkommens und der Art und Weise, wie der Microservice mit der aktuellen Verkehrslast umgeht, berechnet wird, besteht die Gefahr, dass Rückschlüsse auf das zukünftige Verkehrsaufkommen, das der Microservice bewältigen kann, fehlgeleitet sind. Es gibt verschiedene Ansätze, um dieses Problem zu umgehen, z. B. Lasttests (Testen des Microservice mit höheren Verkehrslasten), die ein genaueres Bild der Skalierbarkeit des Dienstes vermitteln, und die Analyse historischer Verkehrsdaten, um zu sehen, wie das Verkehrsaufkommen im Laufe der Zeit wächst. Aber hier fehlt etwas sehr Wichtiges, das eine inhärente Eigenschaft der Microservice-Architektur ist: Microservices leben nicht allein, sondern sind Teil eines größeren Ökosystems.

An dieser Stelle kommt die qualitative Wachstumsskala ins Spiel. Qualitative Wachstumsskalen ermöglichen es, die Skalierbarkeit eines Dienstes mit übergeordneten Geschäftskennzahlen zu verknüpfen: Ein Microservice kann zum Beispiel mit der Anzahl der Nutzer/innen, mit der Anzahl der Personen, die eine Telefonanwendung öffnen ("eyeballs"), oder mit der Anzahl der Bestellungen (bei einem Essenslieferdienst) skalieren. Diese Messgrößen, diese qualitativen Wachstumsskalen, sind nicht an einen einzelnen Microservice gebunden, sondern an das Gesamtsystem oder das/die Produkt(e). Auf Unternehmensebene hat das Unternehmen in den meisten Fällen eine Vorstellung davon, wie sich diese Kennzahlen im Laufe der Zeit verändern werden. Wenn diese übergeordneten Geschäftsmetriken an die Entwicklungsteams weitergegeben werden, können die Entwickler sie in Bezug auf ihre jeweiligen Microservices interpretieren: Wenn einer ihrer Microservices Teil des Bestellflusses für einen Essenslieferdienst ist, wissen sie, dass alle Metriken, die sich auf die Anzahl der in der Zukunft erwarteten Bestellungen beziehen, ihnen Aufschluss darüber geben, welche Art von Datenverkehr ihr Dienst erwarten sollte.

Wenn ich Microservice-Entwicklungsteams frage, ob sie die Wachstumsgröße ihres Dienstes kennen, lautet die übliche Antwort: "Er kann x Anfragen pro Sekunde verarbeiten." Meine Folgefragen zielen immer darauf ab, herauszufinden, wo der betreffende Dienst in das Gesamtprodukt passt: Wann werden die Anfragen gestellt? Ist es eine Anfrage pro Fahrt? Eine Anfrage jedes Mal, wenn jemand die App öffnet? Eine Anfrage jedes Mal, wenn sich ein neuer Nutzer für unser Produkt anmeldet? Wenn diese kontextabhängigen Fragen beantwortet sind, wird die Wachstumsskala klar - und nützlich. Wenn die Anzahl der Anfragen an den Dienst direkt mit der Anzahl der Personen verknüpft ist, die eine Telefonanwendung öffnen, dann skaliert der Dienst mit den Augäpfeln, und wir können die Skalierung des Dienstes planen, indem wir vorhersagen, wie viele Personen die Anwendung öffnen werden. Wenn die Anzahl der Anfragen an den Dienst von der Anzahl der Personen abhängt, die Essen bestellen, dann skaliert der Dienst mit den Lieferungen, und wir können die Skalierung unseres Dienstes planen und vorhersagen, indem wir übergeordnete Geschäftsmetriken verwenden, um zu ermitteln, wie viele zukünftige Lieferungen prognostiziert werden.

Es gibt Ausnahmen von den Regeln der qualitativen Wachstumsskalen, und die Bestimmung einer geeigneten qualitativen Wachstumsskala kann sehr kompliziert werden, je weiter unten im Stack sich der Dienst befindet. Interne Tools leiden in der Regel unter diesen Komplikationen, obwohl sie so geschäftskritisch sind, dass der Rest des Unternehmens schnell auf Skalierungsprobleme stößt, wenn sie nicht skalierbar sind. Es ist nicht einfach, die Wachstumsskala eines Dienstes wie einer Überwachungs- oder Alarmierungsplattform in Form von Geschäftskennzahlen (Nutzer, Augäpfel usw.) zu bestimmen. Daher müssen Plattform- und/oder Infrastrukturunternehmen genaue Wachstumsskalen für ihre Dienste in Bezug auf ihre Kunden (Entwickler, Dienste usw.) und die Spezifikationen ihrer Kunden festlegen. Interne Tools können z. B. mit der Anzahl der Einsätze, der Anzahl der Dienste, der Anzahl der aggregierten Logs oder der Gigabytes an Daten skalieren. Diese sind komplizierter, weil es schwierig ist, diese Zahlen vorherzusagen, aber sie müssen genauso einfach und vorhersehbar sein wie die Wachstumsskalen der Microservices weiter oben im Stack.

Die Quantitative Wachstumsskala

Der zweite Teil der Kenntnis der Wachstumsskala ist die Bestimmung ihrer quantitativen Aspekte, und hier kommen RPS/QPS und ähnliche Kennzahlen ins Spiel. Um die quantitative Wachstumsskala zu bestimmen, müssen wir unsere Microservices mit der qualitativen Wachstumsskala im Hinterkopf angehen: Die quantitative Wachstumsskala wird definiert, indem die qualitative Wachstumsskala in eine messbare Größe übersetzt wird. Wenn die qualitative Wachstumsskala unseres Microservices beispielsweise in "Augäpfeln" gemessen wird (z. B. wie viele Menschen eine Telefonanwendung öffnen) und jeder "Augapfel" zu zwei Anfragen an unseren Microservice und einer Datenbanktransaktion führt, dann wird unsere quantitative Wachstumsskala in Form von Anfragen und Transaktionen gemessen, was zu Anfragen pro Sekunde und Transaktionen pro Sekunde als den beiden Schlüsselgrößen für unsere Skalierbarkeit führt.

Es kann nicht genug betont werden, wie wichtig es ist, genaue qualitative und quantitative Wachstumsskalen zu wählen. Wie wir gleich sehen werden, wird die Wachstumsskala verwendet, um Vorhersagen über die Betriebskosten des Dienstes, den Hardwarebedarf und die Grenzen von zu machen.

Effiziente Nutzung von Ressourcen

Wenn über die Skalierbarkeit großer verteilter Systeme wie Microservice-Ökosysteme nachdenkt, ist eine der nützlichsten Abstraktionen, die wir machen können, die Eigenschaften unserer Hardware und Infrastruktursysteme als Ressourcen zu betrachten. CPU, Arbeitsspeicher, Datenspeicherung und das Netzwerk ähneln den Ressourcen in der natürlichen Welt: Sie sind endlich, sie sind physische Objekte in der realen Welt und sie müssen zwischen den verschiedenen Akteuren im Ökosystem verteilt und geteilt werden. Wie wir im Abschnitt "Organisatorische Herausforderungen" kurz erörtert haben , sind Hardwareressourcen teuer, wertvoll und manchmal rar, was zu einem harten Wettbewerb um Ressourcen innerhalb des Microservice-Ökosystems führt.

Die organisatorische Herausforderung der Ressourcenzuweisung und -verteilung kann gemildert werden, indem geschäftskritischen Microservices ein größerer Anteil der Ressourcen zugewiesen wird. Der Ressourcenbedarf kann priorisiert werden, indem die verschiedenen Microservices innerhalb des Ökosystems nach ihrer Bedeutung und ihrem Wert für das Gesamtunternehmen kategorisiert werden: Wenn die Ressourcen im gesamten Ökosystem knapp sind, können die geschäftskritischsten Services bei der Ressourcenzuweisung eine höhere Priorität erhalten.

Die technische Herausforderung der Ressourcenzuweisung und -verteilung birgt einige Schwierigkeiten, da viele Entscheidungen über die erste Schicht (die Hardwareschicht) des Microservice-Ökosystems getroffen werden müssen. Microservices können mit dedizierter Hardware ausgestattet werden, so dass auf jedem Host nur ein Service läuft, aber das kann ziemlich teuer sein und ist eine ineffiziente Nutzung der Hardware-Ressourcen. Viele Unternehmen entscheiden sich dafür, die Hardware auf mehrere Microservices aufzuteilen, so dass auf jedem Host mehrere verschiedene Dienste laufen - eine Praxis, die in den meisten Fällen eine effizientere Nutzung der Hardwareressourcen darstellt.

Die Gefahren von gemeinsam genutzten Hardware-Ressourcen

Obwohl der Betrieb vieler verschiedener Microservices auf einem Rechner (d.h. die gemeinsame Nutzung von Rechnern durch Microservices) in der Regel eine effizientere Nutzung der Hardwareressourcen darstellt, muss darauf geachtet werden, dass die Microservices ausreichend isoliert sind und die Leistung, Effizienz oder Verfügbarkeit ihrer benachbarten Microservices nicht beeinträchtigen. Die Containerisierung (mit Docker) und die Isolierung von Ressourcen können dazu beitragen, dass Microservices nicht durch schlecht funktionierende Nachbardienste beeinträchtigt werden.

Eine der effektivsten Möglichkeiten, Hardwareressourcen in einem Microservice-Ökosystem zuzuweisen und zu verteilen, ist die vollständige Abstraktion des Begriffs "Host" und seine Ersetzung durch Hardwareressourcen mithilfe von Ressourcenabstraktionstechnologien wie Apache Mesos. Auf dieser Ebene der Ressourcenabstraktion können Ressourcen dynamisch zugewiesen werden, wodurch viele der Fallstricke vermieden werden, die mit der Ressourcenzuweisung und -verteilung in großen verteilten Systemen wie Microservice-Ökosystemen verbunden sind.

Ressourcen-Bewusstsein

Bevor die Hardwareressourcen effizient zugewiesen und auf die Microservices innerhalb des Microservice-Ökosystems verteilt werden können, ist es wichtig, die Ressourcenanforderungen und Ressourcenengpässe der einzelnen Microservices zu ermitteln. Ressourcenanforderungen sind die spezifischen Ressourcen (CPU, RAM usw.), die jeder Microservice benötigt; diese zu ermitteln ist für den Betrieb eines skalierbaren Dienstes unerlässlich. Ressourcenengpässe sind die Grenzen der Skalierbarkeit und Leistung jedes einzelnen Microservices, die von den Eigenschaften seiner Ressourcen abhängen.

Ressourcenanforderungen

Die Ressourcenanforderungen eines Microservices sind die Hardware-Ressourcen, die der Microservice benötigt, um ordnungsgemäß zu laufen, Aufgaben effizient zu verarbeiten und vertikal und/oder horizontal skaliert werden zu können. Die beiden wichtigsten und relevantesten Hardware-Ressourcen sind - wenig überraschend - CPU und RAM (in Multithreading-Umgebungen werden Threads zur dritten wichtigen Ressource). Um den Ressourcenbedarf eines Microservices zu ermitteln, muss man also die CPU und den Arbeitsspeicher bestimmen, die eine Instanz des Dienstes benötigt, um zu laufen. Dies ist wichtig für die Abstraktion von Ressourcen, für die Ressourcenzuweisung und -verteilung sowie für die Bestimmung der allgemeinen Skalierbarkeit und Leistung des Microservices.

Identifizierung zusätzlicher Ressourcenanforderungen

Während CPU und RAM die beiden häufigsten Ressourcenanforderungen sind, ist es wichtig, auf andere Ressourcen zu achten, die ein Microservice innerhalb des Ökosystems benötigt. Das können Hardware-Ressourcen wie Datenbankverbindungen oder Ressourcen der Anwendungsplattform wie Logging-Quotas sein. Wenn du den Bedarf eines bestimmten Microservices kennst, kann das viel zur Verbesserung der Skalierbarkeit und Leistung beitragen.

Die Berechnung des spezifischen Ressourcenbedarfs eines Microservices kann ein kniffliger, langwieriger Prozess sein, weil es viele relevante Faktoren gibt. Der Schlüssel dazu ist, wie bereits erwähnt, die Anforderungen für eine einzige Instanz des Dienstes zu bestimmen. Die effektivste und effizienteste Art, unseren Dienst zu skalieren, ist die horizontale Skalierung: Wenn unser Datenverkehr zunimmt, wollen wir ein paar weitere Hosts hinzufügen und unseren Dienst auf diesen neuen Hosts bereitstellen. Um zu wissen, wie viele Hosts wir hinzufügen müssen, müssen wir wissen, wie unser Dienst auf einem einzigen Host läuft: Wie viel Datenverkehr kann er bewältigen? Wie viel CPU wird beansprucht? Wie viel Speicher? Diese Zahlen verraten uns genau, wie hoch der Ressourcenbedarf unseres Microservices ist.

Ressourcenengpässe

Wir können die Leistungs- und Skalierbarkeitseinschränkungen unserer Microservices durch die Identifizierung von Ressourcenengpässen aufdecken und quantifizieren. Ein Ressourcenengpass ist alles, was in der Art und Weise, wie der Microservice seine Ressourcen nutzt, die Skalierbarkeit der Anwendung einschränkt. Dabei kann es sich um einen Engpass in der Infrastruktur oder um etwas in der Architektur des Dienstes handeln, das seine Skalierbarkeit verhindert. So kann zum Beispiel die Anzahl der offenen Datenbankverbindungen, die ein Microservice benötigt, ein Engpass sein, wenn er sich dem Verbindungslimit der Datenbank nähert. Ein weiteres Beispiel für einen häufigen Ressourcenengpass ist, wenn Microservices vertikal skaliert werden müssen (und nicht horizontal, wenn mehr Instanzen/Hardware hinzugefügt werden), wenn der Datenverkehr zunimmt: Wenn die einzige Möglichkeit, einen Microservice zu skalieren, darin besteht, die Ressourcen jeder Instanz zu erhöhen (mehr CPU, mehr Speicher), werden die beiden Prinzipien der Skalierbarkeit (Gleichzeitigkeit und Partitionierung) aufgegeben.

Einige Ressourcenengpässe sind leicht zu erkennen. Wenn dein Microservice nur skaliert werden kann, indem du ihn auf Maschinen mit mehr CPU und Arbeitsspeicher bereitstellst, um dem wachsenden Datenverkehr gerecht zu werden, dann hast du einen Skalierbarkeitsengpass und musst den Microservice so umgestalten, dass er horizontal statt vertikal skaliert werden kann, wobei du Gleichzeitigkeit und Partitionierung als Leitprinzipien nutzt.

Die Fallstricke der vertikalen Skalierung

Vertikale Skalierung ist kein nachhaltiger oder skalierbarer Weg, um Microservices zu entwickeln. Sie mag in Situationen funktionieren, in denen jeder Microservice über eine eigene Hardware verfügt, aber sie funktioniert nicht gut mit den neuen Hardware-Abstraktions- und Isolationstechnologien, die heute in der Tech-Welt verwendet werden, wie Docker und Apache Mesos. Optimiere immer für Gleichzeitigkeit und Partitionierung, wenn du eine skalierbare Anwendung erstellen willst.

Andere Ressourcenengpässe sind nicht so offensichtlich, und der beste Weg, sie zu entdecken, sind ausführliche Lasttests für den Dienst. Wir werden die Lasttests im Abschnitt "Ausfallsicherheitstests" noch ausführlicher behandeln .

Kapazitätsplanung

Eine der wichtigsten Voraussetzungen für die Entwicklung eines skalierbaren Microservices ist die Sicherstellung des Zugangs zu den notwendigen und erforderlichen Hardwareressourcen, wenn er skaliert. Die effiziente Nutzung von Ressourcen, die Planung von Wachstum und das Design eines Microservices für perfekte Effizienz und Skalierbarkeit von Grund auf werden schnell nutzlos, wenn keine Hardwareressourcen zur Verfügung stehen, wenn der Microservice mehr Produktionsdatenverkehr verarbeiten muss. Diese Herausforderung stellt sich vor allem bei Microservices, die für horizontale Skalierbarkeit optimiert sind.

Zusätzlich zu den technischen Herausforderungen, die mit diesem potenziellen Problem einhergehen, sehen sich Engineering-Organisationen oft mit größeren organisatorischen und geschäftsrelevanten Problemen konfrontiert: Hardware-Ressourcen kosten viel Geld, Unternehmen und einzelne Entwicklungsteams müssen Budgets einhalten, und diese Budgets (zu denen in der Regel auch die Hardware gehört) müssen im Voraus eingeplant werden. Um sicherzustellen, dass Microservices bei steigendem Datenverkehr richtig skalieren können, können wir eine geplante Kapazitätsplanung durchführen. Die Prinzipien der Kapazitätsplanung sind ziemlich einfach: Bestimme den Hardwarebedarf jedes Microservices im Voraus, baue den Bedarf in das Budget ein und sorge dafür, dass die benötigte Hardware reserviert wird.

Um den Hardwarebedarf eines jeden Dienstes zu ermitteln, können wir die Wachstumsskalen (sowohl quantitativ als auch qualitativ), die wichtigsten Geschäftskennzahlen und Verkehrsprognosen, die bekannten Ressourcenengpässe und -anforderungen sowie historische Daten über den Verkehr des Microservices nutzen. Hier sind die qualitativen und quantitativen Wachstumsskalen besonders nützlich, denn sie ermöglichen es uns, genau herauszufinden, wie das Skalierbarkeitsverhalten unserer Microservices mit den hochrangigen Geschäftsprognosen zusammenhängt. Wenn wir zum Beispiel wissen, dass (1) unser Microservice mit den Besuchern des Produkts skaliert, (2) jeder einzelne Besucher einer bestimmten Anzahl von Anfragen pro Sekunde an unseren Microservice entspricht und (3) das Unternehmen vorhersagt, dass das Produkt im nächsten Quartal 20.000 neue Besucher erhalten wird, dann wissen wir genau, wie hoch unser Kapazitätsbedarf im nächsten Quartal sein wird.

Dies muss in das Budget jedes Entwicklungsteams, jeder technischen Organisation und jedes Unternehmens integriert werden. Wenn du diese Übung regelmäßig durchführst , bevor das Budget festgelegt wird, kannst du sicherstellen, dass die Hardware-Ressourcen nicht ausfallen, nur weil die Budgetierung der Ressourcen nicht abgeschlossen oder vorbereitet wurde. Wichtig ist hier (sowohl aus technischer als auch aus geschäftlicher Sicht), die Kosten einer unzureichenden Kapazitätsplanung zu erkennen: Microservices, die aufgrund von Hardwaremangel nicht richtig skaliert werden können, führen zu einer geringeren Verfügbarkeit innerhalb des gesamten Ökosystems, was wiederum zu Ausfällen führt, die das Unternehmen Geld kosten.

Vorlaufzeit für neue Hardware-Anfragen

Ein potenzielles Problem, das von Entwicklungsteams in der Phase der Kapazitätsplanung häufig übersehen wird, ist, dass die für den Microservice benötigte Hardware zum Zeitpunkt der Planung möglicherweise noch nicht vorhanden ist und erst beschafft, installiert und konfiguriert werden muss, bevor Microservices darauf laufen können. Bevor du die Kapazitätsplanung vornimmst, solltest du dich über die genaue Vorlaufzeit für die Beschaffung neuer Hardware informieren, um lange Engpässe in kritischen Zeiten zu vermeiden und einen gewissen Spielraum für Verzögerungen im Prozess einzuplanen.

Sobald die Hardwareressourcen gesichert und den einzelnen Microservices zugewiesen sind, ist die Kapazitätsplanung abgeschlossen. Die Entscheidung darüber, wann und wie die Hardware nach der Planungsphase zugewiesen wird, liegt natürlich bei der jeweiligen technischen Organisation und ihren Entwicklungs-, Infrastruktur- und Betriebsteams.

Die Kapazitätsplanung kann eine wirklich schwierige und manuelle Aufgabe sein. Wie die meisten manuellen Aufgaben in der Technik birgt sie neue Fehlermöglichkeiten: Manuelle Berechnungen können fehlerhaft sein, und selbst ein kleiner Engpass kann für geschäftskritische Dienste katastrophale Folgen haben. Die Automatisierung des Großteils des Kapazitätsplanungsprozesses außerhalb der Entwicklungs- und Betriebsteams reduziert potenzielle Fehler und Ausfälle. Eine gute Möglichkeit, dies zu erreichen, ist der Aufbau und Betrieb eines Self-Service-Tools für die Kapazitätsplanung innerhalb der Anwendungsplattform des Microservice-Ökosystems.

Dependency Scaling

Die Skalierbarkeit der Abhängigkeiten eines Microservices kann ein eigenes Skalierbarkeitsproblem darstellen. Ein Microservice, der in jeder Hinsicht perfekt skalierbar konzipiert, entwickelt und ausgeführt wird, hat immer noch Probleme mit der Skalierbarkeit, wenn seine Abhängigkeiten nicht mit ihm skalieren können. Wenn auch nur eine kritische Abhängigkeit nicht mit ihren Kunden skalieren kann, leidet die gesamte Abhängigkeitskette darunter. Die Sicherstellung, dass alle Abhängigkeiten mit dem erwarteten Wachstum eines Microservices mitwachsen, ist für den Aufbau produktionsfähiger Dienste unerlässlich.

Diese Herausforderung betrifft jeden einzelnen Microservice und jeden Teil des Microservice-Ökosystems. Das bedeutet, dass Microservice-Teams auch dafür sorgen müssen, dass ihr Service kein Skalierungsengpass für seine Kunden ist. Mit anderen Worten: Der Rest des Microservice-Ökosystems sorgt für zusätzliche Komplexität. Auf den unvermeidlichen zusätzlichen Datenverkehr und das Wachstum der Kunden eines Microservices muss man vorbereitet sein.

Qualitative Wachstumsskalen und Skalierbarkeit von Abhängigkeiten

Wenn du es mit unglaublich komplexen Abhängigkeitsketten zu tun hast, kannst du sicherstellen, dass alle Microservice-Teams die Skalierbarkeit ihrer Dienste mit hochrangigen Geschäftsmetriken verknüpfen (unter Verwendung der qualitativen Wachstumsskala) . So kannst du sicherstellen, dass alle Dienste auf das erwartete Wachstum vorbereitet sind, selbst wenn die teamübergreifende Kommunikation schwierig wird.

Das Problem der Skalierung von Abhängigkeiten ist ein besonders starkes Argument für die Implementierung von Skalierbarkeits- und Leistungsstandards in jedem Teil des Microservice-Ökosystems. Die meisten Microservices leben nicht in Isolation. Fast jeder einzelne Microservice ist ein kleiner Teil großer, miteinander verflochtener, komplizierter Abhängigkeitsketten. In den meisten Fällen ist es für eine effektive Skalierung des gesamten Produkts, der Organisation und des Ökosystems erforderlich, dass jeder Teil des Systems zusammen mit dem Rest skaliert. Eine kleine Anzahl super effizienter, leistungsfähiger und skalierbarer Microservices in einem System, in dem der Rest der Services nicht denselben Standards unterliegt (und diese nicht erfüllt), macht die Effizienz der standardisierten Services zunichte.

Neben der Standardisierung im gesamten Ökosystem und der Einhaltung hoher Skalierbarkeitsstandards durch die einzelnen Microservice-Entwicklungsteams ist es wichtig, dass die Entwicklungsteams über Microservice-Grenzen hinweg zusammenarbeiten, um sicherzustellen, dass jede Abhängigkeitskette gemeinsam skaliert. Die Entwicklungsteams, die für die Abhängigkeiten eines Microservices verantwortlich sind, müssen gewarnt werden, wenn ein Anstieg des Datenverkehrs zu erwarten ist. Teamübergreifende Kommunikation und Zusammenarbeit sind hier unerlässlich: Die regelmäßige Kommunikation mit Kunden und Abhängigen über die Skalierbarkeitsanforderungen, den Status und eventuelle Engpässe eines Dienstes kann dazu beitragen, dass alle Dienste, die aufeinander angewiesen sind, auf das Wachstum vorbereitet sind und mögliche Skalierbarkeitsengpässe kennen. Eine Strategie, mit der ich Teams dabei helfe, dies zu erreichen, ist die Durchführung von Architektur- und Skalierbarkeitsüberblicksbesprechungen mit Teams, deren Dienste voneinander abhängen. In diesen Sitzungen besprechen wir die Architektur jedes Dienstes und seine Skalierbarkeitsgrenzen und besprechen dann gemeinsam, was getan werden muss, um die gesamte Gruppe der Dienste zu skalieren.

Verkehrsmanagement

Da die Dienste skalieren und die Anzahl der Anfragen, die jeder Dienst bearbeiten muss, wächst, muss ein skalierbarer, leistungsfähiger Dienst auch den Datenverkehr intelligent verwalten. Ein skalierbarer, leistungsfähiger Dienst muss auch den Datenverkehr intelligent handhaben: Erstens muss das Wachstum (quantitativ und qualitativ) genutzt werden, um den zukünftigen Anstieg (oder Rückgang) des Datenverkehrs vorherzusagen; zweitens müssen die Datenverkehrsmuster gut verstanden und darauf vorbereitet werden; und drittens müssen Microservices in der Lage sein, mit dem Anstieg des Datenverkehrs, aber auch mit Lastspitzen oder -ausbrüchen, intelligent umzugehen.

Den ersten Aspekt haben wir bereits weiter oben in diesem Kapitel behandelt: Das Verständnis der Wachstumsskalen (sowohl quantitativ als auch qualitativ) eines Microservices ermöglicht es uns, die aktuelle Verkehrsbelastung des Dienstes zu verstehen und uns auf zukünftiges Verkehrswachstum vorzubereiten.

Das Verständnis der aktuellen Verkehrsmuster hilft bei der Interaktion mit dem Dienst vor Ort auf viele wirklich interessante Arten. Wenn die Verkehrsmuster klar identifiziert sind, sowohl in Bezug auf die Anfragen pro Sekunde, die im Laufe der Zeit an den Dienst gesendet werden, als auch in Bezug auf alle Schlüsselmetriken (mehr zu den Schlüsselmetriken findest du in Kapitel 6, Überwachung), können Änderungen am Dienst, Betriebsunterbrechungen und Einsätze so geplant werden, dass Spitzenzeiten im Verkehr vermieden werden, um mögliche zukünftige Ausfälle zu vermeiden, wenn ein Fehler eingebaut wird, und um potenzielle Ausfallzeiten zu reduzieren, wenn der Microservice während der Spitzenbelastung neu gestartet wird. Eine genaue Überwachung des Datenverkehrs unter Berücksichtigung der Verkehrsmuster und eine sorgfältige Abstimmung der Überwachungsschwellenwerte auf die Verkehrsmuster des Microservices können dazu beitragen, dass Probleme und Vorfälle schnell erkannt werden, bevor sie einen Ausfall verursachen oder zu einer verringerten Verfügbarkeit führen (die Grundsätze der produktionsreifen Überwachung von werden in Kapitel 6, Überwachung, ausführlicher behandelt).

Wenn wir das künftige Verkehrswachstum vorhersagen können und die aktuellen und vergangenen Verkehrsmuster gut genug kennen, um zu wissen, wie sich die Muster mit dem erwarteten Wachstum verändern werden, können wir Lasttests mit unseren Diensten durchführen, um sicherzustellen, dass sie sich bei höherer Verkehrslast so verhalten, wie wir es erwarten. Die Einzelheiten der Lasttests werden in "Ausfallsicherheitstests" behandelt .

Der dritte Aspekt des Datenverkehrsmanagements ist der, bei dem es besonders knifflig wird. Die Art und Weise, wie ein Microservice mit dem Datenverkehr umgeht, sollte skalierbar sein, d.h. er sollte auf drastische Veränderungen im Datenverkehr vorbereitet sein, insbesondere auf Datenverkehrsbursts, und diese sorgfältig handhaben, um zu verhindern, dass sie den Dienst komplett lahmlegen. Das ist leichter gesagt als getan, denn selbst bei den am besten überwachten, skalierbaren und leistungsfähigen Microservices kann es zu Problemen bei der Überwachung, Protokollierung und anderen allgemeinen Problemen kommen, wenn der Datenverkehr plötzlich in die Höhe schnellt. Solche Spitzen sollten auf der Infrastrukturebene, in allen Überwachungs- und Protokollierungssystemen und vom Entwicklungsteam im Rahmen der Ausfallsicherheitstests des Dienstes vorbereitet werden.

Es gibt noch einen weiteren Aspekt, den ich erwähnen möchte und der mit der Verwaltung des Datenverkehrs zwischen und über verschiedene Standorte hinweg zu tun hat. Viele Microservice-Ökosysteme werden nicht nur an einem Standort, in einem Rechenzentrum oder in einer Stadt eingesetzt, sondern in mehreren Rechenzentren im ganzen Land (oder sogar weltweit). Es ist nicht ungewöhnlich, dass es in den Rechenzentren selbst zu großflächigen Ausfällen kommt, und wenn das passiert, kann das gesamte Microservice-Ökosystem zusammen mit dem Rechenzentrum ausfallen (und wird es normalerweise auch). Für die Verteilung und das Routing des Datenverkehrs zwischen den Rechenzentren ist die Infrastrukturebene (insbesondere die Kommunikationsschicht) des Microservice-Ökosystems zuständig, aber jeder Microservice muss darauf vorbereitet sein, den Datenverkehr von einem Rechenzentrum zu einem anderen umzuleiten, ohne dass der Dienst eine geringere Verfügbarkeit erfährt.

Handhabung und Verarbeitung von Aufgaben

Jeder Microservice ( ) im Microservice-Ökosystem muss eine Art von Aufgaben verarbeiten. Das heißt, jeder Microservice erhält Anfragen von vorgelagerten Client-Diensten, die entweder Informationen vom Microservice benötigen oder den Microservice beauftragen, etwas zu berechnen oder zu verarbeiten und dann Informationen über diese Berechnung oder diesen Prozess zurückzusenden, und dann muss der Microservice diese Anfrage erfüllen (in der Regel durch Kommunikation mit nachgelagerten Diensten zusätzlich zu seiner eigenen Arbeit) und alle angeforderten Informationen oder Antworten an den Client zurücksenden, der die Anfrage gesendet hat.

Grenzen der Programmiersprache

Microservices können diese Aufgabe auf vielfältige Weise erfüllen. Die Art und Weise, wie sie Berechnungen durchführen, mit nachgelagerten Diensten interagieren und verschiedene Aufgaben bearbeiten, hängt von der Sprache ab, in der der Dienst geschrieben ist, und folglich auch von der Architektur des Dienstes (die in vielerlei Hinsicht von der Sprache bestimmt wird). Ein Microservice, der in Python geschrieben ist, hat zum Beispiel eine Reihe von Möglichkeiten, verschiedene Aufgaben zu verarbeiten. Einige davon erfordern den Einsatz asynchroner Frameworks (wie Tornado), andere wiederum können Messaging-Technologien wie RabbitMQ und Celery nutzen, um Aufgaben effizient zu verarbeiten. Aus diesen Gründen wird die Fähigkeit eines Microservices, Aufgaben auf skalierbare und performante Weise zu bearbeiten, zum Teil von der Wahl der Sprache bestimmt.

Vorsicht vor den Skalierbarkeits- und Leistungsbeschränkungen von Programmiersprachen

Viele Programmiersprachen sind nicht für die Leistungs- und Skalierbarkeitsanforderungen von Microservice-Architekturen optimiert oder verfügen nicht über skalierbare oder leistungsfähige Frameworks, mit denen Microservices Aufgaben effizient bearbeiten können.

Aufgrund der Einschränkungen, die durch die Sprachwahl in Bezug auf die Fähigkeit eines Microservice, Aufgaben effizient zu verarbeiten, entstehen, ist die Sprachwahl in der Microservice-Architektur extrem wichtig. Für viele Entwickler/innen ist eines der Verkaufsargumente für die Einführung der Microservice-Architektur die Möglichkeit, einen Microservice in jeder beliebigen Sprache schreiben zu können, und das stimmt in der Regel auch, allerdings mit einer Einschränkung: Die Einschränkungen der Programmiersprache müssen berücksichtigt werden, und die Wahl der Sprache sollte nicht davon abhängen, ob eine Sprache in Mode ist oder Spaß macht (oder ob es sich um die gängigste Sprache handelt, mit der das Entwicklungsteam vertraut ist), sondern die Leistungs- und Skalierbarkeitseinschränkungen jeder potenziellen Sprache sollten als entscheidende Faktoren gelten. Es gibt nicht die eine "beste" Sprache, um einen Microservice zu schreiben, aber es gibt Sprachen, die für bestimmte Arten von Microservices besser geeignet sind als andere.

Effiziente Bearbeitung von Anträgen und Aufgaben

Abgesehen von der Wahl der Sprache erfordert die Standardisierung der Produktionsbereitschaft, dass jeder Microservice sowohl skalierbar als auch performant ist. Das bedeutet, dass Microservices in der Lage sein müssen, eine große Anzahl von Aufgaben gleichzeitig zu bearbeiten und zu verarbeiten, diese Aufgaben effizient zu bearbeiten und darauf vorbereitet zu sein, dass die Aufgaben und Anfragen in Zukunft zunehmen werden. Vor diesem Hintergrund sollten Entwicklungsteams in der Lage sein, drei grundlegende Fragen zu ihren Microservices zu beantworten: wie ihr Microservice Aufgaben verarbeitet, wie effizient ihr Microservice diese Aufgaben verarbeitet und wie ihr Microservice funktioniert, wenn die Zahl der Anfragen steigt.

Um Skalierbarkeit und Leistung zu gewährleisten, müssen Microservices Aufgaben effizient verarbeiten. Dazu brauchen sie sowohl Gleichzeitigkeit als auch Partitionierung. Gleichzeitigkeit bedeutet, dass der Dienst nicht nur einen einzigen Prozess haben darf, der die gesamte Arbeit erledigt: Dieser Prozess nimmt eine Aufgabe nach der anderen auf, führt die Schritte in einer bestimmten Reihenfolge aus und geht dann zur nächsten über, was eine relativ ineffiziente Art der Aufgabenbearbeitung ist. Anstatt unseren Dienst so zu gestalten, dass er einen einzigen Prozess verwendet, können wir die Gleichzeitigkeit einführen, sodass jede Aufgabe in kleinere Teile aufgeteilt wird.

Microservices in Programmiersprachen schreiben, die für Gleichzeitigkeit und Partitionierung optimiert sind

Einige Sprachen sind für eine effiziente (gleichzeitige und partitionierte) Aufgabenbearbeitung und -verarbeitung besser geeignet als andere. Wenn du einen neuen Microservice schreibst, solltest du sicherstellen, dass die Sprache, in der der Service geschrieben wird, keine Einschränkungen bei der Skalierbarkeit und Leistung der Microservices mit sich bringt. Microservices, die bereits in Sprachen mit Leistungseinschränkungen geschrieben wurden, können (und sollten) in geeignetere Sprachen umgeschrieben werden. Das ist eine zeitaufwändige, aber unglaublich lohnende Aufgabe, die die Skalierbarkeit und Leistung drastisch verbessern kann. Wenn du zum Beispiel die Gleichzeitigkeit und Partitionierung optimieren und dafür ein asynchrones Framework verwenden willst, wird das Schreiben deines Dienstes in Python (und nicht in C++, Java oder Go - drei Sprachen, die für Gleichzeitigkeit und Partitionierung entwickelt wurden) eine Menge Skalierbarkeits- und Leistungsengpässe mit sich bringen, die sich nur schwer abmildern lassen.

Die kleineren Teile dieser Aufgaben können wir durch Partitionierung effizienter bearbeiten. Dabei wird jede Aufgabe nicht nur in kleine Teile aufgeteilt, sondern kann auch parallel bearbeitet werden. Wenn wir eine große Anzahl kleiner Aufgaben haben, können wir sie alle gleichzeitig bearbeiten, indem wir sie an eine Gruppe von Arbeitern schicken, die sie parallel bearbeiten können. Wenn wir mehr Aufgaben bearbeiten müssen, können wir diese problemlos mit der steigenden Nachfrage skalieren, indem wir zusätzliche Worker hinzufügen, die die neuen Aufgaben bearbeiten, ohne die Effizienz unseres Systems zu beeinträchtigen. Parallelität und Partitionierung tragen dazu bei, dass unser Microservice sowohl für Skalierbarkeit als auch für Partitionierung optimiert ist.

Skalierbare Speicherung von Daten

Microservices müssen Daten auf eine skalierbare und performante Weise verarbeiten. Die Art und Weise, wie ein Microservice Daten speichert und verarbeitet, kann leicht zur wichtigsten Einschränkung werden, die ihn davon abhält, skalierbar und performant zu werden: Die Wahl der falschen Datenbank, des falschen Schemas oder einer Datenbank, die keine Test-Tenancy unterstützt, kann am Ende die Gesamtverfügbarkeit eines Microservices beeinträchtigen. Die Wahl der richtigen Datenbank für einen Microservice ist ein Thema, das wie alle anderen in diesem Buch behandelten Themen unglaublich komplex ist, und wir werden in diesem Kapitel nur an der Oberfläche kratzen. In den folgenden Abschnitten werfen wir einen Blick auf verschiedene Dinge, die bei der Auswahl von Datenbanken in Microservice-Ökosystemen zu beachten sind, und gehen dann auf einige Datenbank-Herausforderungen ein, die speziell für Microservice-Architekturen gelten.

Die Wahl der Datenbank in Microservice-Ökosystemen

Der Aufbau, Betrieb und die Wartung von Datenbanken in großen Microservice-Ökosystemen ist keine leichte Aufgabe. Einige Unternehmen, die eine Microservice-Architektur einführen, erlauben ihren Entwicklungsteams, ihre eigenen Datenbanken auszuwählen, zu erstellen und zu pflegen. Andere entscheiden sich für mindestens eine Datenbankoption, die für die meisten Microservices im Unternehmen geeignet ist, und stellen ein eigenes Team für den Betrieb und die Pflege der Datenbank(en) ein, damit sich die Entwickler ausschließlich auf ihre eigenen Microservices konzentrieren können.

Wenn wir davon ausgehen, dass die Microservice-Architektur aus vier separaten Schichten besteht (siehe "Microservice-Architektur" für weitere Details) und erkennen, dass dank des Inverse Conway's Law die technischen Organisationen von Unternehmen, die eine Microservice-Architektur einführen, die Architektur ihres Produkts widerspiegeln, dann können wir sehen, wo die Verantwortung für die Auswahl der geeigneten Datenbanken, ihre Erstellung, ihren Betrieb und ihre Wartung liegt: entweder in der Anwendungsplattform-Schicht, die es ermöglichen würde, Datenbanken als Service für Microservice-Teams bereitzustellen, oder in der Microservice-Schicht, in der die von einem Microservice verwendete Datenbank als Teil des Service betrachtet wird. Ich habe beide Ansätze in der Praxis bei verschiedenen Unternehmen gesehen, und einige funktionieren besser als andere. Mir ist auch aufgefallen, dass ein Ansatz besonders gut funktioniert: das Anbieten von Datenbanken als Service innerhalb der Anwendungsplattform und die Möglichkeit für die einzelnen Microservice-Entwicklungsteams, ihre eigene Datenbank zu verwenden, wenn die Datenbanken, die als Teil der Anwendungsplattform angeboten werden, nicht ihren speziellen Anforderungen entsprechen.

Die gängigsten Datenbankarten sind relationale Datenbanken (SQL, MySQL) und NoSQL-Datenbanken (Cassandra, Vertica, MongoDB und Key-Value-Stores wie Dynamo, Redis und Riak). Die Entscheidung zwischen einer relationalen Datenbank und einer NoSQL-Datenbank und die Wahl der geeigneten Datenbank für die Anforderungen eines Microservices hängt von den Antworten auf mehrere Fragen ab:

• Wie viele Transaktionen werden pro Sekunde für jeden Microservice benötigt?

• Welche Art von Daten muss jeder Microservice speichern?

• Welches Schema wird für jeden Microservice benötigt? Und wie oft wird es geändert werden müssen?

• Brauchen die Microservices starke Konsistenz oder eventuelle Konsistenz?

• Sind die Microservices leselastig, schreiblastig oder beides?

• Muss die Datenbank horizontal oder vertikal skaliert werden?

Unabhängig davon, ob die Datenbank als Teil der Anwendungsplattform oder von jedem einzelnen Microservice-Entwicklungsteam gepflegt wird, sollte sich die Wahl der Datenbank nach den Antworten auf diese Fragen richten. Wenn die betreffende Datenbank beispielsweise horizontal skaliert werden muss oder wenn Lese- und Schreibvorgänge parallel durchgeführt werden müssen, sollte eine NoSQL-Datenbank gewählt werden, da relationale Datenbanken mit horizontaler Skalierung und parallelen Lese- und Schreibvorgängen Schwierigkeiten haben.

Datenbank-Herausforderungen in der Microservice-Architektur

Es gibt einige Herausforderungen bei Datenbanken, die speziell für Microservice-Architekturen gelten. Wenn Datenbanken von Microservices gemeinsam genutzt werden, kommt es zu einem Wettbewerb um Ressourcen, und einige Microservices können mehr als ihren Anteil an der verfügbaren Speicherung beanspruchen. Ingenieure, die gemeinsam genutzte Datenbanken aufbauen und pflegen, müssen ihre Lösungen für die Speicherung von Daten so gestalten, dass die Datenbank leicht skaliert werden kann, wenn einer der Microservices zusätzlichen Speicherplatz benötigt oder Gefahr läuft, den gesamten verfügbaren Speicherplatz zu belegen.

Achte auf Datenbank-Verbindungen

Einige Datenbanken haben strenge Beschränkungen für die Anzahl der Datenbankverbindungen, die gleichzeitig geöffnet sein können. Achte darauf, dass alle Verbindungen ordnungsgemäß geschlossen werden, um zu vermeiden, dass sowohl die Verfügbarkeit eines Dienstes als auch die Verfügbarkeit der Datenbank für alle Microservices, die sie nutzen, beeinträchtigt wird.

Eine weitere Herausforderung, mit der Microservices oft konfrontiert sind, insbesondere wenn sie stabile und zuverlässige Entwicklungszyklen und Deployment-Pipelines aufgebaut und standardisiert haben, ist die Handhabung von Testdaten aus End-to-End-Tests, Lasttests und allen Testschreibvorgängen im Staging. Wie im Abschnitt "Die Deployment-Pipeline" erwähnt , muss in der Staging-Phase der Deployment-Pipeline in Datenbanken gelesen und/oder geschrieben werden. Wenn Full Staging implementiert wurde, verfügt die Staging-Phase über eine eigene, separate Test- und Staging-Datenbank. Bei Partial Staging ist jedoch Lese- und Schreibzugriff auf die Produktionsserver erforderlich, so dass sehr sorgfältig darauf geachtet werden muss, dass die Testdaten angemessen gehandhabt werden: Sie müssen eindeutig als Testdaten gekennzeichnet werden (ein Prozess, der als Test Tenancy bekannt ist), und dann müssen alle Testdaten in regelmäßigen Abständen gelöscht werden.

Evaluiere deinen Microservice

Nachdem du nun ein besseres Verständnis von Skalierbarkeit und Leistung hast, kannst du die folgende Liste von Fragen nutzen, um die Produktionsreife deiner Microservices und deines Microservice-Ökosystems zu bewerten. Die Fragen sind nach Themen geordnet und entsprechen den Abschnitten in diesem Kapitel.

Die Wachstumsskala kennen

• Wie hoch ist das qualitative Wachstum dieses Microservices?

• Wie hoch ist das quantitative Wachstum dieses Microservices?

Effiziente Nutzung von Ressourcen

• Läuft der Microservice auf dedizierter oder gemeinsam genutzter Hardware?

• Werden Technologien zur Abstraktion und Zuweisung von Ressourcen eingesetzt?

Ressourcen-Bewusstsein

• Wie hoch ist der Ressourcenbedarf des Microservices (CPU, RAM, etc.)?

• Wie viel Verkehr kann eine Instanz des Microservices bewältigen?

• Wie viel CPU wird für eine Instanz des Microservices benötigt?

• Wie viel Speicherplatz benötigt eine Instanz des Microservices?

• Gibt es weitere Ressourcenanforderungen, die für diesen Microservice spezifisch sind?

• Was sind die Ressourcenengpässe dieses Microservices?

• Muss dieser Microservice vertikal, horizontal oder beides skaliert werden?

Kapazitätsplanung

• Erfolgt die Kapazitätsplanung nach einem Zeitplan?

• Wie lange ist die Vorlaufzeit für neue Hardware?

• Wie oft werden Hardware-Anfragen gestellt?

• Werden bestimmte Microservices bei Hardware-Anfragen bevorzugt behandelt?

• Ist die Kapazitätsplanung automatisiert oder erfolgt sie manuell?

Dependency Scaling

• Welche Abhängigkeiten gibt es bei diesem Microservice?

• Sind die Abhängigkeiten skalierbar und performant?

• Werden die Abhängigkeiten mit dem erwarteten Wachstum des Microservices mitwachsen?

• Sind die Verantwortlichen für die Abhängigkeiten auf das erwartete Wachstum dieses Microservices vorbereitet?

Verkehrsmanagement

• Sind die Verkehrsmuster des Microservices gut bekannt?

• Werden Änderungen des Dienstes entsprechend dem Verkehrsaufkommen geplant?

• Werden drastische Änderungen des Verkehrsaufkommens (insbesondere Verkehrsstöße) sorgfältig und angemessen gehandhabt?

• Kann der Datenverkehr im Falle eines Ausfalls automatisch an andere Rechenzentren weitergeleitet werden?

Handhabung und Verarbeitung von Aufgaben

• Ist der Microservice in einer Programmiersprache geschrieben, die es ermöglicht, dass der Dienst skalierbar und performant ist?

• Gibt es Skalierbarkeits- oder Leistungseinschränkungen bei der Art und Weise, wie der Microservice Anfragen bearbeitet?

• Gibt es Einschränkungen bei der Skalierbarkeit oder Leistung der Art und Weise, wie der Microservice Aufgaben verarbeitet?

• Verstehen die Entwickler im Microservice-Team, wie ihr Dienst Aufgaben verarbeitet, wie effizient er diese Aufgaben verarbeitet und wie der Dienst bei einer steigenden Anzahl von Aufgaben und Anfragen funktioniert?

Skalierbare Speicherung von Daten

• Verarbeitet dieser Microservice Daten auf skalierbare und performante Weise?

• Welche Art von Daten muss dieser Microservice speichern?

• Welches Schema wird für seine Daten benötigt?

• Wie viele Transaktionen werden pro Sekunde benötigt und/oder durchgeführt?

• Braucht dieser Microservice eine höhere Lese- oder Schreibleistung?

• Ist sie leselastig, schreiblastig oder beides?

• Ist die Datenbank dieses Dienstes horizontal oder vertikal skaliert? Ist sie repliziert oder partitioniert?

• Verwendet dieser Microservice eine eigene oder eine gemeinsame Datenbank?

• Wie verarbeitet und/oder speichert der Dienst Testdaten?