Eine selbst betriebene Runtime für ungewöhnliche Service-Topologien

Manche Anwendungen passen nicht in eine einfache Topologie mit einem Dienst pro Container: Dienste müssen nahe an lokalen Systemen bleiben, sich eine Runtime teilen oder zwischen Knoten wandern, ohne ihre Aufrufer zu ändern. nyssr.net ist für diese Fälle entworfen.

nyssr.net ist ein Netzwerk verbundener Java-Knoten. Nachrichten fließen über TCP-Kanäle zwischen ihnen — kein zentraler Server, kein manuelles Routing, kein Single Point of Failure.

Ein kleines Knotennetzwerk mit Mond-/Planeten-Namen als ID.

Ein Knoten, kein Container

Jeder Knoten betreibt einen Micro-Kernel, der Funktionen beim Start als Plugins lädt. Sogar TCP und die Transportschicht sind Plugins — alles, was nicht hart verdrahtet ist, lässt sich austauschen oder ersetzen.

Ein einzelner Knoten kann hunderte Plugins hosten. Um einen neuen Microservice auszurollen, nimmt man ihn in die Plugin-Liste auf. Um ihn zu entfernen, nimmt man ihn heraus.

Ein Knoten kann Dienste, Anwendungen und Transportfunktionen als Plugins hosten.

Objekte, keine Adressen

Jeder Code kann eine Nachricht senden, aber nur registrierte Objekte, sogenannte Targets, können eine empfangen. Jedes Target erhält eine netzweit eindeutige Adresse.

Anwendungen müssen diese Adressen nicht selbst verwalten. Eine Transportschicht registriert Microservices unter einfachen IDs wie database statistics. Sendet man eine Nachricht an diese ID, routet das System sie zu einer arbeitsfähigen Instanz, wo auch immer sie läuft.

Nachrichten werden über IDs geroutet, nicht über Adressen.

Nutzen mehrere Instanzen dieselbe ID, wählt die Registry eine aus — Load Balancing ist eingebaut. Kein zusätzlicher Service Mesh und keine Konfiguration nötig.

Kernidee: Einen Microservice hinzufügen kostet einen Funktionsaufruf oder eine Nachricht. Er kann innerhalb weniger Minuten nutzbar sein.

Entworfen für viele kleine Dienste

nyssr.net ist darauf ausgelegt, hunderte kleine Dienste ohne Konfigurationsaufwand zu hosten. Dienste lassen sich unabhängig voneinander schreiben, ausrollen und warten.

• Unabhängige APIs lassen Clients und Dienste mit unterschiedlicher Geschwindigkeit weiterentwickeln
• Ein Dienst kann auf jedem Knoten laufen — Clients müssen nicht wissen, wo
• Redundanz liefert Skalierung und Fehlertoleranz
• Keine Topics oder Queues müssen konfiguriert werden
• Nachrichten können an ein oder mehrere Ziele im Netz zugestellt werden
• Responses sind standardmäßig verfügbar, sofern nicht explizit abgeschaltet

Betrieb: Knoten für Kapazität ergänzen, Plugin-Listen für Konfiguration nutzen und um ausgefallene Knoten herum routen.