Cung cấp tài nguyên CSS và CSS cục bộ cho dự phòng CDN

Cho rằng

• CDN là một điều tốt vì chúng có thể phục vụ các tài nguyên gần hơn với máy khách, máy khách có thể lưu trữ chúng và bạn có thể giảm tải trên máy chủ của riêng mình.
• Trong các trình duyệt gần đây, tải tài nguyên từ máy chủ của bên thứ ba không làm giảm tính bảo mật nhờ tính toàn vẹn của nguồn cung cấp phụ (SRI) .
• CDN có thể bị ngừng hoặc bị chặn ở một số quốc gia và không khả dụng khi phát triển ngoại tuyến ¹ .

Tôi nghĩ việc sử dụng CDN là bắt buộc, nhưng cũng phải chuẩn bị cho chúng là không có sẵn. Bài đăng trên blog này giới thiệu tốt về các phương pháp khác nhau để cung cấp dự phòng. Nếu bạn nhìn vào ví dụ Cơ bản , bạn có thể thấy rằng nó đã chứa khá nhiều mã soạn sẵn để cung cấp dự phòng cho chỉ jQuery và Bootstrap, trong khi giải pháp được ưa thích cho thấy sử dụng Fallback.js , dường như hầu như không được biết đến trong năm qua . Tương tự, câu hỏi SO phù hợp nhất cho chủ đề chỉ là về việc cung cấp dự phòng cho jQuery.

Tuy nhiên, trong hầu hết các dự án trong thế giới thực, tôi dự kiến ​​sẽ có 5 tài nguyên js / css trở lên, vì vậy tôi cảm thấy như bạn không cần phải lặp lại một số bản tóm tắt lộn xộn để cung cấp dự phòng cho tất cả chúng. Hơn nữa, mỗi khi bạn thêm hoặc cập nhật tài nguyên, bây giờ bạn phải

• Cập nhật liên kết CDN
• Cập nhật bản sao dự phòng cục bộ bằng cách tải xuống thủ công hoặc thay đổi phiên bản trong cấu hình npm / bower
• Cập nhật liên kết đến dự phòng
• Cập nhật hàm băm SRI

Trong thế giới lý tưởng , tôi mong đợi sẽ thêm / cập nhật tài nguyên trong một tệp cấu hình và để tất cả các bước khác thực hiện tự động (và sau đó chạy thử nghiệm để xem liệu bản cập nhật có phá vỡ gì không).

Đã có một quy trình làm việc được thiết lập để đạt được điều này?

Hay là CDN, và đặc biệt là SRI, vẫn còn quá gần đây?

Hay hầu hết mọi người chỉ đơn giản là không quan tâm đến việc cung cấp dự phòng cho tài nguyên CDN?

_{1. Mặc dù bạn có thể có một bản dựng dev không dựa vào CDN, nhưng tôi cũng coi đó là một dạng dự phòng, vì nó cũng cần được duy trì.}

Tôi nghĩ có lẽ bạn hiểu nhầm các trang web lớn hơn có thể cần loại khả năng phục hồi này sử dụng CDN như thế nào.

nó không chỉ là vấn đề lưu trữ jQuery hay một số hình ảnh. Phần lớn trang web sẽ được lưu trữ trên CDN, chỉ với những thứ được tạo động như trang thanh toán hoặc giỏ mua hàng được lưu trữ trên 'webfarms chính'

Ngay cả những thứ này đang di chuyển ngày càng nhiều hơn để được xử lý cục bộ với JS và cookie để hiển thị nội dung cụ thể của người dùng mà không cần xử lý phía máy chủ.

Nếu CDN thất bại và bạn bắt đầu nhận được tất cả lưu lượng truy cập đến máy chủ web của mình, nó có khả năng bị đổ, nếu không bạn không thực sự cần CDN.

