Phân phối giao diện người dùng trong kỷ nguyên xuất bản tần suất cao cần thiết kế lại bộ nhớ đệm và cộng tác nén

Một khi các tài nguyên front-end bước vào nhịp phát hành tần suất cao, các vấn đề về hiệu suất sẽ sớm không còn đơn giản như việc “bật Brotli”. Màn hình đầu tiên chậm lại, lưu lượng quay lại nguồn gốc tăng lên và CPU nút biên bị giật. Nhìn bề ngoài, có vẻ như lực nén chưa đủ mạnh. Nhìn sâu hơn, thường thì bộ nhớ đệm và tính năng nén được tối ưu hóa riêng biệt và cuối cùng làm suy yếu lẫn nhau trên liên kết xuất bản.

Loại vấn đề này thường không xuất hiện trong phiên bản đầu tiên. Lúc đầu, nhóm sẽ chỉ thấy một số tín hiệu rải rác: một thay đổi nhỏ đã gây ra sự cố về tốc độ truy cập của tài nguyên tĩnh, sự gia tăng bất thường về CPU nén cạnh trước thềm một chương trình khuyến mãi lớn và khối lượng gói trả lại trong giai đoạn thang độ xám không khớp với lưu lượng truy cập chính thức. Nếu bạn tiếp tục kiểm tra, các manh mối thường hội tụ về cùng một điều: mặc dù nội dung tài nguyên chỉ thay đổi một chút, nhưng khóa bộ đệm, phân tách đoạn và đầu vào nén đã trở thành một tập hợp khác và lớp vận chuyển buộc phải nuốt toàn bộ chi phí một lần nữa.

Cho đến khi hàm băm tài nguyên ổn định, lợi ích nén sẽ không thể đảm bảo được.

Sau khi các dự án front-end được phát hành song song với nhiều trang, nhiều tuyến và nhiều nhóm, khía cạnh dễ bị bỏ qua nhất là tính ổn định của tên tệp. Miễn là phân đoạn khối thay đổi một chút, ngay cả khi mã doanh nghiệp chỉ thay đổi bản sao của một nút, sản phẩm cuối cùng cũng có thể viết lại hàm băm của một loạt gói công khai. Những gì hệ thống bộ nhớ đệm nhìn thấy là một loạt đối tượng hoàn toàn mới và những gì hệ thống nén nhìn thấy là một loạt đầu vào xuất hiện lần đầu tiên.

Lúc này, dù tốc độ nén có cao đến đâu cũng không thể cứu được tốc độ trúng đòn khỏi bị sập. Các tệp cũ vẫn nằm trong các nút cạnh và các tệp mới đã được thay đổi khóa; bộ đệm cục bộ của trình duyệt hoàn toàn không hợp lệ và CDN phải kéo lại nguồn, nén lại và phân phối lại. Một thay đổi nhỏ trong kinh doanh sẽ được phóng đại thành công việc lặp đi lặp lại cho toàn bộ đường truyền.

Hành động thực sự hữu ích thường không phải là tiếp tục điều chỉnh mức độ nén mà trước tiên là kiểm soát độ ổn định của sản phẩm được phát hành:

• Các phần phụ thuộc công khai được cắt thành các lớp riêng biệt để giảm bớt những thay đổi trong kinh doanh và tập hợp các gói cơ bản lại với nhau để thay đổi hàm băm.
• Tránh trộn lẫn các thay đổi có tần suất cao như dấu thời gian và số bản dựng trực tiếp vào nội dung sản phẩm
• Hãy để mã gần cùng một tuyến đường rơi vào các đoạn ổn định càng nhiều càng tốt thay vì bị xáo trộn lại mỗi khi biên dịch.

Chỉ khi danh tính tài nguyên được ổn định thì bộ đệm mới có thể được sử dụng lại liên tục và kết quả nén mới có giá trị tích lũy.

Họp báo cao tần viết lại bài toán nén thành bài toán phiên bản từ điển

Khi tài nguyên ngày càng bị phân mảnh, Brotli hoặc gzip một tệp vẫn quan trọng, nhưng nó không còn là tất cả. Chi phí thực bắt đầu chuyển sang các phần trùng lặp: mã thời gian chạy khung, mẫu kiểu, khai báo loại giao diện, lớp đóng gói do trình đóng gói tạo ra, thường rất giống nhau giữa các lô phiên bản. Với nhịp độ phát hành nhanh, những đoạn riff này sẽ được chuyển đi chuyển lại nhiều lần.

Vấn đề là từ điển nén có thể dễ dàng chuyển từ tối ưu hóa sang gián đoạn nếu nó không được quản lý cùng với nhịp độ phát hành. Nếu từ điển được chuyển trước, từ điển mới được tham chiếu bởi trang cũ sẽ không khớp; từ điển bị cắt thành quá nhiều mảnh và số lượng phiên bản được duy trì bởi các nút cạnh tăng mạnh; bản cập nhật từ điển không được đồng bộ hóa với tài nguyên trực tuyến và các đối tượng đáng lẽ phải được truy cập sẽ được đưa trở lại chế độ truyền đầy đủ.

