1. Einführung und Ziele
1.1. Aufgabenstellung
1.1.1. Was ist vNext?
vNext ist der Nachfolger des bewährten ADITUS Framework4. Es stellt eine flexibel anpassbare Software-Plattform zur Abbildung aller Prozesse rund um das Ticketing im Event-Umfeld dar. vNext ist besser in der Lage, der deutlich gestiegenen Anzahl an Kundensystemen und den heterogenen Anforderungen der unterschiedlichen Kunden gerecht zu werden.
1.1.2. Wesentliche Features von vNext
-
Fokus auf fachliche Prozesse
vNext stellt die abgebildeten fachlichen Prozesse in den Mittelpunkt. Hierdurch können vollständige Prozessketten einfacher umgesetzt und Abläufe leichter mit Kundenbedürfnissen in Einklang gebracht werden. -
Fokus auf Schnittstellen und Integrationsfähigkeit
Schnittstellen werden in vNext im frühen Stadium der Umsetzung von Anforderungen berücksichtigt und bereitgestellt. Hierdurch wird die Integration mit Drittdiensten deutlich erleichtert. -
Fokus auf effiziente Ressourcennutzung
Das Event-Geschäft ist Saison-Geschäft. vNext ist durch ein hohes Maß an Skalierbarkeit in der Lage, zur Hochsaison die notwendige Leistung zu erbringen und in der Nebensaison Ressourcen zu sparen. -
Fokus auf die Time-to-Market
Die Struktur von vNext erlaubt es ADITUS neue Features, Fehlerbehebungen und Optimierungen schneller umzusetzen und produktiv einzusetzen. -
Fokus auf Cloud
vNext ist von Beginn für den Betrieb in der Cloud ausgelegt und ist somit geeignet, die vollen Vorteile eines Cloud-Systems auszunutzen. Dennoch ist auch der Betrieb innerhalb der IT-Infrastruktur eines Kunden möglich.
1.2. Qualitätsziele
| Qualitätsziel | Motivation und Erläuterung |
|---|---|
Robustheit |
Registrierung und Einlass stellen Basisprozesse für die Event-Durchführung dar. Daher ist es essenziell, dass die im vNext abgebildeten Prozesse auch zu Last-Zeiten zuverlässig ihren Dienst verrichten. |
IT-Sicherheit |
vNext arbeitet mit sensiblen Personendaten und deren Sicherheit besitzt oberste Priorität. Dies umfasst neben dem Schutz der Daten vor unberechtigtem Zugriff auch die Sicherstellung der Wiederherstellbarkeit dieser wertvollen Informationen. |
Leistungs- und Ressourceneffizienz |
Das Event-Geschäft bringt einen saisonal stark schwankenden Ressourcenbedarf mit sich. Um diesem Bedarf jederzeit gerecht zu werden und gleichzeitig die Kosten in der Cloud begrenzen zu können, legt vNext großen Wert auf eine effiziente Ressourcennutzung und eine dynamische Skalierbarkeit dieser. |
Modifizierbarkeit |
ADITUS hat sich am Markt einen Namen als Innovationsmarktführer erarbeitet. vNext stellt sicher, dass ADITUS diesem Ruf gerecht werden kann, und die Umsetzung von Optimierungen und Features mit einer geringen Time-to-Market möglich ist. |
1.3. Stakeholder
| Rolle | Erwartungshaltung |
|---|---|
GF |
TODO |
2. Randbedingungen
2.1. Technische Randbedingungen
| Randbedingung | Motivation / Erläuterung |
|---|---|
Koexistenz / Integration des Framework4 |
Bei dem Entwurf und der Umsetzung einer neuen Architektur soll weiterhin sichergestellt werden, dass keine bestehenden Funktionalitäten und Daten verloren gehen, wodurch eine Integration des bestehenden Datenbestandes und dem bestehenden Framework4 nötig wird. Eine Integration darf keine negativen Auswirkungen auf den Betrieb und das Kundenerlebnis haben. Die neue Architektur soll das bestehende Framework nicht sofort ablösen, sondern ergänzen. Neue Feature sollen in der neuen Struktur umgesetzt, aber in den bestehenden Abläufen des Framework 4 verwendet werden können. |
Implementierung in bekannten Technologien & Frameworks |
Bevorzugte Technologien sind die - von ADITUS bereits verwendeten Technologien - rund um C# und das .NET Framework. |
Cloudfähigkeit |
Aufgrund der Teilnahme von ADITUS am Microsoft Partner Network ist es zwingend erforderlich immer mehr Ressourcen in der Azure-Cloud zu verwenden, daher eine Cloudfähigkeit des Systems zu jedem Zeitpunkt gewährleistet sein. |
On-Premises Hosting auf einer Windows Infrastruktur |
Üblicherweise werden die Produkte “On-Premises” auf der betrieblichen Infrastruktur von ADITUS gehostet. Die betriebliche Infrastruktur setzt auf Windows-Hostsysteme und muss durch eine neue Architektur unterstützt werden. Auch soll weiterhin die Möglichkeit bestehen, dass Kunden die Anwendungen selbst auf Haus-eigenen Systemen hosten. |
2.2. Organisatorische Randbedigungen
| Randbedingung | Motivation / Erläuterung |
|---|---|
Vorgehensweise |
Der Entwicklungsprozess des Systems erfolgt nach einer iterativen und agilen Arbeitsweise. |
2.3. Konventionen
| Randbedingung | Motivation / Erläuterung |
|---|---|
Architekturdokumentation |
Die Dokumentation der Architektur erfolgt basierend auf dem deutschen arc42-Template und soll fortlaufend aktuell gehalten werden, um die Gründe für Architekturentscheidungen zu jedem Zeitpunkt nachvollziehen zu können. |
Code-Styles & Richtlinien |
Die üblichen Guidelines für Code-Styles der jeweiligen Sprachen sollen angewandt werden. Es soll ein automatisiertes Linting stattfinden. |
Die Umsetzung von Anforderungen erfolgt nach dem API-First-Ansatz |
Wir verwenden den API-First-Ansatz, um … - Schnittstellen auf fachliche Prozesse auszurichten. |
3. Kontextabgrenzung
3.1. Fachlicher Kontext
Das nachfolgende Diagramm beschreibt die fachliche Interaktion zwischen Nutzern und dem vNext-System. Während der Übergangsphase agieren die Nutzer nicht direkt mit dem vNext-System, sondern primär mit dem Legacy-System Framework4, dass letztlich mit dem vNext kommuniziert.
3.1.1. Nutzer
Besucher
Besucher sind Veranstaltungs-Interessierte, die über den Online-Shop ein Ticket kaufen wollen oder bereits durch einen Aussteller eingeladen wurden und einen Gutschein einlösen wollen.
Aussteller
Aussteller kaden u.a. Besucher ein, um diese auf ihren Ausstellungsplatz aufmerksam zu machen, um mit diesen idealerweise ins Geschäft zu kommen.
Veranstalter
Der Veranstalter nimmt die Konfiguration seiner Veranstaltung vor, um u.a. Tickets über einen Online-Shop verkaufen zu können.
3.1.2. Framework4
Das Framework4 ist das aktuelle Ticketing-System von ADITUS und interagiert mit dem vNext-System.
3.2. Technischer Kontext
Der technische Kontext beschreibt die Umgebung des System aus technischer Sicht und wie die unterschiedlichen Systeme miteinander kommunizieren.
3.2.1. Browser
Der Browser ist die clientseitige Anwendung, die es den Nutzern ermöglicht über das HTTP-Protokol mit den Web-Anwendungen zu interagieren.
3.2.2. ADITUS Integration Plattform (ADIP)
Die ADITUS Integration Plattform dient als Adapter zwischen ADITUS-Schnittstellen und Kunden-Schnittstellen und ermöglicht somit eine Integration von Dritt-Anbietern in die ADITUS Systeme. Die Integration erfolgt durch den ADIP als Aufrufer der vNext-Schnittstellen.
3.2.3. Framework4
Das Framework4 ist das aktuelle Ticketing-System von ADITUS, dass durch das vNext-System erweitert und langsam abgelöst werden soll, wodurch es direkt mit dem vNext-System über die vNext-Schnittstellen kommuniziert.
3.2.4. Fremdsysteme
SendGrid (Schnittstelle)
SendGrid ist ein externes System, dass vom vNext mittels HTTP-Schnittstelle angesprochen wird, um E-Mails zu verschicken. Durch die Verwendung von SendGrid soll das Tracking und Fehlerhandling der versendten E-Mails ausgelagert werden.
4. Lösungsstrategie
| Qualitätsziel | Szenario | Lösungsansatz | Link |
|---|---|---|---|
Plattform |
|||
Sicherheit |
|||
Auswertbarkeit |
|||
Anpassbarkeit |
|||
Wartbarkeit |
5. Bausteinsicht
5.1. Whitebox Gesamtsystem
<Übersichtsdiagramm>
- Begründung
-
<Erläuternder Text>
- Enthaltene Bausteine
-
<Beschreibung der enthaltenen Bausteine (Blackboxen)>
- Wichtige Schnittstellen
-
<Beschreibung wichtiger Schnittstellen>
5.1.1. <Name Blackbox 1>
<Zweck/Verantwortung>
<Schnittstelle(n)>
<(Optional) Qualitäts-/Leistungsmerkmale>
<(Optional) Ablageort/Datei(en)>
<(Optional) Erfüllte Anforderungen>
<(optional) Offene Punkte/Probleme/Risiken>
5.1.2. <Name Blackbox 2>
<Blackbox-Template>
5.1.3. <Name Blackbox n>
<Blackbox-Template>
5.1.4. <Name Schnittstelle 1>
…
5.1.5. <Name Schnittstelle m>
5.2. Ebene 2
5.2.1. Whitebox <Baustein 1>
<Whitebox-Template>
5.2.2. Whitebox <Baustein 2>
<Whitebox-Template>
…
5.2.3. Whitebox <Baustein m>
<Whitebox-Template>
5.3. Ebene 3
5.3.1. Whitebox <_Baustein x.1_>
<Whitebox-Template>
5.3.2. Whitebox <_Baustein x.2_>
<Whitebox-Template>
5.3.3. Whitebox <_Baustein y.1_>
<Whitebox-Template>
6. Laufzeitsicht
6.1. <Bezeichnung Laufzeitszenario 1>
-
<hier Laufzeitdiagramm oder Ablaufbeschreibung einfügen>
-
<hier Besonderheiten bei dem Zusammenspiel der Bausteine in diesem Szenario erläutern>
6.2. <Bezeichnung Laufzeitszenario 2>
…
6.3. <Bezeichnung Laufzeitszenario n>
…
7. Verteilungssicht
7.1. Infrastruktur Ebene 1
7.2. Infrastruktur Ebene 2
7.2.1. <Infrastrukturelement 1>
<Diagramm + Erläuterungen>
7.2.2. <Infrastrukturelement 2>
<Diagramm + Erläuterungen>
…
7.2.3. <Infrastrukturelement n>
<Diagramm + Erläuterungen>
8. Querschnittliche Konzepte
8.1. Deployment
Das Deployment der Systems lässt sich in unterschiedliche Bestandteile aufteilen:
8.1.1. Deployment notwendiger DevOps-Infrastruktur <<DevOps>>
-
umfasst notwendige Komponenten, die als Grundlage für einen effizienten DevOps-Prozess notwenig sind.
-
Existiert nur einmal für mehrere Environments / Hosting Umgebungen
-
Deployment von Ressourcen innerhalb der Azure Cloud
-
Templating nötiger Infrastruktur-Ressourcen mittels Bicep (Infrastructure-as-Code)
-
Automatisierte Bereitstellung einer Container-Registry und einer zentralisierten Monitoring-Lösung
-
-
Ausführung erfolgt mittels CI/CD-Pipeline in Azure DevOps
8.1.2. Deployment des Kubernetes Clusters <<Environment>>
-
Bereitstellung der physischen Ressourcen in der Azure Cloud
-
Verwendung von Bicep als Infrastructure-as-Code-Lösung
-
Automatisierte Bereitstellung eines Kubernetes Clusters
-
Kann mehrere Systeme umfassen, die durch Namspaces getrennt sind
-
Ausführung erfolgt mittels CI/CD-Pipeline in Azure DevOps
8.1.3. Deployment eines Systems <<System>>
-
Beschreibt Gesamtheit mehrerer Services
-
Deployment innerhalb des Kubernetes Clusters mittels Helm-Chart
-
stellt notwendige Komponenten für die Services zur Verfügung (z.B. eine Message Queue)
-
Ausführung erfolgt mittels CI/CD-Pipeline in Azure DevOps
8.1.4. Deployment der Services <<Service>>
-
Bereitstellung eines Services erfolgt unabhängig von anderen Services
-
Ein Service wird als Docker-Container zur Verfügung gestellt, der aus der Container-Registry geladen wird
-
Deployment erfolgt innerhalb des Kubernetes Clusters mittels Helm-Package
-
Build des Containers und Deployment des Helm-Packages erfolgt mittels CI/CD-Pipeline in Azure DevOps
8.2. Versionierung
Die Versionierung basiert auf Semantic Versioning 2.0.
Die Version wird wie folgt hochgezählt
Major |
Manueller eingriff über Commit-Kommentare. Zeichenfolge "+semver:major" muss im Kommentar vorhanden sein. |
Minor |
Wird hochgezählt pro Pull-Request auf dem main-Branch. |
Patch |
Wird innerhalb eines Pull-Requests pro Commit hochgezählt. |
Als Hilfsmittel wird GitVersion verwendet.
Nachfolgend die Default GitVersion.yml Datei, die für alle weiteren Services genutzt werden soll.
Default GitVersion.yml
mode: mainline
major-version-bump-message: '\+semver:\s?(breaking|major)'
minor-version-bump-message: '\+semver:\s?(feature|minor)'
patch-version-bump-message: '\+semver:\s?(bug|patch)'
commit-message-incrementing: Enabled
assembly-versioning-scheme: MajorMinorPatch
assembly-file-versioning-scheme: MajorMinorPatchTag
assembly-informational-format: '{LegacySemVer}'
branches:
master:
regex: main
increment: Minor
tag: ''
is-mainline: true
feature:
regex: ^feature\/\d*
increment: Patch
tag: RC
track-merge-target: false
tracks-release-branches: false
hotfix:
regex: ^bug\/\d*
increment: Patch
tag: RC
track-merge-target: false
tracks-release-branches: false
pull-request:
regex: ^(pull|pull\-requests|pr)[/-]
tag: PR
increment: Inherit
tag-number-pattern: '[/-](?<number>\d+)[-/]'
track-merge-target: true
tracks-release-branches: false
is-release-branch: false9. Architekturentscheidungen
9.1. ADR 0: Microservices als Architekturstil
Datum |
01.06.2022 |
Status |
Angenommen |
Autor |
|
Mitwirkende |
9.1.1. Kontext & Problemstellung
-
vNext dient als Plattform zur Abbildung vielfältiger, autarker Ticketing-Prozesse.
-
Kunden von ADITUS benötigen häufig nur eine Teilmenge der abgebildeten Prozesse.
-
Im monolithischen Legacy-System traten häufig unerwünschte Seiteneffekte bei der Anpassung einzelner Prozesse auf.
-
Erweiterungen und Korrekturen an einzelnen Prozessen müssen gerade im Event-Betrieb schnell bereitgestellt werden können.
9.1.2. Entscheidung
Verwendung von Microservices, um …
-
fachliche Prozesse strikt voneinander zu trennen.
-
einzelne fachliche Anforderungen komplett unabhängig entwickeln und in Betrieb zunehmen.
-
Bereitstellung einzelner Komponenten zu ermöglichen.
-
höhere Wartbarkeit und einfachere Erweiterbarkeit von einzelnen Funktionalitäten & Prozessen
-
kundenspezifische Anforderungen ohne Auswirkungen auf das Standardprodukt implementieren zu können.
9.1.3. Konsequenzen
-
Querschnittsfunktionalitäten müssen mehrfach ggf. implementiert werden.
-
Microservices gehen, durch deren Definition, mit einer redundanten Datenhaltung einher.
-
Die Komplexität des Betriebs insbesondere des Hostings ist höher als bei den Alternative.
9.1.4. Alternativen
Monolitische Architektur:
-
Bekannte Problemen in der aktuellen Anwendungen
-
Höherer Ressourcen-Verbrauch durch hohe Abhängigkeiten
-
Höheres Risiko für neue Abhängigkeiten
9.2. ADR 1: Containerisierung der System-Komponenten
Datum |
01.06.2022 |
Status |
Angenommen |
Autor |
|
Mitwirkende |
9.2.1. Kontext & Problemstellung
-
Viele unabhängige Services mit unterschiedlichen Infrastruktur Abhängigkeiten.
-
Host-Systeme müssen alle Abhängigkeiten sämtlicher dort gehosteten Services zur Verfügung stellen.
-
Randbedingung: Cloudfähigkeit des System.
-
Randbedingung: OnPremises Hosting in eigenen Infrastrukturen.
9.2.2. Entscheidung
Bereitstellung von System-Komponenten als Container, um …
-
alle Abhängigkeiten der Komponenten dirket mitzuliefern und somit die Anwendung von der Infrastruktur zu trennen.
-
Die Host-Systeme unabhängig der betriebenen Komponenten zu halten
-
Cloud- und OnPremises-Betrieb zu ermöglichen.
9.2.3. Konsequenzen
-
3rd-Party-Komponenten können innerhalb eines Container-Umfelds unabhängig des Host-Systems ausgewählt werden.
-
Hosting Containern können ein Zero-Downtime-Deployment ermöglichen.
-
Anbindung einer zentralen Container-Registry zur Verwaltung der Container nötig.
-
Die Container-Images müssen fortlaufend auf Sicherheitsprobleme geprüft werden und aktuell gehalten werden.
9.3. ADR 2: Container Orchestration
Datum |
01.06.2022 |
Status |
Angenommen |
Autor |
|
Mitwirkende |
9.3.1. Kontext & Problemstellung
-
Container- & Microservice-Umfeld
-
Hohe Skalierbarkeit des Systems notwendig
-
Effiziente Ressourcen-Nutzung im Saison-Geschäft
9.3.2. Entscheidung
Nutzung von Kubernetes zur Orchestration der Container, um …
-
Container auszuführen.
-
Deployments (automatisch) zu skalieren und die Skalierbarkeit zu vereinfachen.
-
den Idealzustand des Systems nachvollziehbar zu beschreiben.
-
die Kommunikation zwischen einzelnen System-Komponenten zu steuern.
-
einen Betrieb innerhalb der Cloud und OnPremises zu ermöglichen.
-
einfaches LoadBalancing zu ermöglichen.
9.3.3. Konsequenzen
-
Zero-Downtime-Deployments können mittels Kubernetes ermöglicht werden.
-
Die Hosting-Umgebung ist "Cloud-Native"
-
Hoher Wartungsaufwand für den Betrieb des Kubernetes-Clusters
-
Die Komplexität eines Kubernetes Clusters ist hoch
9.3.4. Alternativen
Docker Swarm
Es wurde sich gegen Docker Swarm entschieden, da …
-
die Unterstützung von Unix-Container auf Windows-Host-Systemen zum Entscheidungszeitpunkt nicht verfügbar war.
-
eine gleichzeitige Bereitstellung von Windows- und Linux-Nodes nicht möglich war.
-
nicht besonders gut für den produktiven Einsatz geeignet ist.
-
Docker Swarm Deployments in der Cloud nicht üblich / verbreitet sind.
9.4. ADR 3: Eventbasierte Kommunikation
Datum |
27.06.2022 |
Status |
Angenommen |
Autor |
|
Mitwirkende |
9.4.1. Kontext & Problemstellung
-
Fachliche Prozesse sollen in den Mittelpunkt gestellt werden.
-
Abläufe sollen an Kundenbedürfnisse angepasst werden können.
-
Asychrone Prozesse, die aufeinander aufbauen und bei denen verschiedene Personengruppen involviert sind, müssen abgebildet werden.
-
Abhängigkeiten zwischen Microservices sollen gering gehalten werden.
9.4.2. Entscheidung
Wir berücksichtigen bei der Modellierung der fachlichen Domäne sämtliche fachlichen Ereignisse und implementieren diese innerhalb der Software mit einer eventbasierten Architektur, die es möglich machen soll, dass …
-
asychrone Prozess abgebildet werden können.
-
Prozesse über Ereignisse miteinander verkettet werden, ohne eine harte Abhängigkeit zu schaffen.
Die Events werden über eine Message Queue kommuniziert und können somit von allen anderen Services des Systems verarbeitet werden, sodass keine direkte Abhängigkeit zwischen den Services besteht.
9.4.3. Konsequenzen
-
Höhere Komplexität aufgrund der losen Kopplung durch nicht nachvollziehbare Aufruf-Traces
-
Keine automatisierte Überprüfung möglich, ob Events implementiert wurden.
-
Ein eventbasierter Kommunikationsansatz kann eine erste Grundlage für die Bereitstellung von Webhooks sein.
9.5. ADR 4: Integration mit dem Framework4
Datum |
07.06.2022 |
Status |
Angenommen |
Autor |
|
Mitwirkende |
9.5.1. Kontext & Problemstellung
-
Koexistenz mit dem Framework 4 nötig, solange dies nicht vollständig abgelöst ist.
-
Konsistenz der Datenbestände von identischen Datensätzen soll über beide Systeme hinweg gewährleistet werden.
9.5.2. Entscheidung
Wir implementieren einen Dienst im Framework4, der mittels Message Queue auf Ereignisse des vNext-Systems reagieren kann und somit fachliche Domänenänderungen im Framework4 persistieren kann. Der Zugriff des Framework4 auf die Message Queue wird auf lesenden Zugriff beschränkt.
Um Daten gezielt an das vNext zu übertragen oder Daten gezielt abzurufen kann das Framework4 die Standard-Endpunkte der API des vNext verwenden.
Durch diese Kommunikations- und Integrationswege bleibt das vNext unabhsängig vom Legacy-System.
9.5.3. Konsequenzen
-
Ereigniss-Strukturen des vNext müssen mit dem Framework4 geteilt werden.
-
Durch die asynchrone Kommunikation mittels Message Queue kann es zu einer "Eventual Consistency" kommen.
-
Wir müssen die Message Queue eines vNext-Systems für das Framework4 erreichbar machen.
-
Integration der Systeme erhöht das Risiko, dass …
-
das Legacy-System nie vollständig abgelöst wird.
-
durch den entitätsgetriebenen Ansatz des Framework4 der Fokus auf die Prozesse im vNext verloren geht.
-
9.5.4. Betrachtete Möglichkeiten
9.5.5. Implementierung eines Integrations-Services
| Service im Framework 4 | Service im vNext | Service in beiden Systemen | |
|---|---|---|---|
Integrationsaufwand |
+ Weniger Aufwand durch einseitige Integration |
+ Weniger Aufwand durch einseitige Integration |
- erhöhter Aufwand durch beidseitige Integration |
Systemabhängigkeiten |
+ vNext ist ohne Abhängigkeit zum Framework 4 ⇒ Komponenten sind auch ohne Framework4 nutzbar |
- Framework vNext muss das Framework4 kennen - Framework vNext müsste Entitäten aus dem Framework4 kennen und diese auf Prozesse mappen - u.U. mehrere unterschiedliche F4-Versionen, die angebunden werden müssen (bei Multimandantenfähigkeit) |
- bidirektionale Abhängigkeit zwischen den Systemen - u.U. mehrere unterschiedliche F4-Versionen, die aus dem vNext angebunden werden müssen |
Zukunftsfähigkeit |
+ Neue Design-Paradigmen können im Framework vNext konsequent umgesetzt werden + Framework4 kann schrittweise ab- und aufgelöst werden, ohne Spuren im Framework vNext zu hinterlassen + Im Framework vNext werden Schnittstellen und Lösungen geschaffen, die auch von (anderen) Fremdsystemen genutzt werden können + Prozessorientierung wird im Integration-Services des Framework4 umgesetzt. (Mapping von Entitäten auf Prozesse) - aktive Weiterentwicklung des Framework4 ⇒ Gefahr der Nicht-Ablösung - Entwickler müssen zwischen alter und neuer Architektur wechseln - Könnte ggf. die Verwendung von neuen Technologien blockieren, wenn diese nicht von .NET 4.7 / 4.8 unterstützt. |
- Entwicklung des Framework vNext muss stärker Rücksicht auf die Strukturen des Framework4 nehmen - erhöhte Gefahr, dass Framework4 zu einem “Legacy-Bestandteil” des Framework vNext wird - fachliche Prozesse im Framework vNext müssen auf die Entitäten des Framework4 gemappt werden + Entwicklung des Framework4 kann im besten Fall unmittelbar eingestellt werden bzw. auf Bug-Fixes reduziert + Entwickler können sich auf neue Architektur fokussieren + Technologiefreiheit bei der Implementierung des Integration-Services |
- weist die Nachteile beider Einzelintegrationen auf |
9.5.6. Betrachtete Kommunikationsmöglichkeiten für den Datenaustausch
| Message Queue | Webhooks | HTTP / GRPC | Datenbank-Sychronisation | |
|---|---|---|---|---|
Austausch-Richtung |
bi-direktional |
Sender → Empfänger (kann in beide Richtungen implementiert werden) |
Sender → Empfänger (kann in beide Richtungen implementiert werden) |
Sender → Empfänger (kann in beide Richtungen implementiert werden) |
Prozess-Orientierung |
Kommunikation durch Aktionen / Events ausgelöst (Prozessorientiert) |
Kommunikation durch Aktionen / Events ausgelöst (Prozessorientiert) |
Kann Prozess- und Entitätsorientiert sein. (Stärker entitätsgetrieben) |
Synchronisation ist entitätsgetrieben |
Kopplung |
Lose Kopplung |
Einseitige, feste Kopplung |
Einseitige, feste Kopplung |
Einseitige, feste Kopplung |
Vorteile |
- lose Kopplung der Systeme - Systeme können sich nicht gegenseitig blockieren - Empfänger können sofort auf Aktionen & Events des sendenden Systems reagieren |
- Empfänger können sofort auf Aktionen & Events des sendenden Systems reagieren |
- Prozesse können explizit im Fremd-System angestoßen werden - Daten können gezielt synchron geladen werden, wenn diese gebraucht werden - Höhere Konsistenz der Daten durch synchrone Kommunikation und gezieltes Laden von bestimmten Daten |
-Synchronisation von großen Datenmengen möglich |
Nachteile |
- Fremdsysteme müssen die Aktionen & Events explizit kennen - Daten können nicht bei Bedarf aus dem Fremdsystem geladen werden - “Eventual Consistency” |
- Konfiguration von direkten Endpunkten nötig. (Feste Kopplung) - Eignet sich nur zur Übermittelung von Daten (schreibender Zugriff nicht vorgesehen) - “Eventual Consistency” |
- Feste Kopplung zum Fremdsystem |
- Datenbanken der Fremdsysteme müsse aufeinander abgestimmt werden. (Feste Kopplung) - Datenbanken kennen die fachlichen Prozesse nicht - Schwierig, wenn unterschiedliche Datenbank-Systeme im Einsatz sind - “Eventual Consistency” |
9.6. ADR 5: Datenspeicherung und -Sicherung der Microservices
Datum |
01.06.2022 |
Status |
In Arbeit |
Autor |
|
Mitwirkende |
9.6.1. Kontext & Problemstellung
-
vNext verfolgt den Microservice-Architekturstil, der vorsieht, dass …
-
jeder Service seinen eigenen Datenspeicher hat.
-
nicht jeder Service das selbe Datenbanksystem verwendet.
-
Berücksichtung des BAC-Theorems notwendig
-
-
Hohe Anforderungen an IT-Sicherheit und Ausfallsicherheit des Systems.
-
Wiederherstellbarkeit von Daten notwendig
-
Konsistenz der Backups muss gewährleistet werden.
-
-
bestehendes Backup-Konzept des Legacy-System bereits vorhanden, implementiert und etabliert.
-
sichert komplette SQL-Datenbank eines Systems automatisiert.
-
9.6.2. Entscheidung
Wir speichern die Daten der unterschiedlichen Microservices in einer gemeinsamen Datenbank, jedoch durch Schemta im SQL-Server getrennt, um …
-
das etablierte Backup-Konzept weiterzuverwenden.
-
ein konsistentes Backup bei durchgängiger Verfügbarkeit des Systems während des Sicherungsprozess zu gewährleisten.
-
die Komplexität und den Ressourcen-Aufwand der Datensicherung gering zu halten.
9.6.3. Konsequenzen
-
Wir velieren die Flexibilität bei der Auswahl des Datenbanksystems.
-
Es muss sichergestellt werden, dass die Microservices nur auf ihre eigenen Datenspeicher zugreifen können.
9.6.4. Alternativen
Getrennte Speicher und isolierte Backups pro Service
-
Jeder Service besitzt seine eigene Datenbank unabhängig eines vorgegeben Datenbanksystems.
-
Wir sichern jede Datenbank unabhängig voneinander.
-
Dies würde jedoch zu einer Inkonsistenz führen, da die Backups möglicherweise zu unterschiedliche Zeitpunkten gesehen würden.
-
Die unterschiedlichen Datenbanktypen würde auch unterschiedliche Backup-Prozesse voraussetzen, womit eine höherer initialer Implementierungsaufwand einhergeht
Getrennte Speicher, aber synchronisierte Backups für alle Service
-
Jeder Service besitzt seine eigene Datenbank unabhängig eines vorgegeben Datenbanksystems.
-
Der Backup-Prozess würde für alle Services parallel durchgeführt werden.
-
Damit jedoch hierbei keine Inkonsistenzen entstehen, dürfen während des ganzen Prozesses keine Daten geschrieben werden, was letztlich zu einer Einschränkung des Systems im Bereich der Verfügbarkeit führen würde.
“Monitor Worker und Monitor Master”-Pattern
-
Ein zweites System wird für den Deaster-Fall in einem anderen Rechenzetraum redundant deployt.
-
Die Datenbank zwischen den beiden Systemen werden dabei regelmäßig synchronisiert.
-
In einem Ausfall der primären Rechenzentrums, wären die Daten noch im zweiten Rechenzentrum vorhanden und per DNS wird der Betrieb auf das zweite Rechenzentrum umgeleitet.
-
Dieser Ansatz wäre mit einer sehr hohen Komplexität und großem Aufwand verbunden.
Event-Sourcing
-
Beim Event-Sourcing gibt es eine große zentrale Datenbank, die alle im System aufgetretenen Events speichert.
-
Basierend auf den Events werden die Datenbanken der einzelnen Microservices aktualisiert, die quasi eine spezielle Sicht auf die Events darstellt.
-
Die Datenbank kann basierend auf den Events aus der zentralen Datenbank zu jedem Zeitpunkt vollständig neu aufgebaut werden, wodurch eine Sicherung der Microservice-Datenbank nicht notwendig ist.
-
Die Sicherung des Event-Datenbank kann zu jedem Zeitpunkt ohne Nachteile der Konsistenz oder der Verfügbarkeit des Systems erfolgen.
-
Event-Sourcing geht mit einem hohen Aufwand einher und geht bei der Integration mit einem Legacy-System, das selbst nicht den Event-Sourcing-Ansatz verfolgt, mit einer hohen Komplexität und Herausforderung einher.
9.7. ADR-6: Implementierung eines API-Gateways
Datum |
30.06.2022 |
Status |
Angenommen |
Autor |
|
Mitwirkende |
9.7.1. Kontext & Problemstellung
-
vNext-System besteht aus mehreren Services mit jeweils eigenen Schnittstellen, die das gesamte System repräsentieren.
-
Schnittstellen-Konsumenten müssten alle einzelnen Services kennen, wodurch die Integrationsfähigkeit des System verringert wird.
-
Microservices können nicht einfach ersetzt werden, da es möglicherweise nicht sichtbare Schnittstellen nach außen gibt, wenn die Service-Schnittstellen direkt nach außen gegeben werden.
9.7.2. Entscheidung
Wir implementieren ein API-Gateway, das alle Teil-Schnittstellen bündeln, um …
-
die komplexe Architektur des Systems nach außen zu verstecken (Information Hiding).
-
den Konsumenten eine zentrale Schnittstelle zur Verfügung zustellen.
-
grundlegende API-Funktionalitäten zur Verfügung stellen, die nicht in jedem Service erneut implementiert werden sollen.
Wir nutzen als API-Gateway nginx um die angekommenden Requests an die unterschiedlichen Services weiterzuleiten. Weitere Funktionalitäten übernimmt das Gateway erstmal nicht.
9.7.3. Konsequenzen
-
Änderungen an Service-Schnittstellen machen u.U. eine Anpassung im API-Gateway notwendig.
-
Die Implementierung des API-Gateways kann ggf. zu leicht höheren Antwortzeiten führen.
10. Qualitätsanforderungen
Siehe Qualitätsanforderungen in der online-Dokumentation (auf Englisch!).
10.1. Qualitätsbaum
10.2. Qualitätsszenarien
11. Risiken und technische Schulden
11.1. Technische Schulden
| Risiko | Bewertung | Maßnahmen |
|---|---|---|
Fehlendes Fachwissen für verwendete Technologien |
Durch den Einsatz von möglichen neuen Technologien bei der Umsetzung der Architektur, sind ggf. wenige bis viele Komponenten den Mitarbeitern nicht bekannt. |
Gezielte Schulungen im Bereich IT/Software |
11.2. Verwendung von Microservices
| Risiko | Bewertung | Maßnahmen |
|---|---|---|
Hohe Komplexität durch viele Services |
Durch die stärkere Aufteilung der Software in mehrere Dienste, ggf. bis hin zu Dienst pro Prozess, erhöht sich die Komplexität wesentlich. Risiko ist, dass die Übersicht verloren geht und Prozesse nicht mehr gezielt zentral verwaltet werden, sondern in mehrere Dienste verteilt werden und somit die Architektur gebrochen wird. Weiteres Risiko ist die Kommunikation zwischen den verschiedenen Diensten. Es muss sichergestellt werden, dass keinerlei Anfragen von Dienst zu Dienst verloren gehen, oder die Dienste so konzipiert sind, dass diese auch mit teilhaften bzw. unvollständigen Prozessen umgehen können. |
Strukturierte zentrale Übersicht über vorhandene Services und deren Prozesse. Fortlaufende Dokumentation aller Services und Prozesse. Verwendung zentralisierter Komponenten zum Übertragen von Nachrichten. |
Verwendung von Container-Lösungen |
Die Verwendung von Container-Lösungen, z.B. Docker/Kubernetes, ist für ADITUS eine neue Herangehensweise, die so vorher so nie verwendet wurde. Neben der Verwendung im produktiven Umfeld, wird diese Lösung auch während der Entwicklungszeit und innerhalb der Dev-Ops Prozesse genutzt. Dieses Risiko entspricht auch einer technischen Schuld. |
Gezielte Schulungen im Bereich IT/Software. Aufsetzen einer isolierten Testumgebung, die einer produktiven Umgebung gleicht. |
Monitoring und Tracing |
Bei der Verwendung von Microservices innerhalb einer Container-Lösung erhöht dies die Komplexität im Bereich Monitoring und Tracing. Anfragen, die über verteilte Dienste laufen, müssen für ein Monitoring transparent als ein zusammenhängender Aufruf dargestellt werden. Risiko ist, bei der Fehleranalyse den Überblick zu verlieren und das Abläufe nicht mehr korrekt im Zusammenhang gebracht werden können. |
Verwendung von zentralisierten skalierbaren Monitoring-Systemen |
11.3. Verwendung von getrennten Dankenbanken
| Risiko | Bewertung | Maßnahmen |
|---|---|---|
Eigene Datenbank pro Microservice |
Bei der Verwendung getrennter Datenbanken entsteht das Risiko fehlender Datenkonsistenz. Es muss sichergestellt werden, dass Prozesse über verteilte Datenbanken die Daten transaktionssicher schreiben, um Inkonsistenzen zu vermeiden. |
Sicherstellten, dass verteilte Prozesse alle Daten innerhalb einer Transaktion modifizieren, oder das Prozesse autark voneinander sind und dementsprechend keine verteilten Transaktionen benötigen. |
11.4. Integration in das bestehende Framework4
| Risiko | Bewertung | Maßnahmen |
|---|---|---|
Anbindung alter Architektur an neuer Architektur |
Es muss sichergestellt sein, dass die technischen Möglichkeiten der Anbindung gegeben sind. Risiko ist, dass ggf. die neue Architektur von der alten nicht oder nicht vollständig angesprochen werden kann. |
Verwendung von Technologien, die auch für das vorhandene Framework4 Komponenten zur Kommunikation anbieten. |
Schrittweise Migration bestehender Prozesse |
Es muss sichergestellt sein, dass neu geschaffene Prozesse so gestaltet sind, dass diese keinen Einfluss auf vorhandene Prozesse haben. Das Risiko hierbei ist, dass neu geschaffene Prozesse vorhandene Prozesse beeinflussen oder vice versa und somit inkonsistente Zustände im System verursachen könnten. |
Genaue Dokumentation vorhandener Prozesse und innerhalb in welchem System diese ausgeführt werden. Sofortiges Entfernen “alter” Prozesse aus dem Legacy-System. |
Datenaustausch mit der Legacy-Anwendung |
Es muss sichergestellt werden, dass die Legacy-Anwendung auf benötigte Daten im Framework vNext zugreifen kann. Hier bei muss beachtet werden, dass das Framework4 über aussreichende Berechtigungen verfügt um die Informationen abzurufen. |
12. Glossar
| Begriff | Definition |
|---|---|
<Begriff-1> |
<Definition-1> |
<Begriff-2 |
<Definition-2> |
Über arc42
arc42, das Template zur Dokumentation von Software- und Systemarchitekturen.
Erstellt von Dr. Gernot Starke, Dr. Peter Hruschka und Mitwirkenden.
Template Revision: 8.0 DE (asciidoc-based), Februar 2022
© We acknowledge that this document uses material from the arc42 architecture template, https://arc42.org.