Prinzipien und Schlüsselkonzepte der CBA

Diese Abbildung zeigt eine Ansicht der Cell-based Architektur mit Schwerpunkt auf Sicherheit , und kontrollierten Interaktionen zwischen den Zellen. Hier sind die Schlüsselelemente dieser Abbildung:

• Cell-based Architektur (CBA):

  • Die Gesamtstruktur besteht aus einzelnen Zellen , die als Kreise dargestellt sind. Jede Zelle ist eine autonome, isolierte Einheit, was die Resilienz und Sicherheit des gesamten Systems erhöht.

• Kontrollierte Interaktionen:

  • Die Linien , die die Zellen verbinden zeigen mögliche Interaktionen zwischen ihnen an, doch diese Interaktionen werden durch strenge Kontrollen geregelt und in eine Zelle kann nur über die Komponente (Gateway) kommuniziert werden

Eine Zelle ist eine Sammlung von Komponenten , die vom Entwurf und der Implementierung bis zur Bereitstellung gruppiert sind. Eine Zelle ist unabhängig einsetzbar , managefähig und beobachtbar.

Komponenten innerhalb der Zelle können miteinander kommunizieren , indem sie unterstützte Transporte für die Kommunikation zwischen Zellen verwenden. Die externe Kommunikation muss über das „Edge-Gateway oder den Proxy erfolgen, der APIs , Ereignisse oder Datenströme über regulierte Netzwerkendpunkte unter Verwendung von Standard-Netzwerkprotokollen bereitstellt.

In einer Zelle können 1:n Komponenten gruppiert sein. Komponenten innerhalb der Zellen sind wiederverwendbar und können in mehreren Zellen instanziiert werden. Die Zelle sollte ihre Angebote dokumentieren. Die Fähigkeiten einer Zelle müssen netzzugängliche Endpunkte sein. Wenn die Zelle zugriff auf externe Abhängigkeiten benötigt, müssen diese außerdem über Zell-Gateway als Netzwerendpunkte verfügbar gemacht werden. Dieser Endpunkt kann APIs , Ereignisse oder Streams verfügbar machen.

Schnittstellen , die die MIcroservices oder Serverless-Komponenten anbieten, die nicht vom Kontrollpunkt zur Verfügung gestellt werden, sollten von außerhalb der Zelle nicht zugänglich sein. Jede Komponente in der Zelle sollte versioniert sein. Die Zelle sollte einen Namen und eine. Versionskennung haben. Die Versionen sollten sich ändern, wenn sich die Anforderungen und / oder Angebote der Zelle ändern.

Cell Gateway Kommunikation

Die Zellen konsumieren die Funktionalität anderer Zellen unter Verwendung der drei API-Typen (Anfrage-Antwort, Ereignisse und Streams), die von den Zell-Gateways bereitgestellt werden.

Empfehlungen und bewährte Praktiken

Eine Zelle bildet einen begrenzten Kontext, der eine Reihe von Funktionen kapselt, die als Monolith, eine Reihe von Mikroservices, serverlos Funktionen oder eine Kombination davon implementiert sein können.

Jede Zelle ist im Besitz eines Teams. Dieses Team ist für die Entwicklung der Zelle zuständig. In vielen Fällen ist dasselbe Team auch für die Entwicklung der Zelle zuständig. In vielen Fällen ist dasselbe Team auch für die Bereitstellung und die Laufzeit der Zelle verantwortlich.

Die Kommunikation zwischen den Zellen erfolgt über wohldefinierte, versionierte APIs. Zum Beispiel über OpenAPI oder gRPC/Protobuf. Asynchrone Kommunikation zwischen Zellen wird bevorzugt, damit Zellen weiterarbeiten können, wenn ihre abhängigen Zellen nicht verfügbar sind.

Eine Zelle sollte Logik und Daten implementieren. Zumindest muss die Logik eine versionierte Business-API zu diesen Daten bieten, die unabhängig vom Datenspeichermodell ist.

Eine Zelle „besitzt“ alle Daten (sowie die Logik) für ihre Domäne: Nur die besitzende Zelle kann direkt darauf zugreifen, und alle anderen Parteien können nur über die APIs der Zelle auf diese Daten zugreifen. Wenn eine Zelle also Daten benötigt , die sie nicht „besitzt“, muss sie wohldefinierte und versionierte APIs (von anderen Zellen oder externen Quellen) verwenden, um auf diese Datan zuzugreifen. Eine Zelle kann Daten, die sie nicht besitzt, vorübergehend zwischenspeichern.

Eine Zelle kann ihre Daten in einen Data Lake replizieren (z.B. für das Reporting), aber die APIs der Zelle sind immer die primäre Quelle der Wahrheit für ihre Daten.

Eine Zelle muss gesichert werden. Die Mindestsicherung besteht darin , dass der Zelllzugriff über API-Gateways gesteuert wird, die Richtlinien ermöglichen, die steuern, welche anderen Zellen sie aufrufen können. Empfohlen wird jedoch eine Ende-zu-Ende-föderierte Sicherheit mit Identitäten auf Basis Von Token und Zertifikaten.

Eine Zelle sollte als unveränderliche Einheit über einen versionierte DevOps-Prozess bereitgestellt werden können, was Blue-Green-, Canary- und andere Bereitstellungsmuster ermöglicht.

Jede Zelle sollte so konzipiert sein, dass sie unabhängig skalieren kann und Drosselungs- und SLA Richtlinien implementieren kann, die sie vor DoS oder anderen Nachfrageproblemen schützen.

Das interne Kommunikaitonsmodell, die Steuerungsebene, die Datenebene und die Implementierung der Zelle liegen in der Verantwortung des Teams der Zelle.

Die Zellen missachten zyklische Abhängigkeiten, indem sie keine Zellen innerhalb von Zellen haben.

Eine Gruppe von Zellen wird als virtuelle Applikation bezeichnet.

Zellgranularität

Der Entwurf von Systemen hat schon immer einen Ansatz für die Clusterung von Funktionalität erfordert, und es bleibt ein offenes Problem der Informatik - erwarten Sie also keine endgültige Antwort!

Die Anzahl der Komponenten-Komponenten-Verbindungen innerhalb einer Zelle sollte höher sein als die Anzahl, die die Zellgrenze überschreitet. Ein Ansatz wäre daher, die Komponenten anhand der Verbindungen zu clustern.

Andere Ansätze wie z.B. Domain-Driven Design (DDD) können helfen, aber im Grunde ist das Zellenmodell dazu da , Teamgrenzen zu schaffen.

Daher sollte sich die Größe einer Zelle an der Größe , der Verantwortung und dem Output eines Teams orientieren - und die Größe und der Output eines Teams an Teamkonzepten .

Zellbasierte Architektur zielt darauf ab, geschäftsorientierte architektonische Konstrukte zu erstellen, die auf einer höheren Ebene wiederverwendet werden können, daher ist die Organisation der Teams und Zellen um Geschäftsfunktionen herum natürlich unerlässlich.