Wie sich nyssr.net von REST und JMS unterscheidet

nyssr.net unterscheidet sich von konventionellen Microservice-Architekturen darin, wie Dienste kommunizieren, sich durchs Netz bewegen und sich weiterentwickeln.

Kommunikation ist mehrgerichtet

Nachrichten laufen nicht nur von A nach B und zurück. Ein Dienst kann einen Request weiterleiten, einen anderen Dienst auf einem anderen Knoten einbeziehen, Notifications senden oder an viele Empfänger broadcasten. Jeder Dienst erledigt seine Arbeit unabhängig und asynchron.

Handshakes, Responses, Weiterleitung und zurückgestellte Verarbeitung sind normale Nachrichtenmuster statt Sonderinfrastruktur.

Objekte kommunizieren direkt

Nachrichten werden von einer Objektinstanz zu einer anderen gesendet. Ein Dienst kann viele Targets hosten, als Client anderer Dienste auftreten, Notifications empfangen, auf Broadcasts antworten und bei Bedarf weitere Instanzen erzeugen.

Es gibt keine Vorgabe, jede Interaktion als festen HTTP-Endpunkt, als Queue oder Topic zu modellieren.

Zustellung ohne neue Verbindung

Nachrichten laufen über bereits etablierte Knotenkanäle. Existiert der Empfänger, wird die Nachricht direkt zugestellt; andernfalls erhält der Absender einen Fehlercode. Routen können sich ändern, während das Mesh Verbindungskosten und Ausfälle beobachtet.

Das vermeidet eine neue Verbindung pro Nachricht und unterstützt trotzdem Knoten in Clouds, Büros und privaten Netzwerken.

Kernidee: Das Netz ist ein lebendiger Kommunikationsverbund, keine Ansammlung isolierter Request-Endpunkte.

Dienste über Konfiguration ausrollen

Das Knotenprogramm bleibt generisch. Geschäftssoftware wird als Plugin geladen, daher kann ein Container-Image unterschiedliche Knotenrollen über seine Plugin-Liste und eingebundene Konfiguration bedienen.

Die Änderung der Liste ist zugleich ein praktischer Rollback-Mechanismus: eine frühere Konfiguration wiederherstellen und den Knoten neu starten, statt jedes Image neu zu bauen.

Mehr als ein Dienst pro Knoten

Ein Knoten kann viele Dienste hosten — begrenzt durch seine Ressourcen, nicht durch eine Ein-Container-pro-Dienst-Regel. Ein neuer Dienst erfordert kein neues Image, und die Dienstplatzierung kann sich ändern, ohne die Client-Anwendung anzufassen.

Ein produktives Entwicklungsmodell

Während der Entwicklung kann das komplette System auf einem Knoten laufen. Bei Bedarf kommen mehrere Knoten hinzu, ohne das Programmiermodell zu ändern. Dieselben Nachrichten und Service-IDs funktionieren lokal und über das Mesh.

Entwicklung: Mit einem Knoten beginnen und ausbauen, wenn die Architektur es verlangt.

Deployment: Das Knoten-Image generisch halten und Verhalten über Plugins variieren.

Weiterentwicklung: Dienste und Nachrichtenfelder ergänzen, ohne alle Komponenten gleichzeitig zu aktualisieren.