Acesta este un scenariu de planificare ilustrativ pentru un constructor independent, nu o poveste de client sau un rezultat de capacitate măsurat. Aplicația înregistrează împrumuturi de echipamente pentru un club mic: un membru autentificat poate vedea articolele disponibile, poate crea un împrumut și îl poate returna. O înregistrare contează mai mult decât o diagramă de implementare sofisticată, așa că primul design ar trebui să facă scrierile eșuate și datele pierdute ușor de investigat.
Alegeți arhitectura minimă utilă
Folosiți un singur proces API, o singură bază de date și un proxy invers pentru endpoint-ul public HTTPS. Păstrați baza de date accesibilă doar prin calea locală sau privată prevăzută. Dați aplicației propria identitate de sistem de operare, cu acces la fișierele de care are nevoie. Păstrați fișierele de implementare separate de datele persistente, astfel încât o lansare să nu înlocuiască baza de date sau încărcările.
Partajarea unei instanțe menține configurația și investigarea gestionabile pentru o primă implementare. De asemenea, leagă componentele de aceeași limită de repornire, disc și defecțiune. Acceptați acest compromis în mod deliberat. Dacă aplicația necesită recuperare independentă sau baza de date concurează constant cu API-ul, luați în considerare separarea lor înainte de a mări totul deodată.
Bugetați pentru momentul de vârf
Nu dimensionați doar pentru un proces inactiv. Fișa de mai jos folosește alocații de planificare inventate pentru a demonstra calculul. Nu sunt măsurători ale acestei aplicații, benchmark-uri sau cerințe minime. Înlocuiți-le cu observații din runtime-ul și baza de date ale dvs., inclusiv o implementare reprezentativă.
| Partajarea instanței de lucru | Alocație de planificare | Ce să observați |
|---|---|---|
| Sistem de operare și proxy | 300 MiB | Activitate normală în fundal și jurnalizare |
| Proces API | 350 MiB | Cereri reprezentative, nu doar pornirea |
| Bază de date | 400 MiB | Conexiuni, interogări și lucrări de întreținere |
| Marjă pentru implementare | 450 MiB | Orice proces sau pas de build suprapus |
| Anvelopă combinată de planificare | 1,500 MiB | Comparați cu memoria utilizabilă reală |
The Construiți planul de pornire specifică în prezent 2 vCPU, 2 GB RAM și 50 GB SSD. Aceste cifre îl fac o configurație de investigat pentru această fișă, nu dovada că stiva se potrivește. GB din catalog și citirile MiB ale unui instrument sunt unități diferite; inspectați totalurile reale ale sistemului. Estimarea memoriei disponibile a Linux ține cont de memoria relevantă recuperabilă, așa că memoria liberă mică singură nu este un verdict de dimensionare. Consultați explicația kernelului despre MemAvailable și ghidul de măsurare.
CPU și discul necesită decizii separate. Înregistrați duratele cererilor și așteptările bazei de date înainte de a adăuga vCPU. Bugetați discul pentru sistemul de operare, lansările păstrate, creșterea bazei de date, jurnale și lucrări temporare de recuperare. O funcție de încărcare creează o problemă de stocare diferită de o mică înregistrare structurată; dați-i o limită de dimensiune și o decizie de retenție.
Cunoașteți costul inițial
Exemplul următor folosește Build cu resursele sale implicite și fără opțiuni recurente adăugate. Subtotalul său lunar este $14.00 USD. Valorile sunt generate din catalogul actual al configuratorului, astfel încât tabelul de prețuri urmează checkout-ul.
| Perioada de serviciu | Înainte de salvare | Salvat | Plătiți o dată |
|---|---|---|---|
| 1 lună | $14.00 | $0.00 (0%) | $14.00 USD |
| 3 luni | $42.00 | $0.00 (0%) | $42.00 USD |
| 6 luni | $84.00 | $23.52 (28%) | $60.48 USD |
| 12 luni | $168.00 | $84.00 (50%) | $84.00 USD |
O perioadă de șase luni sau anuală reduce totalul inițial al acestui catalog față de plata subtotalului lunar fără discount pentru același număr de luni. Nu adaugă resurse, nu stabilește un preț de reînnoire și nu face o arhitectură netestată potrivită. Alegeți o perioadă pe care vă puteți angaja, consultați detaliile de serviciu și facturare, și bugetați separat pentru un domeniu, eventuale servicii externe și taxe de rețea.
Verificați o cerere completă
Înainte de a deschide aplicația către utilizatorii săi vizați, confirmați accesul la server și accesul de recuperare, instalați un runtime acceptat și înregistrați versiunea pe care o implementați. O definiție de serviciu ar trebui să identifice executabilul, directorul de lucru și utilizatorul runtime. Setarea Restart= din Systemd controlează comportamentul specificat la defecțiune; o buclă de repornire necesită totuși diagnosticare. Consultați manualul serviciului și ghidul de implementare.
Testați mai întâi local, apoi prin numele real HTTPS dintr-o altă conexiune. Cu Caddy, gestionarea automată a certificatelor depinde de o configurație validă a numelui și de o metodă de validare funcțională; provocările obișnuite HTTP și TLS-ALPN necesită porturi de intrare accesibile 80, respectiv 443. Consultați prerechizitele Caddy HTTPS. Un succes local nu poate exclude o problemă DNS sau de proxy, după cum ghidul traseului cererii explică.
Faceți verificarea aplicației specifică: creați un articol de echipament de unică folosință, împrumutați-l, confirmați că o a doua cerere vede rezultatul stocat, apoi returnați-l. Verificați autorizarea, precum și un endpoint simplu de stare. Înregistrați răspunsurile așteptate înainte de testare și păstrați acreditările și datele membrilor în afara jurnalelor partajate pentru depanare.
Demonstrați o recuperare mică
Faceți o copie de siguranță a bazei de date cu o metodă adecvată motorului și obiectivului de recuperare. PostgreSQL documentează abordări separate logice, de sistem de fișiere și de arhivare continuă; alegerea corectă depinde de modul în care trebuie să recuperați. Consultați prezentarea generală a copiilor de siguranță. Dacă sunt încărcate fotografii ale articolelor, includeți acele fișiere și relația cu înregistrările lor din baza de date.
Executați un exercițiu de restaurare într-o bază de date și un director de test separate. Găsiți un articol cunoscut și fișierul corespunzător, apoi verificați că aplicația le poate citi pe ambele. Notați copia de siguranță selectată, momentul de timp al datelor, pașii necesari și rezultatul real. Primul ghid de restaurare dezvoltă acest exercițiu. O selecție opțională de copie de siguranță a catalogului nu dovedește că această recuperare la nivel de aplicație funcționează.
Luați următoarea decizie pe baza dovezilor
Rămâneți la designul simplu cât timp comportamentul său măsurat și cerințele de recuperare se potrivesc. Investigați o aplicație oprită sau avertismentele privind resursele înainte de a presupune că un plan mai mare este răspunsul. Alegeți Malaezia, România sau Elveția pentru server, apoi confirmați alocarea resurselor, locația copiei de siguranță și sfera serviciului. Acest scenariu nu stabilește nicio facilitate, capacitate de cerere sau timp de livrare.
Configurați Build și revizuiți fiecare opțiune. Linkul deschide planul de pornire; verificați perioada selectată și orice alegeri salvate înainte de a continua. Obținerea detaliilor de plată nu instalează aplicația de împrumut de echipamente.
Documentație utilizată
Referințe primare pentru această pagină. Verificați documentația pentru versiunea instalată în propriul mediu.