Architektur von LionsBase¶
Überblick¶
LionsBase ist eine übergeordnete Computer-Anwendung von drei Hauptkomponenten:
Ein Web-Server: Diese Komponente empfängt HTTP-Anfragen von Clienten (in der Regel ein Webbrowser). Einige Anfragen können vom Webserver direkt beantwortet werden, zB statische Inhalte wie Bilder. Gesuche für Web-Seiten werden zur weiteren Verarbeitung an einen Anwendungsserver übertragen. LionsBase verwendet Nginx als Web-Server,
Anwendungsserver: Dieser ist für die Verwaltung der Verarbeitungslogik verantwortlich. Er erstellt dynamisch Webseiten, die vom Webserver an die Endclients geschickt werden. PHP-FPM ist unsere Server Wahl.
Ein Datenbank-Server: permanente Daten, wie zB Mitglieder- Datensätze, werden in einer Datenbank gespeichert. LionsBase verwendet MySQL als Datenbank.
Die Komponenten sind unabhängig und können auf mehreren verschiedenen Servern abgelegt werden.
Architektur¶
LionsBase is deployed on dedicated virtual machines for each Multiple District (or country) so that there is a clear separation of data. Virtual machines are currently based on VMware vSphere for convenience and security but basically requires a LAMP or LEMP stack.
At the moment, LionsBase is physically hosted in a secure datacenter, in Switzerland.
If the multiple district is large enough and thus the load is becoming too high for a single server to handle it, or to serve as a fail-over solution, LionsBase may be installed on multiple servers.
Abbildung 1: Technische Architekturübersicht¶
Wie beschrieben in Abbildung 1, kann die Architektur problemlos eine wachsende Zahl von Clubs bewältigen, zuerst durch Erhöhung dann durch Auslagerung der Kapazitäten:
- Erhöhung der Kapazität ( Vertikale Skalierung)
Die Infrastruktur wird virtualisiert, sobald die Belastung oder die Clubanzahl stark ansteigt, wird die Kapazität der Server (dh der virtuellen Maschinen) entsprechend erhöht (durch Hinzufügen von mehr Speicherplatz, CPU oder RAM).
- Auslagern von Kapazitäten (horizontale Scalierung)
Neben der Kapazitäts-Erhöhung, können neue Server innert Minuten angehängt und konfiguriert werden. Die Anfragen der Clubs werden dann nach ihren Domain-Namen mittels DNS weitergeleitet. Wir vertrauen das einem global arbeitenden Anycast DNS-Dienst an.
Scaling the web and application layer is not difficult. However, scaling the database is more challenging. Currently, our architecture supports one hot replica of the master server and several read replicas. Scaling further is just a matter of deploying a second similar setup. That is, our architecture will easily follow the growth of our customers.
Sicherheit¶
Unsere Infrastruktur verpflichtet sich der stärksten Sicherheits-Bestimmungen. Tatsächlich wird jeder Server auf dem neuesten Stand gehalten, voll aktualisiert und abgesichert (Zugangskontrolle, Firewall, usw.). Um die Sicherheit noch mehr zu erhöhen, analysiert ein Reverse-Proxi jede ankommende Anfrage, die zu unserer Infrastruktur kommt:
Eine Web Application Firewall (WAF) überwacht die Anfragen auf der Anwendungs-Ebene und verhindert, dass verschiedene Angriffe wie SQL-Injection, XSS, Bots, Scrappers, DDoS, usw, stattfinden können.
Der Proxy stellt statische Ressourcen (Bilder, Css-Dateien, Js-Dateien, usw.) in einen global verteilten Cache (dh ein CDN) um die Leistung von Webseiten zu verbessern.
Der Proxy befasst sich auch mit der SSL-Verwaltung.
Der Reverse-Proxy wird von einem Dritt-Anbieter betrieben (meist um unserer Infrastruktur zu schützen gegen DDoS).
Domain Name System (DNS)¶
LionsBase, als eine übergeordnete Computer-Anwendung, muss Kontrolle über die DNS-Einstellungen ihrer Domain-Namen haben, um den Endbenutzern Sicherheit (SSL, WAF, Anti-DDoS, usw.) und viel Erfahrung bieten zu können. Zu diesem Zweck müssen Sie nur auf die DNS-Server wechseln die von Ihrer Domäne gebraucht werden um Ihren Domäne-Namen zu erstellen.
Überwachung¶
Jeder Server wird alle 5 Minuten überwacht, im Fall von Schwierigkeiten werden sofort Warnungen herausgegeben.
Austausch von Informationen¶
The figure Figure 2 depicts the general workflow when a user accepts to share their information (please read section Exchange of information in the mobile application for details).
Abbildung 2: Überblick über den Informationsaustausch¶
What is really important to understand is that the LionsBase data associated to a given multiple district is completely separate from another multiple district. In short, each multiple district runs its own dedicated LionsBase database, code (application) and naturally assets (documents, images and photos, …).
When members choose to share their information, a flag in the source database indicates that, together with the list of fields that may be shared. A daily task exports the corresponding data as a flat file and puts it in an „import“ directory of the other multiple district sandboxes where another task will then iterate over the available external sources of data and import them into a separate space of its LionsBase database.
Bemerkung
Members who change their mind and do not share their profile anymore will get their data getting wiped out of the other multiple districts after the next daily import of data.