Đây cũng là một thay đổi rất thiết thực trong phân phối giao diện người dùng gần đây: các chiến lược bộ đệm và giao thức nén không còn có thể được duy trì bởi các nhóm khác nhau. Phiên bản tài nguyên, phiên bản từ điển và không gian khóa bộ đệm về cơ bản là cùng một vấn đề xuất bản.

Cách tiếp cận phân cấp như sau thường ổn định hơn “nén mạnh thống nhất cho toàn bộ trang web”:

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

Điều quan trọng không phải là cấu hình của ba dòng này mà là những hạn chế mà nó thể hiện: tài nguyên vòng đời dài, danh sách vòng đời ngắn và phiên bản từ điển nén phải phát triển cùng nhau theo cùng một nhịp phát hành.

Áp lực về nguồn thường không phải là file quá lớn mà là cách làm lỗi quá thô.

Một đánh giá sai lầm rất phổ biến khác là quy sự gia tăng băng thông trực tiếp vào trọng lượng của trang. Các trang chắc chắn ngày càng nặng hơn, nhưng những bộ khuếch đại trực tuyến nguy hiểm hơn thường là lựa chọn tốt nhất.

Nếu bạn lọc theo thư mục, tiền tố hoặc thậm chí toàn bộ trang web mỗi khi xuất bản, lớp bộ đệm sẽ mất bộ nhớ ngay lập tức. Tại thời điểm này, ngay cả khi kích thước tệp không tiếp tục tăng, giá trị đỉnh quay về nguồn gốc sẽ tự được đẩy lên. Ngay sau khi nguồn được trả về, các cạnh sẽ được nén lại, các đối tượng được làm ấm lại và trình duyệt được tải xuống lại. Cửa sổ xuất bản sẽ thay đổi từ một thay đổi từng bước nhỏ sang di chuyển toàn bộ trang web.

Trong loại kịch bản này, điều có giá trị nhất là bán kính hư hỏng có thể kiểm soát được:

• Chỉ vô hiệu hóa bảng kê khai, HTML và các tài nguyên có thể thay đổi đã thực sự thay đổi
• Cố gắng không lọc các tệp tĩnh bằng hàm băm và chuyển chúng sang các tài liệu tham khảo mới để chuyển đổi tự nhiên.
• Chia bản phát hành theo thứ tự “đầu tiên tải lên tài nguyên mới, sau đó cắt tài liệu tham khảo, sau đó tái chế tài nguyên cũ” thay vì xóa tất cả cùng một lúc

Điều thực sự nhạy cảm về chi phí truyền không chỉ là kích thước tệp mà còn là cách hệ thống quyết định nội dung nào phải được tìm nạp lại.

Ranh giới áp dụng được xác định cùng với quy mô tài nguyên và tần suất phát hành.

Bộ đồng thiết kế này không bắt buộc đối với tất cả các trang web. Đối với các dự án có số lượng trang tĩnh ít, gói tài nguyên nhỏ và tần suất phát hành hàng tuần hoặc thậm chí hàng tháng, việc sử dụng tên tệp băm truyền thống cộng với tính năng nén trước Brotli thường đủ ổn định.

Bộ nhớ đệm và nén cùng nhau nhanh chóng trở thành cơ sở hạ tầng phân phối khi có các đặc điểm sau:

• Được phát hành nhiều lần trong ngày, với các đợt ra mắt theo thang độ xám, khôi phục hoặc ra mắt theo khu vực
• Sản phẩm front-end có kích thước lớn, có nhiều public phụ thuộc và có các mối quan hệ chunk phức tạp.
• CDN, lưu trữ đối tượng, nén cạnh và bộ nhớ đệm của trình duyệt tham gia đồng thời vào liên kết truyền
• Lưu lượng truy cập cao đến mức tốc độ truy cập bộ đệm và giá trị đỉnh quay về nguồn gốc sẽ phản ánh trực tiếp chi phí và độ ổn định.

Sau khi quá trình phân phối giao diện người dùng bước vào giai đoạn này, quá trình nén không còn chỉ là “làm cho tệp nhỏ hơn” và bộ nhớ đệm không còn chỉ là “lưu trữ nhiều bản sao nội dung hơn”. Điều mà cả hai cùng nhau quyết định là: đối với một thay đổi kinh doanh nhỏ, liệu đó chỉ là gửi thêm một đoạn nữa hay liệu toàn bộ liên kết truyền tải có cần được chạy lại hay không. Bạn xuất bản càng thường xuyên thì sự khác biệt này càng trở nên đắt đỏ.