เว็บไซต์ Static ยังออนไลน์อยู่ระหว่างการเผยแพร่ซ้ำ

การเผยแพร่เว็บ static ซ้ำบน Mythex เคยลบไฟล์ที่ใช้งานอยู่ก่อน แล้วจึงอัปโหลด build ใหม่ ดังนั้นตลอดช่วงที่อัปโหลด ผู้เข้าชมบางคนได้หน้า 404 หรือหน้าที่สคริปต์หายไป การอัปโหลดที่ล้มเหลวอาจทำให้เว็บว่างเปล่าหรือครึ่งใหม่ครึ่งเก่า ตอนนี้ build ใหม่จะถูกเขียนทับของเก่า โดยหน้าจะถูกเขียนเป็นลำดับสุดท้าย และไฟล์ที่เหลือจะถูกลบออกไม่กี่นาทีต่อมา การแก้ไขที่สองทำให้การเผยแพร่ซ้ำแสดงผลภายในไม่กี่วินาที แทนที่จะเป็นหนึ่งนาที หรือสำหรับไฟล์อย่างโลโก้ อาจนานถึงหนึ่งวัน

เว็บ static ถูกเสิร์ฟอย่างไร

เว็บ static คือเว็บที่เป็นไฟล์ล้วนๆ ได้แก่หน้า HTML, JavaScript, CSS และรูปภาพ เมื่อคุณเผยแพร่บน Mythex เราจะ build มัน อัปโหลดผลลัพธ์ไปยัง object storage ภายใต้โฟลเดอร์ของเว็บคุณ แล้วเสิร์ฟผ่าน edge network ซึ่งเป็นเซิร์ฟเวอร์ที่อยู่ใกล้ผู้เข้าชม ดึงไฟล์จาก storage และเก็บสำเนาไว้ระยะหนึ่ง (หากคุณเพิ่งเริ่ม คู่มือของเราเรื่อง CDN คืออะไร อธิบายแนวคิดนี้)

มีสองอย่างที่ผิด ได้แก่ลำดับที่การเผยแพร่ซ้ำเปลี่ยนไฟล์ และระยะเวลาที่เก็บสำเนาเก่าไว้

ปัญหาที่ 1: การอัปโหลดทำให้เว็บว่างก่อน

การเผยแพร่ซ้ำจะลบทุกอย่างในโฟลเดอร์ของเว็บ แล้วอัปโหลด build ใหม่ ตลอดระยะเวลาที่การอัปโหลดใช้ (12 วินาทีสำหรับเว็บ 250 ไฟล์ในการทดสอบภายในของเรา) ผู้เข้าชมที่คำขอยังไม่ถูกแคชที่ edge จะได้ 404 หรือหน้า HTML ที่สคริปต์ของมันได้ 404

การอัปโหลดที่ล้มเหลวแย่กว่านั้น โฟลเดอร์ว่างไปแล้ว และในวิธีอัปโหลดวิธีหนึ่งจากสองวิธี index.html ใหม่อาจลงไปก่อนไฟล์ที่ล้มเหลว การเผยแพร่ที่รายงานว่าล้มเหลวอาจทำให้เว็บครึ่งใหม่ยังออนไลน์อยู่

วิธีแก้: เขียนทับ หน้าเป็นลำดับสุดท้าย ลบทีหลัง

