Die Front-End-Bereitstellung im Zeitalter des High-Frequency-Publishing erfordert eine Neugestaltung der Caching- und Komprimierungszusammenarbeit

Sobald Front-End-Ressourcen in einen Hochfrequenz-Release-Rhythmus eintreten, werden Leistungsprobleme bald nicht mehr so ​​einfach sein wie „Brotli einschalten“. Der erste Bildschirm wird langsamer, der Back-to-Origin-Verkehr nimmt zu und die CPU des Edge-Knotens zittert. Oberflächlich betrachtet scheint die Kompression nicht aggressiv genug zu sein. Bei näherer Betrachtung sind es häufig Caching und Komprimierung, die separat optimiert werden und sich schließlich beim Veröffentlichungslink gegenseitig untergraben.

Diese Art von Problem wird in der ersten Version im Allgemeinen nicht aufgedeckt. Zu Beginn sah das Team nur vereinzelte Signale: Eine kleine Änderung verursachte einen Zusammenbruch der Trefferquote statischer Ressourcen, einen abnormalen Anstieg der Edge-CPU-Komprimierung am Vorabend einer großen Werbeaktion und das Volumen der zurückgegebenen Pakete in der Graustufenstufe stimmte nicht mit dem offiziellen Datenverkehr überein. Wenn Sie weiter nachsehen, stimmen die Anhaltspunkte in der Regel überein: Obwohl sich der Ressourceninhalt nur geringfügig geändert hat, sind Cache-Schlüssel, Chunk-Splitting und komprimierte Eingabe zu anderen Dingen geworden, und die Transportschicht ist gezwungen, erneut die gesamten Kosten zu tragen.

Solange der Ressourcen-Hash nicht stabil ist, sind die Komprimierungsvorteile einfach unhaltbar.

Nachdem Frontend-Projekte parallel mit mehreren Seiten, mehreren Routen und mehreren Teams veröffentlicht werden, wird die Stabilität der Dateinamen am häufigsten übersehen. Solange die Chunk-Segmentierung leicht abweicht, selbst wenn der Geschäftscode nur die Kopie einer Schaltfläche ändert, kann das Endprodukt auch den Hash einer Reihe öffentlicher Bundles neu schreiben. Was das Caching-System sieht, ist ein Stapel völlig neuer Objekte, und was das Komprimierungssystem sieht, ist ein Stapel von Eingaben, die zum ersten Mal erscheinen.

Zu diesem Zeitpunkt kann die Trefferquote nicht vor dem Zusammenbruch bewahrt werden, egal wie hoch die Komprimierungsrate ist. Die alten Dateien liegen immer noch in den Edge-Knoten und die neuen Dateien wurden neu verschlüsselt; Der lokale Cache des Browsers ist völlig ungültig und das CDN muss die Quelle erneut abrufen, erneut komprimieren und erneut verteilen. Eine kleine geschäftliche Änderung wird zu wiederholten Arbeiten für die gesamte Übertragungsstrecke ausgeweitet.

Die wirklich sinnvolle Aktion besteht in der Regel nicht darin, die Komprimierungsstufe weiter anzupassen, sondern zunächst die Stabilität des freigegebenen Produkts zu kontrollieren:

– Öffentliche Abhängigkeiten werden in separate Schichten unterteilt, um geschäftliche Änderungen zu reduzieren und Basispakete zusammenzuführen, um den Hash zu ändern.

• Vermeiden Sie es, hochfrequente Änderungen wie Zeitstempel und Build-Zahlen direkt in den Produktinhalt einzumischen
• Lassen Sie den Code in der Nähe derselben Route so weit wie möglich in stabile Blöcke zerfallen, anstatt ihn bei jeder Kompilierung neu zu mischen.

Nur wenn die Ressourcenidentität stabilisiert ist, kann der Cache kontinuierlich wiederverwendet werden und die Komprimierungsergebnisse haben einen kumulativen Wert.

Hochfrequenz-Pressekonferenz schreibt das Komprimierungsproblem in ein Wörterbuchversionsproblem um

Da die Ressourcen immer fragmentierter werden, sind Einzeldatei-Brotli oder GZIP immer noch wichtig, aber nicht mehr alles. Die tatsächlichen Kosten beginnen sich in Richtung doppelter Teile zu verlagern: Framework-Laufzeitcode, Stilvorlagen, Schnittstellentypdeklarationen, von Paketierern generierte Verpackungsschichten sind zwischen den Versionsstapeln oft sehr ähnlich. Bei einem schnellen Release-Tempo werden diese Riffs immer wieder übertragen.

Das Problem besteht darin, dass das Komprimierungswörterbuch leicht von einer Optimierung zu einer Störung werden kann, wenn es nicht zusammen mit der Release-Kadenz verwaltet wird. Wenn das Wörterbuch im Voraus gewechselt wird, stimmt das neue Wörterbuch, auf das die alte Seite verweist, nicht überein; Das Wörterbuch wird in zu viele Teile zerlegt und die Anzahl der von Randknoten zu verwaltenden Versionen nimmt stark zu. Die Wörterbuchaktualisierung wird nicht mit der Online-Ressource synchronisiert und die Objekte, die hätten getroffen werden sollen, werden zur vollständigen Übertragung zurückgeführt.

