Aplicație Cloud Service

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare
Arhitectură CSA simplificată

Aplicația CSA sau Cloud Service este o arhitectură de rețea de tip Client-Server , în special este un model SaaS pentru aplicații mobile . Proiectată de Luca Scognamiglio, prima sa versiune a fost publicată în mai 2020.

Permite accesul la serviciile de aplicații ( aplicația mobilă ) fără a fi necesară instalarea aplicației în sine.

Această arhitectură folosește două protocoale: HTTPS și RTMP / S (încapsulate în HTTPS)

Operațiune

Aplicația CSA sau Cloud Service este o arhitectură care permite accesul la serviciile de aplicații ( aplicația mobilă ) fără a fi necesară instalarea aplicației în sine, dar descărcând doar un client foarte mic care va interfața cu aplicația care se află pe un server al dezvoltatorului.

Serverul va avea aplicația în cauză în interiorul său, în timp ce diferiții clienți vor avea un mic software care se va ocupa doar de stabilirea conexiunii cu serverul și de toate componentele de bază principale pentru utilizarea fluidă a sistemului în primele 3 secunde.

Compoziţie

Client

În funcție de faptul că clientul trebuie să fie cât mai ușor, va avea:

  • Grafică pe prima pagină și funcționalitate de bază (folosind principiile localității )
  • Structura de bază a paginilor aplicației
  • Funcționalitate HTTPS și RTMP / S

Server

Având în vedere că protocolul HTTPS este utilizat și RTMP / S este încapsulat în HTTPS , primul răspuns este obținut cu serverul Dispatcher care va verifica corectitudinea cererii; dacă cererea este validă, atunci va verifica agentul utilizator , deoarece o cerere client HTTPS va fi formată din:

 POST <uri> HTTP / 1.1
Gazdă : <nume-gazdă>
User-Agent : <nume>

Serverul va verifica dacă solicitarea a fost făcută de la un client desktop , un Android sau un IOS , pentru a trimite înapoi către serverele care vor avea versiunea desktop, Android sau IOS respectiv.

Server Architecture.jpg

Structura clientului

Operațiunea clientului va fi după cum urmează:

Aplicația pe care utilizatorul o va descărca va conține pagina de autentificare / înregistrare și va fi primul lucru pe care utilizatorul îl va vedea imediat ce descarcă / deschide aplicația (cu excepția cazului în care utilizatorul decide să aibă constanta acces). Pagina principală pe care utilizatorul o va accesa va fi încărcată 50% pe client și restul de 50% pe server .

50% care va fi prezent pe client va fi componenta pe care utilizatorul o va vedea mai întâi, precum și cea mai ușoară, restul va fi încărcat imediat după aceea.

Pentru celelalte pagini diferite de primare pe care le vom numi Less_Page , 25% vor fi prezente pe client, restul de 75% din pagină va fi încărcat în momentul solicitării.

Există, de asemenea, o a treia categorie, care este Rare_pages , care sunt acele pagini care sunt rareori utilizate. Aceste pagini nu vor locui pe client, ci în întregime pe server și vor fi încărcate după cum este necesar.

Deci, paginile din interiorul clientului vor fi structurate după cum urmează:

  • Autentificare / Înregistrare 100%
    • Pagina principală 50% Client - 50% Server
    • Less_Page 25% Client - 75% Server
    • Rare_page 0% Client - 100% Server

Alegerea dacă o pagină trebuie să fie Less_page sau Rare_page se va face prin principiul localității de către Dispacher_Server .

Clientul va avea nu numai GUI-ul aplicației, ci și invocarea funcției ; în acest caz, toate metodele de operare vor fi prezente în cadrul Clientului în momentul descărcării. Aceste metode nu vor fi executate în interiorul clientului, ci vor invoca corpul metodelor din server și vor aștepta rezultatul și apoi îl vor integra în GUI.

Structura serverului

În ceea ce privește serverul, ar trebui să ne ocupăm de 95% din operațiuni tocmai pentru că scopul nostru este de a ușura sarcina clientului.

Componenta serverului va fi compusă după cum urmează:

  • Server Dispecer
  • Server conținut
  • Bază de date

Server Dispecer

Dispatcher Server va fi primul server care primește cererile clientului; joacă un rol crucial pentru funcționarea corectă a acestui sistem.

Sarcinile serverului Dispatcher sunt:

  • Verificați validitatea cererii
  • Verificați User-Agent → Sortare server de conținut
  • Accesați Efectuarea operațiunilor de securitate împotriva operațiunilor frauduloase.

Verificați validitatea cererii

Va fi prima operațiune pe care Dispatcher Server o va efectua și va verifica dacă cererea este consecventă și dacă nu a primit erori de transmisie; în caz de erori, va solicita retransmiterea cererii.

Verificați User-Agent

După verificarea validității cererii, Dispatcher Server va analiza conținutul câmpului User-Agent pentru a merge și a direcționa această cerere către Serverul de conținut în cauză. În momentul sortării către serverul de conținut, serverul dispecerat va notifica clientul despre serverul care va gestiona solicitările sale, furnizându-i adresa IP a serverului de conținut pentru cererile sale viitoare.

Această operație de sortare către serverul de conținut va fi efectuată o singură dată pe conexiune , prin urmare până când utilizatorul decide să părăsească aplicația.