Trang web tôi làm việc trên CDN của chúng tôi ngày càng trở nên quan trọng đối với trang web. Ban đầu, chúng tôi chỉ đơn giản sử dụng nó để lưu trữ hình ảnh / CSS / JS. Ở giai đoạn này, chúng tôi đã có một thuộc tính cấu hình để viết lại tên máy chủ của các tài nguyên này từ www.mysite.com/ thành www.cdn.com/ vì vậy nếu CDN bị hỏng, chúng tôi chỉ cần thay đổi giá trị máy chủ này hoặc tắt hoàn toàn các url trỏ đến máy chủ web của chúng tôi.

Tuy nhiên, hiện tại chúng tôi đã chuyển sang bộ nhớ đệm về cơ bản toàn bộ các trang có nội dung được cá nhân hóa được tải thông qua AJAX. CDN của chúng tôi đã trở nên thiết yếu đối với trang web của chúng tôi và chúng tôi có thể chạy nhiều mà không cần nó như các máy chủ HTTP của chúng tôi. Chúng tôi trả tiền tốt cho CDN một phần vì có khả năng phục hồi và SLA hứa hẹn về thời gian hoạt động do đó đặt thời gian và nỗ lực vào dự phòng dường như là một sự lãng phí thời gian. Chúng tôi có kế hoạch DR ngay khi có vấn đề lớn với nhà cung cấp của chúng tôi nhưng đó không phải là quy trình tự động đơn giản và sẽ thấy thời gian ngừng hoạt động khi chúng tôi di chuyển sang CDN dự phòng.

Vì vậy, để trả lời cho câu hỏi của bạn, nó phụ thuộc vào mức độ tích hợp của trang web của bạn với CDN. Nếu đó chỉ là tài sản của bạn mà bạn đang đưa vào CDN và giả sử máy chủ http của bạn có thể xử lý tải của việc cung cấp nội dung này thì bạn có thể sử dụng công tắc cấu hình để bật hoặc tắt CDN. Kết hợp với một công cụ giám sát, bạn có thể tự động bật hoặc tắt công tắc.

Tôi thấy 3 lý do rất quan trọng để sử dụng CDN:

1. Giảm độ trễ mạng cho người dùng ở các khu vực xa. Khi bạn có một trang web dành cho khán giả toàn cầu, việc lưu trữ của bạn ở Bắc Mỹ dường như không nhanh đối với người dùng ở Nam Á, đặc biệt là ở Trung Quốc. Sự khác biệt về trải nghiệm người dùng có thể rất lớn đến nỗi nó sẽ không khuyến khích người dùng sử dụng trang web của bạn. Trong trường hợp này CDN đa khu vực sẽ rất cần thiết cho doanh nghiệp của bạn.

2. Phục vụ càng nhiều càng tốt từ nguồn tài nguyên có sẵn cao. Độ tin cậy là một trong những lý do chính để sử dụng CDN trên đám mây - lưu lượng được tự động định tuyến lại cho các nút có sẵn và bạn có thể thêm một số biện pháp bổ sung để định tuyến lại lưu lượng nếu toàn bộ khu vực đám mây bị hỏng.

3. CDN dễ bảo trì và rẻ hơn so với các máy chủ ứng dụng phục vụ nội dung động. Khi bạn phải đối phó với các vấn đề nêu trên, đó là cách tự nhiên để tiết kiệm tiền.

Tất cả điều này có nghĩa, mục tiêu của CDN là tăng tính khả dụng của nội dung của bạn cho người dùng cuối. Nếu CDN thất bại hoặc trở nên chậm vì một số lý do, dự phòng phía máy khách sẽ tăng đáng kể tải trang, vì trước tiên, nó sẽ cố gắng lấy tài nguyên không thể truy cập được. Giải pháp tốt hơn là thiết kế phía máy chủ sẽ thay thế URL cơ sở trong các liên kết như "{CDN} /js/jquery-version-min.js". Điều này sẽ cho phép định tuyến lại lưu lượng truy cập đến máy chủ ứng dụng thay vì CDN nếu kiểm tra sức khỏe CDN không thành công - khách hàng sẽ không thực hiện các yêu cầu không cần thiết và sẽ chuyển trực tiếp đến máy chủ ứng dụng, đó sẽ là dự phòng của bạn với giải pháp phía máy khách. Điều này cũng sẽ giải quyết vấn đề triển khai cục bộ và dàn dựng,