15 Best Practices für den Aufbau einer Microservices-Architektur

15 Best Practices für den Aufbau einer Microservices-Architektur

  • ITOps & DevOps
6 Minuten Lesezeit Aktualisiert Dec 23, 2020

Auf einen Blick: Best Practices für den Aufbau einer Microservices-Architektur verbessern das Anwendungsmanagement, indem sie die unabhängige Entwicklung und Bereitstellung von Services fördern. Wichtige Strategien umfassen die separate Bereitstellung von Microservices, deren Containerisierung für Flexibilität und die Nutzung von Automatisierungstools für Bereitstellungsprozesse.

  • Microservices sollten lose gekoppelt und für hohe Kohäsion ausgelegt sein.
  • Implementieren Sie ein zentrales Protokoll- und Überwachungssystem für eine bessere Fehlerbehandlung.

Microservices sind ein weiterentwickeltes architektonisches Muster, das das Design und die Entwicklung einer Anwendung als Sammlung kleiner, autonomer, lose gekoppelter Services umfasst, die miteinander kommunizieren. Auf seiner elementaren Ebene agiert jeder einzelne Microservice als eigene Anwendung. Die Strukturierung von Anwendungen als Sammlung von Microservices fördert:

  • Einfache und schnellere Bereitstellung
  • Skalierbarkeit
  • Wartbarkeit

Das macht das Management und die Wartung der gesamten Anwendung viel einfacher.

Mikroservice-Architektur

Ein typisches Microservices-Framework

Diese Vorteile bestätigen die breitere Verbreitung von Microservices durch DevOps-Organisationen , sowohl große als auch kleine. Es ist eine sichere Annahme, dass die Verbreitung von Microservices dank dieser Vorteile weiter steigen wird – aber um den Nutzen zu maximieren, ist es entscheidend, Best Practices für den Betrieb widerstandsfähiger verteilter Systeme zu übernehmen. Hier sind 15 Best Practices, die grundlegend für den Erfolg von Microservices sind. Schauen wir uns das an!

Best Practices für die Microservices-Architektur

In diesem Artikel gruppiere ich diese Best Practices in Kategorien, die den Fortschritt verschiedener Softwareentwicklungsphasen im Lebenszyklus (SDLC) widerspiegeln, beginnend ab dem Zeitpunkt, an dem Sie Microservices für Ihr nächstes Projekt in Betracht ziehen, bis zum Ende der Anwendungsbereitstellung. Die Tipps enthalten außerdem Praktiken, die speziell für neue Nutzer spezifisch sind, damit Sie erfolgreich von einem monolithischen zu einem Microservice-Framework wechseln können.

Für Planung und Organisation...

  • Bestimmen Sie, ob die Microservices-Architektur auf Grundlage Ihrer Anforderungen geeignet ist. Nehmen Sie keine Microservices-Architektur an, nur weil die großen Namen sie machen. Sie sollten Ihre Anforderungen analysieren, um zu sehen, wo Sie sie in Funktionen aufteilen können, die einen Mehrwert bieten. Führen Sie Ihre Sorgfaltspflicht durch, um sicherzustellen, dass Ihre Anwendung in Microservices unterteilt werden kann, ohne dabei ihre Kernfunktionen und die Betriebsfähigkeit zu erhalten.
  • Bringen Sie alle mit der Idee an Bord. Der Übergang von monolithischer Architektur zu Microservices ist anfangs ein langwieriger und mühsamer Prozess – und die Auswirkungen beschränken sich nicht nur auf das Entwicklungsteam. Stakeholder sollten die Zeit, das Geld und die technische Expertise berücksichtigen, die für die notwendigen infrastrukturellen Änderungen erforderlich sind. Das Engineering-Team steht insbesondere vor erheblichen Umwälzungen, sowohl als Implementierer als auch als Nutzer während des gesamten Übergangs.
  • Bauen Sie Teams um Microservices herum. Jeder Microservice agiert als eigenständige Anwendung, daher sollten auch Teams das tun. Bilden Sie separate Teams für die Handhabung verschiedener Microservices. Das erfordert auch, dass solche Teams über die notwendigen Fähigkeiten und Werkzeuge verfügen, um einen bestimmten Service eigenständig zu entwickeln, bereitzustellen und zu verwalten. Die Teams sollten flexibel und groß genug sein, um ihre Abläufe eigenständig zu bewältigen, ohne Zeit mit der Kommunikation zu verschwenden.

