Skalierbarkeit

Es gibt viele Einsatz-Szenarien, bei denen ein einzelner Rechner zur Bewältigung seiner Aufgabe nicht ausreicht. Meist ist der Grund eine hohe Zahl an Benutzern, die in einer gegebenen Zeitspanne auf das Programm oder die Website zugreifen.

Die Lösung in diesem Fall ist oft die Verteilung der Last auf viele Rechner. Zudem ist es oft auch billiger, eine große Anzahl an billigen Komponenten zu nutzen als eine mega-teure Maschine - vorausgesetzt eine Verteilung ist von der bestehenden Software aus realisierbar.

Das Design der Software sollte hier schon in einem frühen Stadium auf eine spätere Verteilung zugeschnitten sein. Je später man mit dieser Arbeit beginnt, desto teurer wird der Umbau.

devel.one bietet eine durchgängige Methode der Unterteilung der Software in kleinere Happen, die jeweils miteinander kommunizieren. Am Anfang arbeiten diese Teile noch auf einer einzigen Maschine. Wenn die Zeit gekommen ist und die Last zunimmt, genügt es die einzelnen Komponenten auf verschiedene Rechner zu verteilen und per Konfiguration zu verknüpfen. Wenn die Unterteilung der Software hinreichend feingliedrig durchgeführt wurde, muss nichts neu programmiert werden.

Ermöglicht wird dieses durch die lose Koppelung der Softwareteile durch die Verwendung von Nachrichten sowie durch das PlugIn-System.

Beispiel:

Komponente A benötigt die Komponenten B und C. A, B und C sind als PlugIn ausgeführt; technisch gesehen befinden sie sich in einer eigenen JAR-Datei. A liest beim StartUp die Adressen seiner Sub-Komponenten aus der Konfiguration und initiiert daraufhin die Kommunikation.
Zu einem späteren Zeitpunkt ist die Last auf dem Rechner soweit angestiegen, dass zwei weitere Rechner angeschafft werden müssen. Die Komponenten B und C werden in das PlugIn-Verzeichnis dieser Rechner kopiert, die Adressen für die Erreichung der Komponenten auf dem ersten Rechner aktualisiert, und weiter geht's.

Doch wie sieht es aus, wenn eine existierende Software aufgespalten werden muss?
Gewöhnlich habt ihr eine Vorstellung, wo der Bruch durchgeführt werden sollte. Das ist natürlich mit etwas Programmierung verbunden. Aber auch hier kann man devel.one wunderbar einsetzen, denn die Library läßt sich von jedem JAVA™-Programm einbinden. Die Kommunikation zwischen den Bruchstücken übernehmen dann kleine Targets mit Message-Handlern. Direkte Methoden-Aufrufe von A nach B und C und umgekehrt werden dann durch Nachrichten ersetzt.

Generell ist die Unterteilung der Software in Micro-Services sehr hilfreich für die maximale Ausnutzung der Resourcen. Die Services verteilt man geschickt auf unterschiedliche Namespaces/Threads, damit sämtliche Cores einer Maschine ausgelastet werden können. Gleichzeitig achtet man darauf, das Services, welche sehr viel miteinander kommunizieren müssen, möglichst im gleichen Thread liegen. Services, die viel Last erzeugen, separiert man schon früh in eigene Plugins, damit diese zu gegebener Zeit ausgelagert werden können.