1. อย่าลบก่อน อัปโหลด build ใหม่ทับของเก่า
2. ทรัพยากรก่อนหน้า หน้าจะระบุสคริปต์และสไตล์ที่ต้องใช้ ดังนั้นหน้าจะถูกอัปโหลดเป็นลำดับสุดท้าย จนกว่าหน้าใหม่จะลง ผู้เข้าชมจะได้หน้าเก่า ซึ่งอ้างถึงทรัพยากรเก่าที่ยังอยู่ เมื่อหน้าใหม่ลงแล้ว ทรัพยากรใหม่ที่หน้าอ้างถึงก็อยู่ในที่ของมันแล้ว
3. ลบส่วนที่เหลือทีหลัง ก่อนการอัปโหลด เราบันทึกรายการไฟล์ที่เว็บประกอบด้วย สามนาทีหลังอัปโหลดสำเร็จ ไฟล์ใดในรายการนั้นที่ build ใหม่ไม่ได้เขียนทับ จะถูกลบ สามนาทีนานกว่า 60 วินาทีที่หน้าอาจถูกแคชไว้ที่ edge และในเบราว์เซอร์ ดังนั้นผู้เข้าชมที่ยังถือหน้าเก่าอยู่ก็ยังหาทรัพยากรที่หน้านั้นอ้างถึงได้
4. ถ้าไม่แน่ใจ อย่าลบอะไรเลย หากการแสดงรายการก่อนอัปโหลดล้มเหลว จะไม่มีการลบ ไฟล์ที่เหลือไม่เป็นอันตราย และการเผยแพร่ครั้งถัดไปจะเคลียร์ให้ การลบโดยไม่รู้ว่ามีอะไรอยู่คือวิธีที่ทำให้เว็บว่างเปล่า

ตอนนี้การอัปโหลดที่ล้มเหลวจะทิ้งเว็บเดิมไว้เหมือนเดิมทุกประการ

เราทดสอบแบบ end-to-end ภายในเครื่องโดยใช้สคริปต์อัปโหลดจริง route อัปโหลดจริง และการเสิร์ฟ storage จริง พร้อมผู้เข้าชมที่มาถึงโดยไม่มีแคช edge เลย ด้วยโค้ดเก่า 55 จาก 91 การเข้าชมเสียหายระหว่างการเผยแพร่ซ้ำ และ 61 จาก 92 ระหว่างการเผยแพร่ที่ล้มเหลว ด้วยโค้ดใหม่ 0 การเข้าชมเสียหายจากราว 3,500 ครั้ง ครอบคลุมทั้งสองวิธีอัปโหลด การอัปโหลดที่ล้มเหลว และการเผยแพร่หลังจากนั้น และไฟล์ที่เหลือถูกลบตรงตามที่ควรลบ

ปัญหาที่ 2: การเผยแพร่ซ้ำใช้เวลานานกว่าจะแสดงผล

แม้การอัปโหลดจะสำเร็จ การเปลี่ยนแปลงก็ปรากฏช้า edge เก็บสำเนาหน้าไว้ 60 วินาที และไฟล์อื่นทุกไฟล์ไว้หนึ่งวัน พร้อมบอกเบราว์เซอร์ให้ทำเช่นเดียวกัน ไฟล์ที่ชื่อคงที่ เช่น logo.png ฟอนต์ หรืออะไรก็ตามจากโฟลเดอร์ public/ อาจแสดงเวอร์ชันเก่านานถึงหนึ่งวันหลังการเผยแพร่ซ้ำ

วิธีแก้: สำเนาไฟล์อยู่ภายใต้ build

เมื่อ edge ถาม API ของเราว่าเว็บอยู่ที่ไหน คำตอบตอนนี้รวมตัวบ่งชี้ build ที่เปลี่ยนทุกครั้งที่การเผยแพร่ลง edge จะเก็บสำเนาของมันภายใต้ตัวบ่งชี้นั้น ดังนั้นการเผยแพร่จึงกลายเป็นชุดคีย์แคชใหม่ทั้งชุดทันทีที่การค้นหา 30 วินาทีของ edge หมดอายุ สำเนาเก่าจะไม่ถูกหาเจออีกเลย ดังนั้น edge จึงเก็บสำเนาได้หนึ่งวันโดยไม่มีวันเสิร์ฟสำเนาที่เกินการเผยแพร่ที่มาแทนที่

เบราว์เซอร์ได้กฎสองแบบที่ต่างกัน:

