EN DE
  • Home
  • Services
    • Dedicated Team Ihre verlängerte Werkbank bei PITS
    • Webshops & Webseiten Überzeugende Webauftritte für KMUs
    • Software Developement Komplexe Projekte nach Mass
    • Hybride oder native iOS und Android Apps Native iOS und Android Apps
  • Initiativen
  • Referenzen
  • Technologie
  • Prozess
  • Über PITS
  • Kontakt
  • Medien
    • Blog Unser Blog versorgt Sie regelmässig mit aktuellen und spannenden Artikeln zu den unterschiedlichsten Themen aus der Online-Welt.
    • Whitepapers PITS Whitepapers werden sowohl für Entwickler als auch für Kunden zu bestimmten Themen sorgfältig erstellt.
  • Jobs
  • Startups
�

Microservices Architektur

Erstellt von Sonu CN am 26. Apr 2021
Starting with Hyperledger fabric

Erstellt von Anizhasree K

NoSQL

Erstellt von Thankaraj JJ

Apache Kafka

Erstellt von Sarath Baiju

Durchstarten mit SASS

Erstellt von Harold Gomez

Microservices haben sich als der beste Weg erwiesen, um eine skalierbare, belastbare und verteilte serviceorientierte Architektur zu implementieren. Es gibt eine Reihe von Gestaltungsprinzipien, die uns bei der Dimensionierung der Dienste helfen, damit wir nicht am Ende einen umfangreichen (monolithischen) Service erstellen. Es gibt jedoch verschiedene Möglichkeiten und Herausforderungen, dieses Design zu implementieren, und es liegt im Ermessen des Architekten, den richtigen Ansatz zu wählen, der zum Geschäftsprozess passt.

Die Tools und Technologien entwickeln sich sehr schnell weiter, um den Herausforderungen und Anforderungen gerecht zu werden, so dass man davon ausgehen kann, dass sehr häufig erhebliche Änderungen vorgenommen werden. Dank des Charakters von Microservices können häufige Änderungen mit deutlich weniger Aufwand und Auswirkungen vorgenommen werden und passen gut zum agilen Entwicklungsprozess.

Wenn Sie sich für die Einführung von Microservices entscheiden, sind viele wichtige Entscheidungen zu treffen. Im Folgenden werden wir uns die grundlegenden Prinzipien, Tools und Technologien ansehen, die für den Aufbau einer Microservices Architektur erforderlich sind.

Gestaltungsprinzipien

  • Autonome
  • Hohe Kohäsion
  • Widerstandsfähigkeit
  • Datenkonsistenz
  • Automatisierung

 

Anzuwendende Technologien

  • Kommunikation (synchrone und asynchrone)
  • Containerisierung
  • Dienstregistrierung und -suche
  • Sicherheit
  • Anwendungsskalierung und Management
  • Zentralisierte Überwachung und Protokollierung
  • Konfigurationsmanagement
  • Container-Orchestrierung
  • Infrastruktur als Code
  • Kontinuierliche Integration und Bereitstellungspipeline

 

Der „Domain Driven“ Ansatz

Das „Domain Driven“ Design geht Hand in Hand mit der Microservices Architektur. Der allererste Schritt zur Microservices Architektur ist die Festlegung der Grenzen für jeden Dienst, und bei DDD geht es um die Definition der Grenzen.

Die Architekten benötigen die Hilfe von Fachexperten, um die Bereiche und ihre interne Dynamik zu verstehen, damit sie die Grenzen erkennen können. Es muss eine Bereichsanalyse durchgeführt werden, vorzugsweise eine „Event Storming“-Sitzung, in der die Experten und das technische Team gemeinsam iterativ diskutieren und den Bereich erkunden, um Folgendes zu ermitteln

  • Domain Events: Ereignisse, die wichtig sind und den Geschäftsprozess vorantreiben.
  • Befehle: Die Ereignisquellen, d. h. die Aktionen, die die „Domain Events“ auslösen. Es kann sich um eine Benutzeraktion oder eine vom System generierte Aktion handeln.
  • Allgegenwärtige Sprache: Gemeinsame Geschäftsterminologien, die die Semantik des Bereichs darstellen und überall verwendet werden müssen.
  • Aggregat: Repräsentiert den Zustand und das Verhalten. Führt die Operation aus, um die der Befehl bittet, und gibt die entsprechenden Ereignisse aus.
  • Richtlinien: Geschäftsregeln, die angeben, was als Folge eines durch einen Befehl ausgelösten Ereignisses geschehen soll. Eine Reihe von Richtlinien bilden zusammen einen Geschäftsprozess.
  • Begrenzter Kontext: Eine Gruppe von verwandten Aggregaten und Konzepten aus einem begrenzten Kontext. Ein Bounded Context zieht die Grenze und korreliert mit einem Microservice.
Ein typisches Event Storming Board sieht wie folgt aus

 

Aus dem in der Event Storming-Sitzung gewonnenen Fachwissen kann ein Geschäftsprozessmodell abgeleitet werden. Domain Driven Design in Kombination mit der Modellierung von Geschäftsprozessen unter Verwendung von Business Process Model and Notations (BPMN) kann uns helfen, komplexe Probleme der realen Welt zu lösen und hochgradig kohärente verteilte Systeme zu entwerfen.

Ein BPMN Beispiel von Camunda

 

DDD sollte nur für Microservices mit komplexen Geschäftsregeln angewendet werden. Einfachere Microservices können mit einfachen Ansätzen verwaltet werden. Die technische Implementierung der einzelnen Microservices kann sich je nach Anforderung und Funktionalität unterscheiden. Ein Microservice kann zum Beispiel so einfach sein wie eine serverlose Funktions-App in Azure, ein Service mit mehr Geschäftsregeln und zur Vermeidung von Duplizierung kann das Specification-Muster implementieren, ein Service mit verteilten Transaktionen kann das SAGA-Muster implementieren oder auf BPMN-Automatisierung wie Camunda zurückgreifen, ein Service, der hohe Leistung und Skalierbarkeit erfordert, kann das CQRS-Muster implementieren, ein Audit-bezogener Service könnte sich für Event-Sourcing entscheiden usw.

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.

Copyright ©2021 PIT Solutions AG. Ein nach ISO 9001:2015 zertifiziertes Unternehmen. Alle Rechte vorbehalten

Imprint

Wir freuen uns, von Ihnen zu hören!

Kontakt

Schweiz
kontakt(at)pitsolutions(dot)ch
+41 43 558 43 60

Indien
contact(at)pitsolutions(dot)com
+91 471 270 0615 / 715

USA
pitsusa(at)pitsolutions(dot)com
+1 425 440 2812

VAE
pitsuae(at)pitsolutions(dot)com
+971 6 558 5598

Copyright ©2021 PIT Solutions AG. Ein nach ISO 9001:2015 zertifiziertes Unternehmen. Alle Rechte vorbehalten

Impressum
Kontaktieren Sie uns!
Nach oben scrollen