- Sử dụng Cloud Run để phục vụ Tệp tĩnh - 1
- Bài đăng trên blog về cách sử dụng Google Cloud Run để cung cấp các tệp tĩnh. Bài viết tập trung vào việc chuyển hướng và cải thiện hiệu năng.
Bài viết được dịch bởi AI.
Bài viết được tóm tắt bởi durumis AI
- Chúng tôi đã xây dựng một hệ thống CDN kết hợp Google Cloud Storage (GCS) và Cloud Run để quản lý hình ảnh và tài nguyên web hiệu quả, đồng thời cung cấp các tệp được tối ưu hóa cho môi trường trình duyệt web.
- Hình ảnh được tải lên sẽ được chuyển đổi và lưu trữ ở nhiều định dạng khác nhau như webp, avif, trong khi các tệp văn bản được nén bằng gzip, br để cung cấp nội dung tối ưu cho người dùng.
- Cloud Storage và Cloud Run được triển khai trên 8 vùng trên toàn cầu để phân phối tài nguyên từ vùng gần nhất với vị trí người dùng, giúp giảm thiểu độ trễ và cải thiện trải nghiệm người dùng.
Bài viết trướcđã giải thích về việc sử dụng Cloud Run mà durumis đang sử dụng để phục vụ các tệp tĩnh.
Tuy nhiên, không giống như các tệp như robots.txt hoặc favicon.ico, các tệp hình ảnh được đăng trên blog hoặc tài nguyên của trang web chính nó không thể được xử lý đơn giản như các tệp tĩnh.
Do đó, các tệp này cần phải được sử dụng Cloud Run được liên kết với Google Cloud Storage (sau đây gọi là GCS).
Khái niệm cơ bản rất đơn giản. Các tệp hình ảnh được tải lên theo thời gian thực hoặc các tài nguyên mới được tải lên khi trang web được cập nhật sẽ được tải lên GCS, và khi có yêu cầu từ bên ngoài, Cloud Run sẽ kiểm tra xem tệp có trong GCS hay không, và nếu có, nó sẽ chuyển tiếp tệp đó.
Tuy nhiên, cách thức hoạt động thực tế phức tạp hơn nhiều so với điều đó.
Về cơ bản, khi tải tệp hình ảnh lên GCS, durumis chuyển đổi tệp hình ảnh thành 3 dạng.
Khi tải lên, nếu là jpeg hoặc png, tệp hình ảnh đó sẽ được chuyển đổi thành webp và avif và lưu trữ cùng một lúc.
Tất cả các tệp hình ảnh sẽ được yêu cầu bằng URL dưới dạng không có phần mở rộng, và khi có yêu cầu, Cloud Run sẽ kiểm tra tiêu đề của trình duyệt web đang yêu cầu để xác nhận xem trình duyệt web có thể nhận tệp hình ảnh avif, webp theo thứ tự ưu tiên hay không, và nếu không thể nhận được cả hai tệp, nó sẽ được chuyển tiếp dưới dạng jpeg hoặc png. Ngoài ra, không chỉ đơn giản là thay đổi định dạng, mà còn thu nhỏ trước và lưu trữ/chuyển tiếp theo kích thước cần thiết trên trang web.
Biểu đồ
Tương tự với tệp văn bản.
Nhiều tài nguyên được trang web cần không chỉ là hình ảnh mà còn là các tệp văn bản như js và css.
Các tệp js và css cũng tương tự như hình ảnh, được nén bằng gzip và br khi tải lên và lưu trữ, và khi có yêu cầu, tệp được trình duyệt web hỗ trợ sẽ được chuyển tiếp trực tiếp.
Vai trò của CDN không chỉ đơn thuần là lưu trữ nội dung. Trong trường hợp của Google Cloud Platform (GCP), chức năng Cloud CDN có thể được kết nối trực tiếp với Google Cloud Load Balancer (GCLB), cung cấp các chức năng mạnh mẽ hơn.
Cloud CDN nhận dữ liệu từ Backend Service, lưu trữ nó và sau đó chuyển tiếp đến máy khách. Trong quá trình này, Cloud CDN có thể gửi tệp được tối ưu hóa dựa trên tiêu đề yêu cầu của máy khách. Điều này cho phép cung cấp nhiều loại nội dung khác nhau cho cùng một URL.
Ví dụ, đối với cùng một URL '/image/tempImage',
- Trong trường hợp tệp hình ảnh
- Gửi các định dạng hình ảnh khác nhau dựa trên tiêu đề 'Accept' của trình duyệt.
- Trình duyệt Chrome thường hiển thị độ ưu tiên theo thứ tự 'image/avif,image/webp,image/apng'.
- CDN sẽ cung cấp các định dạng hình ảnh có thể dựa trên thứ tự này và thay thế bằng định dạng jpeg hoặc png nếu không được hỗ trợ.
- Tương tự, trong trường hợp tệp văn bản
- Độ ưu tiên cho phương thức nén cũng được xem xét.
- Trình duyệt Chrome hỗ trợ các phương thức nén như 'gzip, deflate, br, zstd'.
- Ví dụ, trong trường hợp dịch vụ durumis, hiện tại gzip và br được hỗ trợ, vì vậy tệp nén br sẽ được gửi ưu tiên.
Các tính năng nâng cao của CDN này cho phép cung cấp nội dung được tối ưu hóa cho môi trường của người dùng, điều này có thể cải thiện đáng kể hiệu năng và trải nghiệm người dùng của trang web.
Ngay cả khi đó là Cloud CDN, về cơ bản, yêu cầu tệp vẫn cần thiết từ CDN đến Cloud Run, vì vậy trong trường hợp của durumis, Cloud Storage và Cloud Run được triển khai trước tại 8 vùng trên toàn cầu để triển khai trước các tài nguyên và gửi các tài nguyên đó. Do đó, mặc dù có một số chi phí và khối lượng công việc tăng lên, nhưng người dùng có thể trải nghiệm độ trễ được cải thiện đáng kể.
Ngay cả khi sử dụng Cloud CDN, về cơ bản, bạn vẫn cần phải lấy tệp từ máy chủ gốc (trong trường hợp này là Cloud Run). Durumis đang tối ưu hóa cấu trúc này để cung cấp dịch vụ tốt hơn cho người dùng trên toàn cầu.
Chiến lược tối ưu hóa toàn cầu của durumis:
- Triển khai Cloud Storage và Cloud Run trước tại 8 vùng trên toàn cầu
- Phân phối trước các tài nguyên cần thiết cho từng vùng
- Gửi tài nguyên từ vùng gần nhất khi có yêu cầu từ người dùng
Phương pháp này yêu cầu một số chi phí và công việc bổ sung, nhưng mang lại những lợi ích sau cho người dùng:
- Độ trễ được cải thiện đáng kể
- Thời gian tải nội dung nhanh hơn
- Cải thiện trải nghiệm người dùng tổng thể
Hình dung cấu trúc này như sau:
Thông qua cấu trúc này, durumis có thể cung cấp dịch vụ nhanh chóng và nhất quán cho người dùng trên toàn cầu. Bởi vì nội dung được cung cấp từ vùng gần nhất với vị trí của người dùng, nên dịch vụ có thể được sử dụng với độ trễ thấp ở bất cứ đâu trên thế giới.
Cách tiếp cận này đòi hỏi nhiều nỗ lực hơn cho việc thiết lập và bảo trì ban đầu, nhưng nó mang lại lợi ích to lớn trong việc cải thiện trải nghiệm của người dùng cuối cùng. Đặc biệt, đối với các công ty cung cấp dịch vụ toàn cầu, cấu trúc này có thể giúp cung cấp dịch vụ cạnh tranh.
Trong câu chuyện về CDN hôm nay, chúng ta chỉ xem xét các khái niệm cơ bản.
Trên thực tế, chúng ta cũng có thể thảo luận về các phần cấu hình chi tiết, nhưng vì nó khác nhau giữa các nhà cung cấp đám mây (GCP, Azure, AWS) và nó không thú vị lắm nên tôi đã giải thích các khái niệm.
Nếu có cơ hội sau này, tôi sẽ thảo luận thêm về các chi tiết.
Vậy thì, câu chuyện tiếp theo sẽ là về cách đồng bộ hóa Cloud Storage trong nhiều vùng (chúng tôi có tới 8 vùng!).
Cảm ơn bạn.