• ผลลัพธ์ build ที่มี hash ไฟล์อย่าง assets/index-CzLcxDO8.js ซึ่งชื่อเปลี่ยนเมื่อเนื้อหาเปลี่ยน จะถูกแคชหนึ่งปีและมาร์กว่า immutable มันจะไม่มีวันเก่าภายใต้ชื่อนั้น
• อย่างอื่นทั้งหมด หน้าและไฟล์ชื่อคงที่อย่างโลโก้ จะถูกมาร์กว่า no-cache ซึ่งหมายถึง "ตรวจสอบก่อนใช้" หากไม่มีอะไรเปลี่ยน คำตอบจะเป็น 304 Not Modified เล็กๆ ที่ไม่มีเนื้อหา เพราะตอนนี้เราเคารพการตรวจสอบ If-None-Match ของเบราว์เซอร์แล้ว

การแยกสองแบบนี้ต้องระวัง ไฟล์ที่คัดลอกจาก public/assets/ ยังคงชื่อเดิมของมัน และการแคชไฟล์ assets/logo.png ไว้หนึ่งปีจะตรึงโลโก้เก่าไว้หนึ่งปี ดังนั้นไฟล์จะนับเป็น hash ก็ต่อเมื่ออยู่ในโฟลเดอร์ผลลัพธ์ build และ ชื่อของมันมีส่วนที่ดูเหมือน hash ไม่ใช่คำธรรมดา

ในเครื่อง หน้าใหม่และโลโก้ใหม่ปรากฏ 6 วินาที หลังการเผยแพร่ขึ้นระบบ ก่อนหน้านี้คือ 60 วินาทีสำหรับหน้า และหนึ่งวันสำหรับโลโก้

การแก้ไขเล็กอีกสองอย่างระหว่างทาง

• หน้าว่างจากคำขอ HEAD คำขอ HEAD ขอ header ของหน้าโดยไม่เอาเนื้อหา เรากำลังแคชการตอบกลับว่างเหล่านั้น ดังนั้นผู้เข้าชมคนต่อไปที่เข้าหน้านั้นจึงเห็นหน้าว่าง ตอนนี้การตอบกลับ HEAD จะไม่ถูกแคชอีก
• หน้าจริงสำหรับ "ไม่มีอะไรที่นี่" ที่อยู่ที่ไม่มีแอปเคยได้ข้อความธรรมดาว่า "This published app is offline or the link was not found" พร้อมรหัสข้อผิดพลาด 502 ตอนนี้จะได้หน้าที่เหมาะสมชื่อ "There's no app here" พร้อมสถานะ 404 และทางกลับไปยัง Mythex สำหรับเจ้าของ โดเมนที่กำหนดเองซึ่งไม่รู้จักก็ได้หน้าเดียวกัน

สิ่งที่เราเรียนรู้

• ลำดับเป็นส่วนหนึ่งของความถูกต้อง ไฟล์ชุดเดียวกันที่อัปโหลดด้วยลำดับต่างกันคือความต่างระหว่างเว็บที่เสียกับเว็บที่ใช้งานได้
• ลบทีหลัง และลบเฉพาะสิ่งที่รู้ การลบด้วยรายการที่ถ่ายก่อนอัปโหลดปลอดภัย การล้างโฟลเดอร์แล้วหวังว่าการอัปโหลดจะเสร็จไม่ปลอดภัย
• แคชตามเวอร์ชัน ไม่ใช่ตามเวลา เวลาหมดอายุเป็นการเดาว่าเนื้อหาเปลี่ยนเมื่อใด คีย์ที่เปลี่ยนไปตาม build คือความจริง

เกี่ยวข้อง: แอปที่เผยแพร่แล้วของคุณยังออนไลน์อยู่ระหว่างที่คุณเผยแพร่ซ้ำ และดูเรื่องการเผยแพร่เพิ่มเติมได้ในเอกสาร