Utilizarea acestei strategii permite să nu vă simțiți obosiți și să suprasolicitați Dispatcher Server prea mult.

Efectuați operațiuni de securitate împotriva operațiunilor frauduloase

Această fază este o primă examinare a posibilelor atacuri de către actori rău intenționați, deoarece va fi singurul server care are lista completă de accesări și conexiuni, motiv pentru care acționează ca manager în caz de atac, notificând serverele de conținut închideți anumite conexiuni.

Server conținut

Serverele conținute vor fi serverele care vor avea instalată aplicația efectivă în interiorul lor; mai multe servere de conținut sunt utilizate pentru a reduce oboseala pe un singur server și pentru a delega un server fiecărei platforme. Toate serverele de conținut vor avea aceeași aplicație, astfel încât, în cazul unui atac asupra unui server de conținut, acesta poate fi deconectat, delegând restul pentru a umple temporar lipsa acelui server. Diferența dintre serverele conținute va fi substanțial în GUI - urile care sunt încărcate în momentul solicitării de către client.

În acest fel, serverul de conținut delegat domeniului desktop va putea furniza interfața desktop dezvoltată special pentru acest lucru, serverul de conținut delegat Android Mobile va furniza interfața Android special dezvoltată și așa mai departe.

Bază de date

Baza de date este, de asemenea, o componentă fundamentală și importantă; va exista o bază de date centralizată care va conține toate informațiile și datele unui anumit utilizator, iar aceasta va fi accesibilă de pe toate serverele de conținut, astfel încât, dacă utilizatorul se conectează pe mobil sau prin desktop, va avea acces la toate datele sale .

O alternativă este, de asemenea, de a avea o bază de date pentru fiecare server care conține - care, totuși, va fi la curent cu celelalte baze de date -, astfel încât, în caz de nevoie, va fi posibilă interogarea bazei de date în cauză.

Avantaje și dezavantaje

Beneficii

  • Portabilitate mai mare
    • Prin exploatarea potențialului faptului că aplicația reală se află pe server și că, prin urmare, utilizatorul va trebui să interacționeze cu serverul pentru a utiliza aplicația, nu necesită nicio modificare pe partea din spate, ca arhitectură care execută aplicația este întotdeauna aceeași: de fapt, vom crea o abstractizare reală.
  • Extensibilitate mai mare
    • Pentru a putea extinde software-ul prin adăugarea de funcții suplimentare, va fi suficient să lucrați pe un singur back-end și apoi să faceți modificările corespunzătoare pe fiecare front-end. Profitând de principiul localității furnizat de Dispatcher Server, vom putea adăuga noi caracteristici fără ca clientul să devină mai greu.
  • Securitate mai mare
    • Deoarece cu această arhitectură, rezidând software-ul în interiorul serverului, putem crea toate sistemele de securitate necesare; mai ales datorită faptului că nu avem centralizare a apelurilor, dar avem o rețea de servere specializate, care vor funcționa fiecare cu metodologiile lor de securitate.
  • Actualizări ale aplicației de pe server
    • În funcție de faptul că aplicația se află în serverele dezvoltatorului și că, mai presus de toate, avem un singur back-end, dezvoltarea actualizărilor se dovedește a fi mult mai rapidă. Instalarea este, de asemenea, mult mai rapidă, deoarece nu va trebui să solicităm utilizatorilor să instaleze actualizarea, dar totul va fi la discreția dezvoltatorului de pe server, cu excepția actualizărilor necesare pentru a alinia clientul cu serverul.
  • Simplitatea clientului
    • Clientul este mult mai minim și simplificat, astfel încât să faciliteze utilizarea de către utilizator și să cântărească mai puțin (în ceea ce privește resursele hardware) pentru dispozitivul care îl folosește.
  • BackEnd unic pentru toate tipurile de clienți
    • După cum sa menționat anterior, mergem în acest fel pentru a dezvolta un singur back-end care se află pe serverele noastre, deoarece vom crea o abstracție reală
  • Dezvoltare dedicată FrontEnd
    • În timp ce avem un singur back-end, un alt punct forte al acestui model este posibilitatea dezvoltării front-end-ului dedicat fiecărui tip de dispozitiv, pentru a face utilizarea acestuia mai ușoară, mai confortabilă și mai ales potrivită pentru dispozitivul utilizat. funcționează conform strategiei Vizualizare

Dezavantaje

  • Arhitectură de server mai complexă
    • Dacă, pe de o parte, vom simplifica clientul, pe de altă parte, vom face partea serverului mai complexă, întrucât vom delega 95% din funcționalitate și execuție serverelor delegate. Deci, acest lucru necesită o proiectare și o dezvoltare mai riguroasă și mai precisă a serverului.
  • Dezvoltarea managementului comunicării server
    • Partea server, așa cum am văzut, este alcătuită din mai multe servere specializate în diverse sarcini; cu toate acestea, acest lucru necesită un proces de comunicare complex și optimizat între diferitele servere și baza de date, deoarece nucleul acestui model este comunicarea și interoperabilitatea acestor servere pentru a asigura compatibilitatea deplină, securitatea, suportul și viteza în executarea cerere.

Bibliografie

Luca Scognamiglio, Stream_Application_V1.0

linkuri externe

Adus de la „ https://it.wikipedia.org/w/index.php?title=Cloud_Service_Application&oldid=121464708 ”