Beim Entwerfen des Microservices...

  • Unterscheiden Sie Ihre Microservices von Ihren Geschäftsfunktionen und -dienstleistungen. Dies hilft Ihnen, Microservices zu vermeiden, die entweder zu groß oder zu klein sind. Wenn Ersteres eintritt, werden Sie keinen Nutzen aus der Nutzung der Microservice-Architektur sehen. Letzteres führt zu einem exponentiellen Anstieg der Betriebskosten, der alle erzielten Vorteile überwiegt.
  • Entwerfen Sie Ihre Services so, dass sie lose gekoppelt sind, hohe Kohäsion haben und einen eingrenzenden Kontext abdecken. Ein lose gekoppelter Service hängt minimal von anderen Services ab. Hohe Kohäsion erfordert, dass das Design des Services dem Prinzip der Einzelverantwortung folgt – das heißt, er sollte nur eine Hauptfunktion erfüllen und diese gut ausführen. Schließlich sollten Sie Ihren Service so gestalten, dass er domänenspezifisch ist und gleichzeitig interne Details der Domäne und domänenspezifische Modelle enthält. Dies stellt sicher, dass ein Microservice einen eingrenzenden Kontext abdeckt und so ein Domain-Driven Design (DDD) erreicht.
  • Verwenden Sie APIs und Ereignisse, um zwischen Diensten zu kommunizieren. Dienste sollten sich nicht direkt gegenseitig aufrufen. Stattdessen sollten Sie ein API-Gateway entwerfen, das Authentifizierung, Anfragen und Antworten sowie Drosselung für die Dienste übernimmt. Mit einem API-Gateway können Sie den Datenverkehr einfach vom API-Gateway auf die aktualisierte Version umleiten, sobald es Änderungen an Ihrem Service gibt.
  • Berücksichtigen Sie Sicherheitslücken innerhalb einer Microservice-Architektur. Als Best Practice sollten Sie das DevSecOps-Modell übernehmen, um ein sicheres Microservices-Framework sicherzustellen. Wichtig ist, dass Microservices im Allgemeinen aufgrund ihrer verteilten Struktur anfälliger für Angriffsvektoren sind. Daher erfordert die Bereitstellung von Sicherheit einen völlig anderen Ansatz als ein monolithisches Framework – deshalb ist DevSecOps perfekt.

Beim Entwickeln des Microservices...

  • Haben Sie für jeden Dienst eine eigene Versionskontrollstrategie. Jeder Dienst sollte sein eigenes Repository für einfachen Zugriff haben, während die Versionskontrollprotokolle sauber gehalten werden. Das ist auch nützlich, wenn Sie Änderungen implementieren, die möglicherweise andere Dienste kaputt machen könnten.
  • Entwicklungsumgebungen sollten über alle Maschinen hinweg konsistent sein. Richten Sie die Entwicklungsumgebung Ihres Services als virtuelle Maschinen ein, damit Entwickler das Framework anpassen und schnell loslegen können.
  • Integrieren Sie Abwärtskompatibilität für die Service-Endpunkte, die Sie freistellen. Sie sollten keine Aufrufer kaputt machen. Dazu implementieren Sie starre Vertragstests, um sich vor fehlerhaften Änderungen zu schützen. Dies ermöglicht auch Abwärtskompatibilität basierend auf den API-Aufrufen als Antwort auf jede Benutzeranfrage. Dies hilft Ihrer Organisation, produktionsbereite Anwendungen schneller zu erstellen.

