Hinter den Kulissen Teil 2 - Back-End-Server

Dieses Thema im Forum "Dev-Blog" wurde erstellt von SteuerungC, 9. Februar 2019.

  1. SteuerungC

    Serverteam Developer

    Mitglied seit:
    Jan. 2016
    Beiträge:
    207
    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.

    [​IMG]
    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)
    Da Boson über das Paketsystem frei mit allen Minecraftservern sowie dem BungeeCord im Netzwerk bidirektional, also in beide Richtungen, kommunizieren kann, sind praktisch alle Möglichkeiten gegeben, den Minecraftserver bzw. den Spieler zu "steuern". Da ein direkter Zugriff auf Spieler und Welten natürlich nicht möglich ist, sendet Boson also nur Pakete an den passenden Minecraftserver oder den BungeeCord, in dem praktisch eine Anweisung enthalten ist, was zu tun ist.
    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.
    Damit Boson seine vielseitigen Funktionen bearbeiten kann, ist es in einige Module aufgeteilt. Ein Modul kann man wie ein Plugin bei einem Minecraftserver verstehen: Grundfunktionen, wie bspw. das Paketsystem oder die Konsole sind in Boson direkt enthalten, alle anderen Funktionen werden von den Modulen bereitgestellt. Da die Boson-Module sehr viel zusammenarbeiten und so auch schnell aufeinander angewiesen sind, kann mittlerweile kein Boson-Modul ohne weiteres "rausgeworfen" werden. Nachfolgend werden die verschiedenen Module mit ihren Aufgaben aufgelistet. Die Module an sich sind mittlerweile so komplex, dass im Prinzip für fast jedes Modul ein eigener Blogbeitrag verfasst werden könnte - Ich werde hier versuchen, die Funktionen kurz und trotzdem möglichst vollständig zu erklären.

    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.

    [​IMG]
    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.

    [​IMG]
    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.

    [​IMG]
    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.

    [​IMG]
    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.)

    [​IMG]
    Stark vereinfachtes Ablaufdiagarmm dieser Anfrage (Zum Zoomen auf das Bild klicken)


    [​IMG]
    Ausschnitt aus unserer internen Dokumentation zu der Resource, also dem Teil des REST-Servers von Foron

    [​IMG]
    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
     
    Morock, Dubbnium, ThorStarbound und 44 anderen gefällt das.
  2. joestr

    joestr Spender

    Mitglied seit:
    Apr. 2015
    Beiträge:
    314
    Wiki:
    Joestr
    Erstaunlich, was da für eine Infrastruktur dahinter steckt! Als Normal-Benutzer macht man sich über sowas normalerweise keine Gedanken.
     
    Architektkubus, Jan, ResQ_ und 4 anderen gefällt das.
  3. TMD

    TMD Spender

    Mitglied seit:
    Sep. 2014
    Beiträge:
    874
    Also ich hab mir das ganze nun nicht durchgelesen, da war irgendwie anderes gerade interessanter. Aber ich muss schon sagen, die Bildchen sehen ja schon irgendwie wie Kunst aus. Ihr macht das schon :p
     
    Yunaaa und KugoHugo gefällt das.
  4. arturoog

    Guard

    Mitglied seit:
    Nov. 2014
    Beiträge:
    126
    Ich bin fasziniert. Hatte ich kaum drüber nachgedacht, wie das funktioniert, dass Forum und Minecraft und Teamspeak etc. so "über Grenzen hinweg zusammenarbeiten". Aber natürlich, irgendwie muss irgendjemand da ja mal was programmiert haben :D.
    Gut erklärt. Die eingebauten Links sind auch hilfreich. Wieder was gelernt:)
     
    RiotSeb, ResQ_ und SteuerungC gefällt das.
  5. B_A_Baracus

    B_A_Baracus Wiki-Vielschreiber

    Mitglied seit:
    März 2017
    Beiträge:
    499
    Wiki:
    B a baracus
    Toll erklärt :rolleyes:
     
    RiotSeb, boesekoenigin und SteuerungC gefällt das.
  6. Theodorianum

    Theodorianum Spieler

    Mitglied seit:
    Apr. 2018
    Beiträge:
    205
    Echt toll erklärt, sehr leicht verständlich! :D
    Da versteht man wie viel Arbeit es ist einen Server zu leiten...
     
    Drakona7, RiotSeb, boesekoenigin und 3 anderen gefällt das.
  7. TischGetreide10

    TischGetreide10 Spieler

    Mitglied seit:
    Juli 2018
    Beiträge:
    15
    Theodorianum gefällt das.
  8. boesekoenigin

    boesekoenigin Spieler

    Mitglied seit:
    Jan. 2019
    Beiträge:
    34
  9. Petro99

    Petro99 Spieler

    Mitglied seit:
    Aug. 2017
    Beiträge:
    192
  10. Kathinka05

    Kathinka05 Spender

    Mitglied seit:
    Dez. 2015
    Beiträge:
    213
    Wiki:
    Kathinka05
    Ich bin immer wieder fasziniert was da alles hinter steckt und wie die Zusammenarbeit so läuft. Ich hab zwar ein gewisses technisches Verständnis und weiß wie viel Arbeit dahinter steckt aber das so im Einzelnen mal aufgelistet zu sehen ist schon cool.

    Und wie immer ein dickes Lob an euch, dass immer alles reibungslos läuft und wie viel Zeit ihr hier investiert um für uns das Spiel so angenehm wie möglich zu machen.
     
    Drakona7, Yunaaa, Theodorianum und 2 anderen gefällt das.
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deinem Erleben anzupassen und dich nach der Registrierung angemeldet zu halten. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. OK Weitere Informationen
    Information ausblenden