Zapewnienie lokalnych zasobów JS i CSS na potrzeby awarii CDN

Jeśli się uwzględni

• Sieci CDN są dobrą rzeczą, ponieważ mogą obsługiwać zasoby bliżej klienta, klient może je buforować i można zmniejszyć obciążenie własnego serwera.
• W najnowszych przeglądarkach ładowanie zasobów z serwerów innych firm nie zmniejsza bezpieczeństwa dzięki Subresource Integrity (SRI) .
• Sieci CDN mogą być niedostępne lub zablokowane w niektórych krajach i nie są dostępne przy programowaniu offline ¹ .

Myślę, że korzystanie z sieci CDN jest konieczne, ale trzeba też być przygotowanym na ich niedostępność. Ten post na blogu stanowi miłe wprowadzenie do różnych podejść do zapewniania rezerw. Jeśli spojrzysz na przykład podstawowy , zobaczysz, że zawiera on już sporo kodu z podstawowymi kodami, aby zapewnić awarie tylko dla jQuery i Bootstrap, podczas gdy preferowane rozwiązanie sugeruje użycie Fallback.js , co wydaje się w dużej mierze nieobsługiwane przez ostatni rok . Podobnie, najtrafniejsze pytanie SO w tym temacie dotyczy jedynie zapewnienia rezerwy dla jQuery.

Jednak w większości rzeczywistych projektów spodziewałbym się, że będę mieć 5 lub więcej zasobów js / css, więc uważam, że nie powinieneś powtarzać jakiegoś bałaganu, aby zapewnić awarie wszystkim z nich. Ponadto za każdym razem, gdy dodajesz lub aktualizujesz zasób, musisz to zrobić

• Zaktualizuj łącze CDN
• Zaktualizuj lokalną kopię zapasową przez ręczne pobranie lub zmianę wersji w konfiguracji npm / bower
• Zaktualizuj link do kreacji zastępczej
• Zaktualizuj skrót SRI

Podczas gdy w Idealnym Świecie spodziewam się dodać / zaktualizować zasób w jednym pliku konfiguracyjnym, a wszystkie pozostałe kroki wykonają się automatycznie (a następnie uruchomią testy, aby sprawdzić, czy aktualizacja coś zepsuła).

Czy istnieje już ustalony przepływ pracy, aby to osiągnąć?

A może CDN, a zwłaszcza SRI, są wciąż zbyt nowe?

Czy też większość ludzi po prostu nie chce zapewnić rezerw dla zasobów CDN?

_{1. Chociaż możesz mieć wersję deweloperską, która nie opiera się na CDN, ale uważam również, że jest to forma rezerwowa, ponieważ należy ją również zachować.}

Myślę, że być może źle zrozumiałeś, jak większe witryny, które mogą potrzebować tego rodzaju odporności, używają sieci CDN.

to nie tylko kwestia hostowania jQuery lub niektórych zdjęć. Większość witryny będzie hostowana w sieci CDN, a tylko „dynamicznie generowane rzeczy”, takie jak strony płatności lub koszyki zakupów, będą hostowane w „głównych sklepach internetowych”

Nawet te coraz częściej zaczynają być przetwarzane lokalnie za pomocą JS i plików cookie, aby wyświetlać rzeczy specyficzne dla użytkownika bez konieczności przetwarzania po stronie serwera.

Jeśli CDN zawiedzie i zaczniesz otrzymywać cały ruch przekazywany do twojego serwera, prawdopodobnie się przewróci, w przeciwnym razie tak naprawdę nie potrzebujesz CDN.

Witryna, nad którą pracuję nad naszym CDN, zyskuje na znaczeniu. Na początku po prostu użyliśmy go do buforowania obrazów / CSS / JS. Na tym etapie mieliśmy właściwość config, która przepisała nazwę hosta tych zasobów z www.mysite.com/ na www.cdn.com/, więc jeśli CDN spadł, moglibyśmy po prostu zmienić tę wartość hosta lub całkowicie ją wyłączyć i wyjść adresy URL wskazujące nasz serwer.

Jednak teraz przeszliśmy do buforowania w zasadzie całych stron z spersonalizowaną treścią ładowaną za pośrednictwem AJAX. Nasza sieć CDN stała się niezbędna dla naszej witryny i moglibyśmy bez niej działać tak samo, jak nasze własne serwery HTTP. Płacimy naszym CDN dobre pieniądze po części z powodu odporności i obietnic SLA dotyczących przestojów, dlatego wkładanie czasu i wysiłku w awarie wydaje się stratą czasu. Mamy już plan DR, na wypadek gdyby wystąpił poważny problem z naszym dostawcą, ale nie jest to prosty zautomatyzowany proces, który przejdzie okres przestoju, gdy przeprowadzimy migrację do naszej zastępczej sieci CDN.

Zatem odpowiedź na twoje pytanie zależy od tego, jak integralna jest twoja strona CDN. Jeśli to tylko twoje zasoby wkładasz do CDN i zakładając, że twoje serwery http poradzą sobie z obciążeniem udostępniania tej zawartości, możesz użyć przełącznika config, aby zasadniczo włączyć lub wyłączyć CDN. W połączeniu z narzędziem do monitorowania możesz zautomatyzować włączanie i wyłączanie tego przełącznika.

Widzę 3 bardzo ważne powody korzystania z sieci CDN:

1. Zmniejsz opóźnienie sieci dla użytkowników w odległych regionach. Gdy masz witrynę internetową dla globalnej publiczności, hosting w Ameryce Północnej nie wydaje się szybki dla użytkowników w Azji Południowej, zwłaszcza w Chinach. Różnica w doświadczeniu użytkowników może być tak duża, że ​​zniechęci użytkowników do korzystania z Twojej witryny. W takim przypadku wielonarodowy CDN będzie niezbędny dla Twojej firmy.

2. Podawaj jak najwięcej z wysoce dostępnych zasobów. Niezawodność jest jednym z głównych powodów korzystania z CDN w chmurze - ruch jest automatycznie przekierowywany do dostępnych węzłów i można dodać dodatkowe środki w celu przekierowania ruchu, jeśli cały region chmury jest wyłączony.

3. CDN jest łatwiejszy w utrzymaniu i tańszy niż serwery aplikacji obsługujące zawartość dynamiczną. Kiedy masz do czynienia z wyżej wymienionymi problemami, to naturalny sposób na zaoszczędzenie pieniędzy.

Wszystko to oznacza, że ​​celem CDN jest zwiększenie dostępności treści dla użytkowników końcowych. Jeśli CDN ulegnie awarii lub stanie się powolny z jakiegoś powodu, powrót po stronie klienta znacznie zwiększy ładowanie strony, ponieważ najpierw spróbuje uzyskać zasób, który jest niedostępny. Lepszym rozwiązaniem jest zaprojektowanie strony serwera, która zastąpi podstawowy adres URL w linkach takich jak „{CDN} /js/jquery-version-min.js”. Umożliwi to przekierowanie ruchu do serwera aplikacji zamiast CDN, jeśli sprawdzenie poprawności CDN nie powiedzie się - klienci nie będą wykonywać niepotrzebnych żądań i przejdą bezpośrednio do serwera aplikacji, co byłoby rezerwą po stronie klienta. To rozwiąże również problem wdrożeń lokalnych i etapowych,