Für Datenspeicherung und -verwaltung...

  • Haben Sie für jeden Microservice unterschiedliche Datenbanken oder Datenspeicher. Wählen Sie eine Datenbank aus, die zu den Bedürfnissen Ihres Microservices passt, passen Sie die Infrastruktur und den Speicher an die enthaltenen Daten an und nutzen Sie sie ausschließlich für diesen Microservice. Dies bleibt einer der wichtigsten Ermöglicher für ein robustes Microservice-Framework, bei dem jeder Service unabhängig gepflegt wird und gleichzeitig mit anderen Services über ein Service-Mesh zusammenarbeitet.
Service Mesh

Service-Mesh-fähige Microservices

Zum Deployen und Hosten...

  • Stellen Sie Ihre Microservices separat bereit. Das hilft, Zeit zu sparen, während Sie bei regelmäßigen Wartungs- oder Upgrade-Arbeiten mit mehreren Teams zusammenarbeiten. Sie möchten auch nicht, dass ein einzelner Dienst unfair viele Ressourcen verbraucht und andere Services beeinträchtigt, nur weil sie Ressourcen teilen. Ich empfehle dringend, eine dedizierte Infrastruktur zu verwenden, um jeden Microservice zu hosten. Dadurch werden jeder Microservice von Fehlern in anderen Komponenten isoliert, was die Fehlertoleranz verbessert und einen vollständigen Ausfall vermeidet.
  • Containerisieren Sie Ihre Microservices. Container und Microservices gehen oft Hand in Hand. Mit containerisierten Microservices können Sie einzelne Services unabhängig bereitstellen und verwalten, ohne die auf anderen Containern gehosteten Services zu beeinträchtigen. Container bieten zudem Plattformunabhängigkeit und Interoperabilität, die genau mit den Zielen der Microservice-Architektur übereinstimmt.
  • Haben Sie einen separaten Build für Ihre Microservices und automatisieren Sie den Bereitstellungsprozess. Ein wesentlicher Aspekt der Umsetzung des DevOps-Modells ist es, die Effizienz durch Automatisierung zu steigern. Mit Automatisierungstools wie Jenkins können Sie DevOps-Workflows automatisieren, indem Sie Continuous Integration und Continuous Delivery (CI/CD) ermöglichen.

Für Wartung und Betrieb...

  • Verwenden Sie ein zentrales Protokollierungs- und Überwachungssystem. Ein zentrales Protokollsystem stellt sicher, dass alle Microservices ihre Logs in einem standardisierten Format liefern, wobei die Logs für jeden einzelnen diskret gespeichert werden. Im Gegensatz zu einem monolithischen Modell unterstützt dies eine schnellere Fehlerbehandlung und Ursachenanalyse. Darüber hinaus hilft die Nutzung einer fortschrittlichen Überwachungslösung nicht nur, die Ressourcenverfügbarkeit zu überwachen, sondern gewährleistet auch die Sicherheit, indem kompromittierte Ressourcen frühzeitig identifiziert werden.

Übergang zur Microservice-Architektur

Microservices helfen dabei, Anwendungen besser zu verwalten, aber der Übergang zu einer Microservices-Architektur ist komplex. Der Ansatz zur Implementierung von Microservices kann je nach Anwendungsfall unterschiedlich sein – aber diese grundlegenden Best Practices sind universell. Wie immer ist das Ziel aller Microservices, ein Framework zu erreichen, das lose gekoppelt, verteilt und unabhängig ist und gleichzeitig ein DevOps-Modell bildet, das Automatisierung und Effizienz ermöglicht.

Verwandte Literatur

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus ITOps & DevOps

Abonnieren Sie The Brief

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Danke

Sie haben The Brief abonniert
Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.