Architettura di LionsBase¶
Panoramica¶
LionsBase è un’applicazione ospitata composta da tre componenti principali:
Un web server: questo componente riceve le richieste HTTP da client (in genere un browser web). Alcune richieste sono gestite direttamente dal server web, in genere le richieste di contenuto statico, ad esempio immagini. Le richieste per le pagine web vengono trasmessi a un server applicazioni per l’ulteriore elaborazione. LionsBase utilizza Nginx come server web,
Un application server: questo componente è responsabile della gestione della logica di business. Esso costruisce dinamicamente pagine web che sarà servita ai clienti al fine di server web. PHP-FPM è il nostro server di applicazione scelta.
Un server database: permanenti dei dati, quali record di membro sono memorizzati in un database. LionsBase utilizza MySQL come database.
I componenti sono indipendenti e possono essere ospitati su più server differenti.
Architettura¶
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.
Figure 1: Technical architecture overview¶
Come descritto nei Figura 1, l’architettura può facilmente affrontare un numero crescente di club dal primo scaling up e quindi scaling out:
- Scaling Up (aka Vertical Scalability)
Come l’infrastruttura è virtualizzato, non appena il carico o la quantità di Club aumenta, la capacità dei server (cioè, le macchine virtuali) sarà aumentata di conseguenza (con l’aggiunta di più spazio su disco, CPU o RAM).
- Scaling Out (aka Horizontal Scalability)
Al lato di scalabilità, nuovi server può essere lanciato e completamente configurato in pochi minuti. Le richieste per i club sono quindi indirizzate secondo il loro nome a dominio tramite DNS. Contiamo su un servizio DNS anycast globalmente distribuita.
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.
Sicurezza¶
La nostra infrastruttura segue le migliori pratiche in termini di sicurezza. Infatti, ogni server è mantenuto fino ad oggi, completamente patchato e protetto (controllo degli accessi, firewall, ecc.). Per aumentare ulteriormente il livello di sicurezza, un proxy inverso analizza ogni richiesta venuta alla nostra infrastruttura:
Una Web Application Firewall (WAF) controlla le richieste di livello applicazione e impedisce di vari attacchi quali SQL-injection, XSS, bot, scrappers, DDoS, ecc.
Il proxy mette risorse statiche (immagini, css, js lime, ecc.) in una cache distribuita a livello globale (cioè un CDN) in modo da aumentare le prestazioni di siti web.
Il proxy si occupa anche della gestione SSL.
Il proxy inverso è gestito da un provider di terze parti (principalmente per proteggere le nostre infrastrutture contro DDoS).
Server di nome di dominio (DNS)¶
LionsBase, essendo un’applicazione ospitata, ha bisogno di essere in controllo delle impostazioni DNS del vostro nome di dominio, al fine di garantire la sicurezza (SSL, WAF, anti-DDoS, ecc.) e un’esperienza trasparente per gli utenti finali. A tal fine, devi solo cambiare i server DNS utilizzati dal vostro dominio presso il registrar.
Monitoraggio¶
Ogni server viene monitorato ogni 5 minuti e gli avvisi vengono segnalati in caso di problemi.
Exchange of Information¶
The figure Figure 2 depicts the general workflow when a user accepts to share her information (please read section Exchange of information in the mobile application for details).
Figure 2: Overview of the exchange of information¶
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.
Nota
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.