Hinweis: Um hier alles richtig zu verstehen ist es ratsam, erst den Beitrag von @RiotSeb vollständig durchzulesen: Hier geht es zu Hinter den Kulissen Teil 1 - Minecraftserver.
Boson - der Stoff, der die Welt zusammenhält ...
... so lautet zumindest die stark vereinfachte physikalische Erklärung zu diesem Begriff. Das klingt zunächst etwas hoch gegriffen, jedoch übernimmt unser "Boson" tatsächlich einige Aufgaben, die die "Welten" von Minecraft, Voteseiten, TeamSpeak und Forum zusammenhalten.
In diesem Teil des Dev-Blogs geht es also um unseren Back-End-Server, welcher den Namen "Boson" trägt. Angefangen als relativ einfaches Projekt ist Boson nicht nur unerlässlich sondern auch sehr komplex geworden. Es ist daher gar nicht so einfach, mit der eigentlichen Erklärung anzufangen. Ich versuche euch in diesem Beitrag Stück für Stück an die Funktionen und Notwendigkeit unseres Back-End-Servers heranzuführen. Auch hier sind einige Dinge zum besseren Verständnis vereinfacht oder unvollständig dargestellt.
Unter dem Begriff Back-End versteht man in der Softwareentwicklung den Bereich, von dem der Endbenutzer erstmal nichts mitbekommt. Zum Back-End gehören auch Dinge wie die Datenbank oder das Paketsystem. Im Gegensatz dazu ist das Front-End alles, was im direkten Kontakt mit dem Endbenutzer steht: Also der Minecraftserver oder das Forum. Der Back-End-Server übernimmt also (fast) nur Aufgaben, die nicht in direktem Kontakt mit dem Spieler stehen. Von der Existenz des Back-End-Servers bekommt man als Spieler also erstmal nichts mit - nur dann, wenn er mal nicht korrekt funktioniert.
Boson ist ein komplett selbst entwickeltes Programm und hat wenig mit einem Minecraftserver oder dem BungeeCord gemeinsam, außer, dass Boson auch vollständig in Java geschrieben ist und eine Minecraftserver-ähnliche Konsole zur Eingabe von Befehlen hat. Man kann sich also nicht etwa mit einem Minecraft-Clienten darauf verbinden. Anders als unser Minecraftnetzwerk wird Boson nicht täglich neugestartet sondern läuft auch mal gerne einen Monat lang durch - solange, bis es wieder ein Update von uns gibt.
Boson mit den meisten relevanten Verbindungen. Die Minecraftserver sind hier zusammengefasst und die Anbindung des Datenbankservers ist weggelassen.
Der Back-End-Server wird für Funktionen genutzt, die mindestens eines der folgenden Kriterien erfüllen:
Hier mal ein Beispiel. Der Pfeil gibt hierbei an, in welche Richtung die Paket-Kommunikation stattfindet:
Voson
Voson ist unser Voteserver und kümmert sich darum, die Votes, die von den Serverlisten zu uns geschickt werden, zu bearbeiten. Hierbei kümmert sich Voson nicht darum, dass die Belohnungen ausgegeben werden, sondern Voson informiert nur mit einem Paket den BungeeCord, dass ein Vote für einen Spieler angekommen ist. Der BungeeCord kümmert sich dann um alles weitere. Sollte mal das Servernetzwerk (z.B. bei einer Wartung oder während des Backups) offline sein, so speichert Voson die Votes erst einmal zwischen. Dies geschieht in einem eigenständigen Datenbanksystem, sodass auch bei einer Wartung unseres Datenbankservers die Votes zwischengespeichert werden. Solange Boson mit dem Modul Voson aktiv ist, können also immer Votes angenommen werden - sollte jedoch auch unser Rootserver aus sein, oder es steht ein Serverumzug an, ist Boson selbstverständlich auch etwas länger heruntergefahren und kann keine Votes entgegennehmen.
Voson mit allen relevanten Verbindungen
TS3Bot
Der TS3Bot kommuniziert über die beim TeamSpeak-Server mitgelieferte Schnittstelle (über ein Telnet-Interface) mit dem TeamSpeak-Server und ist wirklich der einzige Fall, wo ein Spieler direkt mit Boson interagieren kann, nämlich beim Freischalten in TeamSpeak. Der UWBot, der euch als Gast im TeamSpeak anschreibt, ist nämlich eben dieses Boson-Modul.
Neben der Registrierung kümmert sich der TS3Bot auch noch um das TeamSpeak-Logging, bspw. von Bans, bewegt abwesende Spieler in den AfK-Bereich, oder kickt diese bei zu langer Inaktivität.
Hier kann man sehr gut erklären, was es bedeutet, ein so vernetztes System zu haben: Im Spiel kann ein Admin per Befehl alle Spieler auf dem TeamSpeak-Server anstupsen lassen. Hierfür wird dann beim Absenden des Befehls ein Paket mit der Anweisung an das TS3Bot-Modul gesendet, welches dann alle Spieler anstupst.
Der TS3Bot mit den relevanten Verbindungen. Einige Daten vom TS3Bot werden direkt in der Datenbank gespeichert.
Scribon
Scribon ist das neuste Modul und kümmert sich um grundsätzliche Monitoringfunktionen: Hier wird nicht nur überprüft, ob die Datenbank funktioniert, sondern es werden auch jede Minute alle Minecraftserver im Netzwerk angepingt, um zu schauen, ob mit diesen alles in Ordnung ist. Sollte ein Minecraftserver mal nicht auf Pings antworten oder ein Absturz bemerkt werden, so kann Scribon direkt alle Devs darüber mit einer Messaging-API über unseren teaminternen Chatservice informieren. Diese Messaging-API kann ebenfalls für wichtige Infos von allen Minecraftservern über das Paketsystem verwendet werden.
In Scribon werden auch die Daten für die Statusanzeige im Forum und auf der Statusseite generiert.
Scribon mit seiner Verbindung im Paketsystem und dem Zugriff zum Messaging-Service.
Photon
Photon kümmert sich um unser tägliches Serverbackup. 15 Minuten vor Beginn des Backups werden die Spieler über das Backup informiert. Pünktlich um vier Uhr beendet Photon dann per Paketsystem alle Minecraftserver und den BungeeCord und startet und überwacht die Bash-Skripte zum Kopieren der Serverdaten und der Datenbank. Wenn schließlich alle Daten kopiert sind, startet Photon alle Minecraftserver und als letztes den BungeeCord wieder. Kleinere Pluginupdates werden von uns tagsüber in das System eingetragen und dann automatisch beim Neustart der Minecraftserver eingespielt. Danach werden die Backupdaten automatisiert verpackt und auf einen Backupserver hochgeladen.
Hier spielen dann erstmals die Module zusammen: Während des Backups wird in Scribon der Serverstatus passend gesetzt, sodass im Forum, TeamSpeak und auf der Statusseite der passende Status angezeigt wird. Sollte es beim Backup ein Problem geben, wird über die Messaging-API von Scribon wieder eine Information an alle Devs gesendet.
Ebenfalls finden sich hier einige Befehle um bei Serverwartungen schnell Backups zu machen oder alle Minecraftserver zu starten oder zu stoppen.
Photon mit Zugriff auf die Skripte für das Backup. Die Meldungen über den Status des Backups und über etwaige Fehler werden an Scribon weitergegeben.
Foron
Foron ist das mächtigste Modul und kümmert sich primär um die Kommunikation mit dem Forum und unseren restlichen Webanwendungen. Hierfür beinhaltet dieses Modul einen kleinen eignen Webserver, welcher eine REST-API bereitstellt. Dieser Webserver ist nur intern innerhalb unseres Rootservers erreichbar. Alle Interaktionen, bei denen ein Spieler direkt zugreift, laufen grundsätzlich über unseren öffentlichen Webserver, der immer einige Prüfungen macht, bevor Anfragen an Foron weitergeleitet werden.
Im Prinzip kann man sich vorstellen, dass intern eine "Website" mit einer URL aufgerufen wird. Dieser Aufruf wird von Foron bearbeitet und die gewünschten Aktionen dann per Paketsystem ausgeführt. Hierzu zählen dann Funktionen wie der Abruf der Spielerliste im Forum, das Setzen der Wiki-Ränge oder die Kompassfunktion auf der Dynmap. Intern sind noch weitere Funktionen vorhanden: Es lassen sich Spieler teleportieren, beliebige Spielersettings ändern, und auch die Statusseite erhält von hier aus Informationen - um nur ein paar Beispiele zu nennen.
Im Spoiler findet ihr ein Beispiel um einen solchen Vorgang mal selber auszuprobieren:
Foron bearbeitet die Anfragen, die vom Webserver weitergegeben werden. Dafür nutzt Foron die Datenbank, das Paketsystem und Scribon. Diverse interne Skripte und auch Webseiten, die nur für das Team erreichbar sind, sind hier nicht mit dargestellt.
Diese fünf Module machen Boson zu unserem Schweizer Taschenmesser wenn es darum geht, alle unsere Dienste miteinander zu verbinden. Habt ihr Fragen zu der allgemeinen Funktion oder zu den Modulen, könnt ihr diese gerne hier stellen. Falls der Wunsch besteht, kann ich auch gerne genauer auf einzelne Module eingehen - jedoch wird die Erklärung natürlich immer technischer, wenn die Reise tiefer geht.
Vielen Dank fürs Lesen!
Boson - der Stoff, der die Welt zusammenhält ...
... so lautet zumindest die stark vereinfachte physikalische Erklärung zu diesem Begriff. Das klingt zunächst etwas hoch gegriffen, jedoch übernimmt unser "Boson" tatsächlich einige Aufgaben, die die "Welten" von Minecraft, Voteseiten, TeamSpeak und Forum zusammenhalten.
In diesem Teil des Dev-Blogs geht es also um unseren Back-End-Server, welcher den Namen "Boson" trägt. Angefangen als relativ einfaches Projekt ist Boson nicht nur unerlässlich sondern auch sehr komplex geworden. Es ist daher gar nicht so einfach, mit der eigentlichen Erklärung anzufangen. Ich versuche euch in diesem Beitrag Stück für Stück an die Funktionen und Notwendigkeit unseres Back-End-Servers heranzuführen. Auch hier sind einige Dinge zum besseren Verständnis vereinfacht oder unvollständig dargestellt.
Unter dem Begriff Back-End versteht man in der Softwareentwicklung den Bereich, von dem der Endbenutzer erstmal nichts mitbekommt. Zum Back-End gehören auch Dinge wie die Datenbank oder das Paketsystem. Im Gegensatz dazu ist das Front-End alles, was im direkten Kontakt mit dem Endbenutzer steht: Also der Minecraftserver oder das Forum. Der Back-End-Server übernimmt also (fast) nur Aufgaben, die nicht in direktem Kontakt mit dem Spieler stehen. Von der Existenz des Back-End-Servers bekommt man als Spieler also erstmal nichts mit - nur dann, wenn er mal nicht korrekt funktioniert.
Boson ist ein komplett selbst entwickeltes Programm und hat wenig mit einem Minecraftserver oder dem BungeeCord gemeinsam, außer, dass Boson auch vollständig in Java geschrieben ist und eine Minecraftserver-ähnliche Konsole zur Eingabe von Befehlen hat. Man kann sich also nicht etwa mit einem Minecraft-Clienten darauf verbinden. Anders als unser Minecraftnetzwerk wird Boson nicht täglich neugestartet sondern läuft auch mal gerne einen Monat lang durch - solange, bis es wieder ein Update von uns gibt.
Boson mit den meisten relevanten Verbindungen. Die Minecraftserver sind hier zusammengefasst und die Anbindung des Datenbankservers ist weggelassen.
Der Back-End-Server wird für Funktionen genutzt, die mindestens eines der folgenden Kriterien erfüllen:
- Die Funktion muss immer verfügbar sein, auch wenn bspw. das Minecraftnetzwerk komplett heruntergefahren ist (Beispiele: Backup, Vote-Server, Monitoring)
- Die Funktionen müssen über eine zentrale Instanz gesteuert werden (Beispiele: Backup, Erfassung von Namensumbenennungen, TeamSpeak-Anbindung)
- Die Funktion sollte aufgrund von Leistungsverteilung oder besserer Wartbarkeit nicht direkt in Teile des Minecraftnetzwerks eingebaut werden (Beispiele: Web-Zugriffe, TeamSpeak-Anbindung, Vote-Server)
Hier mal ein Beispiel. Der Pfeil gibt hierbei an, in welche Richtung die Paket-Kommunikation stattfindet:
- Nachricht an den Spieler senden: Boson => BungeeCord:
Um einem Spieler eine Nachricht zu senden, schickt Boson ein Paket an den BungeeCord, in dem dieser dazu angewiesen wird, dem Spieler die im Paket erhaltene Nachricht zu senden. - Spieler loggt sich ein: Boson <= BungeeCord:
Sobald sich ein Spieler einloggt, wird ein passendes Paket an Boson gesendet. Boson überprüft dann, ob der Spieler eine neue private Nachricht im Forum hat. Ist dies der Fall sendet Boson eine Nachricht an den Spieler (siehe oben). - Spieler teleportieren: Boson => Minecraftserver:
Soll ein Spieler von Boson aus teleportiert werden, so sendet Boson dem Minecraftserver, auf dem der betreffende Spieler online ist, ein Paket, in dem die Anweisung zur Teleportation und die Zielkoordinaten erhalten sind.
Voson
Voson ist unser Voteserver und kümmert sich darum, die Votes, die von den Serverlisten zu uns geschickt werden, zu bearbeiten. Hierbei kümmert sich Voson nicht darum, dass die Belohnungen ausgegeben werden, sondern Voson informiert nur mit einem Paket den BungeeCord, dass ein Vote für einen Spieler angekommen ist. Der BungeeCord kümmert sich dann um alles weitere. Sollte mal das Servernetzwerk (z.B. bei einer Wartung oder während des Backups) offline sein, so speichert Voson die Votes erst einmal zwischen. Dies geschieht in einem eigenständigen Datenbanksystem, sodass auch bei einer Wartung unseres Datenbankservers die Votes zwischengespeichert werden. Solange Boson mit dem Modul Voson aktiv ist, können also immer Votes angenommen werden - sollte jedoch auch unser Rootserver aus sein, oder es steht ein Serverumzug an, ist Boson selbstverständlich auch etwas länger heruntergefahren und kann keine Votes entgegennehmen.
Voson mit allen relevanten Verbindungen
TS3Bot
Der TS3Bot kommuniziert über die beim TeamSpeak-Server mitgelieferte Schnittstelle (über ein Telnet-Interface) mit dem TeamSpeak-Server und ist wirklich der einzige Fall, wo ein Spieler direkt mit Boson interagieren kann, nämlich beim Freischalten in TeamSpeak. Der UWBot, der euch als Gast im TeamSpeak anschreibt, ist nämlich eben dieses Boson-Modul.
Neben der Registrierung kümmert sich der TS3Bot auch noch um das TeamSpeak-Logging, bspw. von Bans, bewegt abwesende Spieler in den AfK-Bereich, oder kickt diese bei zu langer Inaktivität.
Hier kann man sehr gut erklären, was es bedeutet, ein so vernetztes System zu haben: Im Spiel kann ein Admin per Befehl alle Spieler auf dem TeamSpeak-Server anstupsen lassen. Hierfür wird dann beim Absenden des Befehls ein Paket mit der Anweisung an das TS3Bot-Modul gesendet, welches dann alle Spieler anstupst.
Der TS3Bot mit den relevanten Verbindungen. Einige Daten vom TS3Bot werden direkt in der Datenbank gespeichert.
Scribon
Scribon ist das neuste Modul und kümmert sich um grundsätzliche Monitoringfunktionen: Hier wird nicht nur überprüft, ob die Datenbank funktioniert, sondern es werden auch jede Minute alle Minecraftserver im Netzwerk angepingt, um zu schauen, ob mit diesen alles in Ordnung ist. Sollte ein Minecraftserver mal nicht auf Pings antworten oder ein Absturz bemerkt werden, so kann Scribon direkt alle Devs darüber mit einer Messaging-API über unseren teaminternen Chatservice informieren. Diese Messaging-API kann ebenfalls für wichtige Infos von allen Minecraftservern über das Paketsystem verwendet werden.
In Scribon werden auch die Daten für die Statusanzeige im Forum und auf der Statusseite generiert.
Scribon mit seiner Verbindung im Paketsystem und dem Zugriff zum Messaging-Service.
Photon
Photon kümmert sich um unser tägliches Serverbackup. 15 Minuten vor Beginn des Backups werden die Spieler über das Backup informiert. Pünktlich um vier Uhr beendet Photon dann per Paketsystem alle Minecraftserver und den BungeeCord und startet und überwacht die Bash-Skripte zum Kopieren der Serverdaten und der Datenbank. Wenn schließlich alle Daten kopiert sind, startet Photon alle Minecraftserver und als letztes den BungeeCord wieder. Kleinere Pluginupdates werden von uns tagsüber in das System eingetragen und dann automatisch beim Neustart der Minecraftserver eingespielt. Danach werden die Backupdaten automatisiert verpackt und auf einen Backupserver hochgeladen.
Hier spielen dann erstmals die Module zusammen: Während des Backups wird in Scribon der Serverstatus passend gesetzt, sodass im Forum, TeamSpeak und auf der Statusseite der passende Status angezeigt wird. Sollte es beim Backup ein Problem geben, wird über die Messaging-API von Scribon wieder eine Information an alle Devs gesendet.
Ebenfalls finden sich hier einige Befehle um bei Serverwartungen schnell Backups zu machen oder alle Minecraftserver zu starten oder zu stoppen.
Photon mit Zugriff auf die Skripte für das Backup. Die Meldungen über den Status des Backups und über etwaige Fehler werden an Scribon weitergegeben.
Foron
Foron ist das mächtigste Modul und kümmert sich primär um die Kommunikation mit dem Forum und unseren restlichen Webanwendungen. Hierfür beinhaltet dieses Modul einen kleinen eignen Webserver, welcher eine REST-API bereitstellt. Dieser Webserver ist nur intern innerhalb unseres Rootservers erreichbar. Alle Interaktionen, bei denen ein Spieler direkt zugreift, laufen grundsätzlich über unseren öffentlichen Webserver, der immer einige Prüfungen macht, bevor Anfragen an Foron weitergeleitet werden.
Im Prinzip kann man sich vorstellen, dass intern eine "Website" mit einer URL aufgerufen wird. Dieser Aufruf wird von Foron bearbeitet und die gewünschten Aktionen dann per Paketsystem ausgeführt. Hierzu zählen dann Funktionen wie der Abruf der Spielerliste im Forum, das Setzen der Wiki-Ränge oder die Kompassfunktion auf der Dynmap. Intern sind noch weitere Funktionen vorhanden: Es lassen sich Spieler teleportieren, beliebige Spielersettings ändern, und auch die Statusseite erhält von hier aus Informationen - um nur ein paar Beispiele zu nennen.
Im Spoiler findet ihr ein Beispiel um einen solchen Vorgang mal selber auszuprobieren:
Nachricht senden per REST-Server
Hier wird es jetzt etwas technischer, um mal ein Beispiel für das Senden einer Nachricht an einen Spieler auf dem Minecraftserver über Boson zu demonstrieren.
Wenn ihr im Forum angemeldet und auf dem Minecraftserver online seid, könnt ihr euch einfach mal mit dem folgenden Knopf eine Nachricht im Spiel senden:
Hier klicken
In dem neuen Tab öffnet sich jetzt eine Seite des Webservers, quasi ein Programm, welches prüft, ob ihr im Forum angemeldet seid und gibt dann eine vordefinierte Nachricht sowie euren Spielernamen an Boson weiter.
Boson prüft dann, ob ihr auf dem Minecraftserver online seid und ob der Cooldown, also eine Art Spamfilter, noch aktiv ist. Wenn alles in Ordnung ist, sendet Boson ein Paket zum BungeeCord welches euch die Nachricht zustellt. Ihr erhaltet im Browser dann die Antwort von Boson im JSON-Format. Diese Antwort ist für unseren REST-Server standardisiert.
Die Antwort ist in dem JSON-Format, welches man auch aus Minecraft kennt, da es sich in jeder Programmiersprache, die wir hier verwenden (Java, php, Javascript, NodeJS), einfach übersetzen lässt und dennoch für Menschen gut lesbar ist. In dieser Antwort sind immer Angaben zum Erfolg der Anfrage, eine Nachricht, der Typ und die Version des Servers sowie - wenn nötig - die Ergebnisdaten, die die Anfrage geliefert hat.
Anbei ist nochmal ein Flussdiagramm mit dem kompletten Weg dieser Nachricht sowie ein Teil unserer internen Dokumentation zu dieser Resource (also zu diesem Teil des REST-Servers.)
Stark vereinfachtes Ablaufdiagarmm dieser Anfrage (Zum Zoomen auf das Bild klicken)
Ausschnitt aus unserer internen Dokumentation zu der Resource, also dem Teil des REST-Servers von Foron
Hier wird es jetzt etwas technischer, um mal ein Beispiel für das Senden einer Nachricht an einen Spieler auf dem Minecraftserver über Boson zu demonstrieren.
Wenn ihr im Forum angemeldet und auf dem Minecraftserver online seid, könnt ihr euch einfach mal mit dem folgenden Knopf eine Nachricht im Spiel senden:
Hier klicken
In dem neuen Tab öffnet sich jetzt eine Seite des Webservers, quasi ein Programm, welches prüft, ob ihr im Forum angemeldet seid und gibt dann eine vordefinierte Nachricht sowie euren Spielernamen an Boson weiter.
Boson prüft dann, ob ihr auf dem Minecraftserver online seid und ob der Cooldown, also eine Art Spamfilter, noch aktiv ist. Wenn alles in Ordnung ist, sendet Boson ein Paket zum BungeeCord welches euch die Nachricht zustellt. Ihr erhaltet im Browser dann die Antwort von Boson im JSON-Format. Diese Antwort ist für unseren REST-Server standardisiert.
Die Antwort ist in dem JSON-Format, welches man auch aus Minecraft kennt, da es sich in jeder Programmiersprache, die wir hier verwenden (Java, php, Javascript, NodeJS), einfach übersetzen lässt und dennoch für Menschen gut lesbar ist. In dieser Antwort sind immer Angaben zum Erfolg der Anfrage, eine Nachricht, der Typ und die Version des Servers sowie - wenn nötig - die Ergebnisdaten, die die Anfrage geliefert hat.
Anbei ist nochmal ein Flussdiagramm mit dem kompletten Weg dieser Nachricht sowie ein Teil unserer internen Dokumentation zu dieser Resource (also zu diesem Teil des REST-Servers.)
Stark vereinfachtes Ablaufdiagarmm dieser Anfrage (Zum Zoomen auf das Bild klicken)
Ausschnitt aus unserer internen Dokumentation zu der Resource, also dem Teil des REST-Servers von Foron
Foron bearbeitet die Anfragen, die vom Webserver weitergegeben werden. Dafür nutzt Foron die Datenbank, das Paketsystem und Scribon. Diverse interne Skripte und auch Webseiten, die nur für das Team erreichbar sind, sind hier nicht mit dargestellt.
Diese fünf Module machen Boson zu unserem Schweizer Taschenmesser wenn es darum geht, alle unsere Dienste miteinander zu verbinden. Habt ihr Fragen zu der allgemeinen Funktion oder zu den Modulen, könnt ihr diese gerne hier stellen. Falls der Wunsch besteht, kann ich auch gerne genauer auf einzelne Module eingehen - jedoch wird die Erklärung natürlich immer technischer, wenn die Reise tiefer geht.
Vielen Dank fürs Lesen!
- yEd Graph Editor: Ablauf- und Prozessdiagramme (wie in diesem Beitrag) und Mindmaps erstellen: yEd Graph Editor
- Physikalische Erklärung von Bosonen von Harald Lesch: Video
.