Dies ist auch eine sehr praktische Änderung in der jüngsten Front-End-Bereitstellung: Caching-Strategien und Komprimierungsprotokolle können nicht mehr von verschiedenen Teams gepflegt werden. Ressourcenversionen, Wörterbuchversionen und Cache-Schlüsselbereiche sind im Wesentlichen dasselbe Veröffentlichungsproblem.

Ein hierarchischer Ansatz wie der folgende ist normalerweise stabiler als „einheitliche starke Komprimierung für die gesamte Site“:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

Der Schlüssel liegt nicht in der Konfiguration dieser drei Zeilen selbst, sondern in den Einschränkungen, die sie zum Ausdruck bringen: Ressourcen mit langem Lebenszyklus, Liste mit kurzem Lebenszyklus und komprimierte Wörterbuchversionen müssen sich gemeinsam nach demselben Veröffentlichungsrhythmus entwickeln.

Der Druck, zur Quelle zurückzukehren, besteht oft nicht darin, dass die Datei zu groß ist, sondern darin, dass die Fehlermethode zu grob ist.

Eine weitere sehr häufige Fehleinschätzung besteht darin, die Erhöhung der Bandbreite direkt auf das Gewicht der Seite zurückzuführen. Die Seiten werden sicherlich immer umfangreicher, aber die gefährlicheren Verstärker im Internet sind normalerweise der richtige Weg.

Wenn Sie bei jeder Veröffentlichung ein Verzeichnis, ein Präfix oder sogar die gesamte Site löschen, verliert die Cache-Ebene sofort ihren Speicher. Selbst wenn die Dateigröße zu diesem Zeitpunkt nicht weiter zunimmt, wird der Spitzenwert für die Rückkehr zum Ursprung von selbst erhöht. Sobald die Quelle zurückgegeben wird, werden die Kanten erneut komprimiert, die Objekte werden erneut erwärmt und der Browser wird erneut heruntergeladen. Das Veröffentlichungsfenster ändert sich von einer kleinen schrittweisen Änderung zu einer vollständigen Website-Verlagerung.

In einem solchen Szenario ist der kontrollierbare Fehlerradius das Wertvollste:

• Machen Sie nur Manifest-, HTML- und veränderbare Ressourcen ungültig, die tatsächlich geändert wurden
• Versuchen Sie, statische Dateien nicht mit Hash zu bereinigen, sondern sie für einen natürlichen Wechsel an neue Referenzen zu übergeben.
• Teilen Sie die Veröffentlichung in die Reihenfolge auf: „Zuerst neue Ressourcen hochladen, dann Referenzen entfernen, dann alte Ressourcen recyceln“, anstatt sie alle auf einmal zu löschen

Was bei den Übertragungskosten wirklich kritisch ist, ist nicht nur die Dateigröße, sondern auch die Art und Weise, wie das System entscheidet, welche Inhalte erneut abgerufen werden müssen.

Die anwendbare Grenze wird zusammen mit dem Ressourcenumfang und der Veröffentlichungshäufigkeit bestimmt.

Dieses Co-Design ist nicht für alle Websites erforderlich. Für Projekte mit einer kleinen Anzahl statischer Seiten, einem kleinen Ressourcenpaket und einer Veröffentlichungshäufigkeit von wöchentlich oder sogar monatlich ist die Verwendung traditioneller Hash-Dateinamen plus Brotli-Vorkomprimierung normalerweise stabil genug.

Caching und Komprimierung zusammen werden schnell zu einer Bereitstellungsinfrastruktur, sobald diese Merkmale vorhanden sind:

• Wird mehrmals täglich veröffentlicht, mit Graustufen, Rollback oder regionalen Veröffentlichungen
• Das Front-End-Produkt ist groß, weist viele öffentliche Abhängigkeiten und komplexe Blockbeziehungen auf.
• CDN, Objektspeicher, Kantenkomprimierung und Browser-Caching sind gleichzeitig an der Übertragungsverbindung beteiligt
• Der Datenverkehr ist so hoch, dass die Cache-Trefferrate und der Return-to-Origin-Spitzenwert direkt die Kosten und Stabilität widerspiegeln.

Nachdem die Front-End-Bereitstellung in diese Phase eintritt, bedeutet Komprimierung nicht mehr nur „Dateien kleiner machen“ und Caching nicht mehr nur „Speichern weiterer Kopien von Inhalten“. Was die beiden gemeinsam entscheiden, ist: Bei einem kleinen Unternehmen ändert sich, ob nur ein weiterer Chunk gesendet werden soll oder ob die gesamte Übertragungsstrecke neu gefahren werden muss. Je häufiger Sie veröffentlichen, desto teurer wird dieser Unterschied.