Dies ist ein illustratives Planungsszenario für einen unabhängigen Entwickler, keine Kundenstory und kein gemessenes Kapazitätsergebnis. Die Anwendung erfasst Geräteausleihen für einen kleinen Club: Ein authentifiziertes Mitglied kann verfügbare Gegenstände sehen, eine Ausleihe erstellen und zurückgeben. Ein Datensatz ist wichtiger als ein ausgefallenes Deployment-Diagramm, daher sollte das erste Design fehlgeschlagene Schreibvorgänge und verlorene Daten leicht untersuchen lassen.
Wähle die minimal nützliche Architektur
Verwende einen API-Prozess, eine Datenbank und einen Reverse-Proxy für den öffentlichen HTTPS-Endpunkt. Halte die Datenbank nur über den vorgesehenen lokalen oder privaten Pfad erreichbar. Gib der Anwendung eine eigene Betriebssystem-Identität mit Zugriff auf die benötigten Dateien. Halte Deployment-Dateien von persistenten Daten getrennt, damit ein Release nicht die Datenbank oder Uploads ersetzt.
Eine geteilte Instanz hält Konfiguration und Untersuchung für ein erstes Deployment überschaubar. Sie bindet die Komponenten außerdem an dieselbe Neustart-, Datenträger- und Fehlergrenze. Akzeptiere diesen Kompromiss bewusst. Wenn die Anwendung eine unabhängige Wiederherstellung erfordert oder die Datenbank durchgängig mit der API konkurriert, ziehe in Betracht, sie zu trennen, bevor du alles auf einmal hochskalierst.
Kalkuliere den geschäftigen Moment ein
Dimensionieren Sie nicht nur für einen Leerlaufprozess. Das folgende Arbeitsblatt verwendet erfundene Planungszuschläge, um die Berechnung zu demonstrieren. Sie sind keine Messwerte dieser Anwendung, keine Benchmarks und keine Mindestanforderungen. Ersetzen Sie sie durch Beobachtungen aus Ihrer Laufzeitumgebung und Datenbank, einschließlich einer repräsentativen Bereitstellung.
| Gemeinsame Nutzung der Instanz | Planungszuschlag | Was zu beobachten ist |
|---|---|---|
| Betriebssystem und Proxy | 300 MiB | Normale Hintergrundaktivität und Protokollierung |
| API-Prozess | 350 MiB | Repräsentative Anfragen, nicht nur der Start |
| Datenbank | 400 MiB | Verbindungen, Abfragen und Wartungsarbeiten |
| Bereitstellungsreserve | 450 MiB | Jeder überlappende Prozess oder Build-Schritt |
| Kombinierte Planungshülle | 1,500 MiB | Mit tatsächlich nutzbarem Arbeitsspeicher vergleichen |
Das Startplan erstellen gibt derzeit 2 vCPU, 2 GB RAM und 50 GB SSD an. Diese Werte machen es zu einer Konfiguration, die für dieses Arbeitsblatt untersucht werden sollte, nicht zu einem Beweis, dass der Stack passt. Katalog-GB und MiB-Anzeigen eines Tools sind unterschiedliche Einheiten; prüfen Sie die tatsächlichen Systemsummen. Die Schätzung des verfügbaren Arbeitsspeichers von Linux berücksichtigt relevanten rückgewinnbaren Arbeitsspeicher, daher ist wenig freier Arbeitsspeicher allein kein Urteil zur Dimensionierung. Siehe die Kernel-Erklärung zu MemAvailable und die Messleitfaden.
CPU und Datenträger erfordern separate Entscheidungen. Erfassen Sie Anfragedauern und Datenbank-Wartezeiten, bevor Sie vCPU hinzufügen. Planen Sie Datenträger für das Betriebssystem, aufbewahrte Releases, Datenbankwachstum, Protokolle und temporäre Wiederherstellungsarbeiten ein. Eine Upload-Funktion erzeugt ein anderes Speicherproblem als ein kleiner strukturierter Datensatz; geben Sie ihr ein Größenlimit und eine Entscheidung zur Aufbewahrung.
Kenne die Vorabkosten
Das folgende Beispiel verwendet Build mit seinen Standardressourcen und ohne zusätzliche wiederkehrende Optionen. Der monatliche Zwischensummenbetrag beträgt $14.00 USD. Die Werte werden aus dem aktuellen Konfigurator-Katalog generiert, sodass die Preistabelle dem Checkout folgt.
| Dienstzeitraum | Vor dem Speichern | Gespeichert | Einmalig bezahlen |
|---|---|---|---|
| 1 Monat | $14.00 | $0.00 (0%) | $14.00 USD |
| 3 Monate | $42.00 | $0.00 (0%) | $42.00 USD |
| 6 Monate | $84.00 | $23.52 (28%) | $60.48 USD |
| 12 Monate | $168.00 | $84.00 (50%) | $84.00 USD |
Ein sechsmonatiger oder jährlicher Zeitraum senkt die Voraussumme dieses Katalogs im Vergleich zur Zahlung der unrabattierten monatlichen Zwischensumme für dieselbe Anzahl von Monaten. Er fügt keine Ressourcen hinzu, legt keinen Verlängerungspreis fest und macht eine ungetestete Architektur nicht geeignet. Wählen Sie einen Zeitraum, auf den Sie sich festlegen können, und prüfen Sie Service- und Abrechnungsdetails, und berücksichtigen Sie separat eine Domain, etwaige externe Dienste und Netzwerkgebühren.
Verifiziere eine vollständige Anfrage
Bevor Sie die Anwendung für ihre vorgesehenen Nutzer freigeben, bestätigen Sie den Serverzugang und den Wiederherstellungszugang, installieren Sie eine unterstützte Laufzeitumgebung und dokumentieren Sie das Release, das Sie bereitstellen. Eine Dienstdefinition sollte die ausführbare Datei, das Arbeitsverzeichnis und den Laufzeitbenutzer angeben. Systemds Restart= Einstellung steuert das festgelegte Fehlerverhalten; eine Neustartschleife erfordert dennoch eine Diagnose. Siehe das Service-Handbuch und die Deployment-Anleitung.
Zuerst lokal testen, dann über den echten HTTPS-Namen von einer anderen Verbindung aus. Bei Caddy hängt die automatische Zertifikatsverwaltung von einer gültigen Namenskonfiguration und einer funktionierenden Validierungsmethode ab; die gängigen HTTP- und TLS-ALPN-Challenges benötigen erreichbare eingehende Ports 80 bzw. 443. Siehe die Caddy-HTTPS-Voraussetzungen. Ein lokaler Erfolg kann ein DNS- oder Proxy-Problem nicht ausschließen, wie der Leitfaden zum Anfragepfad erklärt.
Machen Sie die Anwendungsprüfung konkret: Erstellen Sie einen wegwerfbaren Ausrüstungsgegenstand, leihen Sie ihn aus, bestätigen Sie, dass eine zweite Anfrage das gespeicherte Ergebnis sieht, und geben Sie ihn dann zurück. Prüfen Sie die Autorisierung ebenso wie einen einfachen Health-Endpunkt. Halten Sie erwartete Antworten vor dem Testen fest und halten Sie Anmeldedaten und Mitgliederdaten aus Logs heraus, die zur Fehlerbehebung geteilt werden.
Belege eine kleine Wiederherstellung
Sichern Sie die Datenbank mit einer Methode, die zur Engine und zum Wiederherstellungsziel passt. PostgreSQL dokumentiert getrennte logische, Dateisystem- und kontinuierliche Archivierungsansätze; die richtige Wahl hängt davon ab, wie Sie wiederherstellen müssen. Siehe die Backup-Übersicht. Wenn Artikel fotografiert hochgeladen werden, schließen Sie diese Dateien und die Beziehung zu ihren Datenbankeinträgen ein.
Führen Sie eine Wiederherstellungsübung in eine separate Testdatenbank und ein separates Verzeichnis durch. Finden Sie einen bekannten Artikel und die zugehörige Datei und prüfen Sie dann, ob die Anwendung beide lesen kann. Notieren Sie das gewählte Backup, den Datenzeitstempel, die erforderlichen Schritte und das tatsächliche Ergebnis. Der erste Wiederherstellungsleitfaden entwickelt diese Übung. Eine optionale Katalog-Backup-Auswahl beweist nicht, dass diese Wiederherstellung auf Anwendungsebene funktioniert.
Triff die nächste Entscheidung auf Basis von Belegen
Bleiben Sie beim einfachen Design, solange sein gemessenes Verhalten und die Wiederherstellungsanforderungen passen. Untersuchen Sie eine gestoppte Anwendung oder Ressourcenwarnungen bevor Sie annehmen, dass ein größerer Plan die Antwort ist. Wählen Sie Malaysia, Rumänien oder die Schweiz für den Server und bestätigen Sie dann Ressourcenzuweisung, Backup-Speicherort und Leistungsumfang. Dieses Szenario begründet keine Einrichtung, Anforderungskapazität oder Lieferzeit.
Build konfigurieren und jede Option prüfen. Der Link öffnet den Startplan; prüfen Sie den ausgewählten Zeitraum und alle gespeicherten Auswahlen, bevor Sie fortfahren. Das Abrufen von Zahlungsdaten installiert nicht die Ausleih-Anwendung für Ausrüstung.
Verwendete Dokumentation
Primäre Referenzen für diese Seite. Überprüfen Sie die Dokumentation für die in Ihrer eigenen Umgebung installierte Version.