Сервисный работник на производстве

Это руководство является справочным материалом для развертывания и поддержки производственных приложений, в которых используется работник службы Angular. В нем объясняется, как работник службы Angular вписывается в большую производственную среду, поведение работника службы в различных условиях, а также доступные ресурсы и отказоустойчивость.

Сервисный работник и кеширование ресурсов приложения

Концептуально вы можете представить работника службы Angular в качестве прямого кэша или ребра CDN, установленного в веб-браузере конечного пользователя. Работа сервисного работника состоит в том, чтобы удовлетворять запросы, сделанные приложением Angular на ресурсы или данные из локального кэша, без необходимости ожидания сети. Как и в любом кеше, в нем есть правила того, как содержимое просрочено и обновлено

Версии приложения

В контексте работника службы Angular «версия» - это набор ресурсов, представляющих конкретную сборку приложения Angular. Каждый раз, когда развертывается новая сборка приложения, работник службы рассматривает эту сборку как новую версию приложения. Это верно, даже если обновляется только один файл. В любой момент времени работник сервиса может иметь несколько версий приложения в своем кэше, и он может обслуживать их одновременно.

Чтобы сохранить целостность приложения, работник службы Angular группирует все файлы в одну версию. Файлы, сгруппированные в версию, обычно включают файлы HTML, JS и CSS. Группирование этих файлов имеет важное значение для целостности, поскольку файлы HTML, JS и CSS часто ссылаются друг на друга и зависят от конкретного содержимого. Например, файл index.html может иметь тег <script>, который ссылается на bundle.js, и он может пытаться вызвать функцию startApp () из этого скрипта. Каждый раз, когда обслуживается эта версия index.html, соответствующая bundle.js должна обслуживаться вместе с ней. Например, предположим, что функция startApp () переименована в runApp () в обоих файлах. В этом случае недопустимо использовать старый файл index.html, который вызывает startApp (), вместе с новым пакетом, который определяет runApp ().

Эта целостность файла особенно важна при ленивой загрузке модулей. Пакет JS может ссылаться на многие ленивые чанки, а имена ленивых чанков уникальны для конкретной сборки приложения. Если запущенное приложение в версии Xattempts загружает ленивый фрагмент, но сервер уже обновился до версии X + 1, операция отложенной загрузки завершится неудачно.

Идентификатор версии приложения определяется содержимым всех ресурсов и изменяется при изменении любого из них. На практике версия определяется содержимым файла ngsw.json, который содержит хеши для всего известного содержимого. Если какой-либо из кэшированных файлов изменится, хеш файла изменится в ngsw.json, в результате чего работник службы Angular будет рассматривать активный набор файлов как новую версию.

С помощью управления версиями работника службы Angular сервер приложений может гарантировать, что приложение Angular всегда имеет согласованный набор файлов.

Обновить проверки

Каждый раз, когда пользователь открывает или обновляет приложение, работник службы Angular проверяет наличие обновлений приложения путем поиска обновлений в манифесте ngsw.json. Если обновление найдено, оно загружается и кэшируется автоматически и будет обслуживаться при следующей загрузке приложения.

Целостность ресурса

Одним из потенциальных побочных эффектов длительного кэширования является непреднамеренное кэширование недопустимого ресурса. В обычном HTTP-кэше жесткое обновление или истечение срока действия кэша ограничивают негативные последствия кэширования неверного файла. Работник службы игнорирует такие ограничения и эффективно долго кэширует все приложение. Следовательно, важно, чтобы работник службы получил правильное содержание.

Для обеспечения целостности ресурса работник службы Angular проверяет хэши всех ресурсов, для которых у него есть хэш. Обычно для приложения, созданного с помощью Angular CLI, это все в каталоге dist, охватываемом конфигурацией src / ngsw-config.json пользователя.

Если конкретный файл не проходит проверку, работник службы Angular пытается повторно извлечь содержимое, используя параметр URL «разорения кеша», чтобы исключить влияние браузера или промежуточного кеширования. Если этот контент также не проходит проверку, работник службы считает всю версию приложения недействительной и перестает обслуживать приложение. При необходимости работник сервиса переходит в безопасный режим, когда запросы возвращаются в сеть, решая не использовать свой кэш, если велика вероятность обслуживания недопустимого, поврежденного или устаревшего контента.

Несовпадения хэшей могут возникать по разным причинам:

Кэширующие слои между исходным сервером и конечным пользователем могут обслуживать устаревший контент.

Неатомарное развертывание может привести к тому, что у работника службы Angular будет виден частично обновленный контент.

Ошибки в процессе сборки могут привести к обновлению ресурсов без обновления ngsw.json. Также может произойти обратное, что приведет к обновлению ngsw.json без обновленных ресурсов.

Неразделенный контент

Единственные ресурсы, которые имеют хэши в манифесте ngsw.json, - это ресурсы, которые присутствовали в каталоге dist на момент создания манифеста. Другие ресурсы, особенно загруженные из CDN, имеют контент, который неизвестен во время сборки или обновляется чаще, чем развертывание приложения.

Если у работника службы Angular нет хэша для проверки заданного ресурса, он все равно кэширует его содержимое, но учитывает заголовки кэширования HTTP, используя политику «устаревшего при переаттестации». То есть, когда заголовки кэширования HTTP для кэшированного ресурса указывают, что ресурс истек, работник службы Angular продолжает обслуживать контент и пытается обновить ресурс в фоновом режиме. Таким образом, поврежденные нехэшированные ресурсы не остаются в кэше после их настроенного времени жизни.

Вкладки приложений

Для приложения может возникнуть проблема, если версия ресурсов, которые оно получает, изменяется внезапно или без предупреждения.

Работник службы Angular предоставляет гарантию: работающее приложение будет продолжать работать с той же версией приложения. Если другой экземпляр приложения открывается на новой вкладке веб-браузера, то обслуживается самая последняя версия приложения. В результате на этой новой вкладке может быть запущена версия приложения, отличная от исходной вкладки.

Важно отметить, что эта гарантия сильнее той, которая обеспечивается обычной моделью веб-развертывания. Без работника службы нет никакой гарантии, что код, загруженный позже в запущенном приложении, имеет ту же версию, что и исходный код приложения.

Существует несколько ограниченных причин, по которым работник службы Angular может изменить версию работающего приложения. Некоторые из них являются ошибочными условиями:

Текущая версия становится недействительной из-за сбоя хэша.

Несвязанная ошибка приводит к тому, что работник сервиса переходит в безопасный режим; то есть временная деактивация.

Работник службы Angular знает, какие версии используются в данный момент, и очищает версии, когда их не использует ни одна вкладка.

Другие причины, по которым работник службы Angular может изменить версию работающего приложения, - это обычные события:

Страница перезагружается / обновляется. Страница запрашивает, чтобы обновление было немедленно активировано через сервис SwUpdate.

Сервисный работник обновлений

Сервисный работник Angular - это небольшой скрипт, который запускается в веб-браузерах. Время от времени сервисный работник будет обновляться с исправлениями ошибок и улучшениями функций.

Сервисный работник Angular загружается при первом открытии приложения и при обращении к нему после периода бездействия. Если работник службы изменился, он будет обновлен в фоновом режиме.

Большинство обновлений работника службы Angular прозрачны для приложения - старые кэши все еще действительны, а контент по-прежнему обслуживается в обычном режиме. Однако иногда исправление или функция в сервисе Angular требует отмены старых кэшей. В этом случае приложение будет прозрачно обновляться из сети.

Отладка сервисного работника Angular

Иногда может потребоваться проверить работника службы Angular в работающем состоянии, чтобы исследовать проблемы или убедиться, что он работает в соответствии с планом. Браузеры предоставляют встроенные инструменты для отладки сервисных работников, а сам сервисный работник Angular включает полезные функции отладки.

Нахождение и анализ отладочной информации

Работник службы Angular предоставляет информацию об отладке в каталоге ngsw / virtual. В настоящее время единственным открытым URL является ngsw / state. Вот пример содержимого этой страницы отладки:

NGSW Debug Info:
Driver state: NORMAL ((nominal))
Latest manifest hash: eea7f5f464f90789b621170af5a569d6be077e5c
Last update check: never
=== Version eea7f5f464f90789b621170af5a569d6be077e5c ===
Clients: 7b79a015-69af-4d3d-9ae6-95ba90c79486, 5bc08295-aaf2-42f3-a4cc-9e4ef9100f65
=== Idle Task Queue ===
Last update tick: 1s496u
Last update run: never
Task queue:
 * init post-load (update, cleanup)
Debug log:

Демонстрация в реальном времени:

См. Содержимое страницы отладки пера w3resource ( @ w3resource ) на CodePen .

Состояние водителя

Первая строка указывает состояние драйвера:

Состояние водителя: НОРМАЛЬНОЕ ((номинальное))

NORMAL указывает, что работник службы работает нормально и не находится в ухудшенном состоянии.

Есть два возможных ухудшенных состояния:

EXISTING_CLIENTS_ONLY: у работника службы нет чистой копии последней известной версии приложения. Старые кэшированные версии безопасны в использовании, поэтому существующие вкладки продолжают работать из кэша, но новые загрузки приложения будут обслуживаться из сети.

SAFE_MODE: работник сервиса не может гарантировать безопасность использования кэшированных данных. Либо произошла непредвиденная ошибка, либо все кэшированные версии являются недействительными. Весь трафик будет обслуживаться из сети с минимальным количеством кода работника сервиса.

В обоих случаях аннотация в скобках содержит ошибку, из-за которой работнику сервиса пришлось перейти в ухудшенное состояние.

Последний манифест

Это хэш SHA1 самой последней версии приложения, о которой знает служащий.

Проверка последнего обновления

Проверка последнего обновления: никогда

Это указывает, когда в последний раз работник службы проверял наличие новой версии или обновления приложения. никогда не указывает на то, что работник сервиса никогда не проверял наличие обновлений.

В этом примере файла отладки проверка обновления в настоящее время запланирована, как объяснено в следующем разделе.

Версия

=== Версия eea7f5f464f90789b621170af5a569d6be077e5c === Клиенты: 7b79a015-69af-4d3d-9ae6-95ba90c79486, 5bc08295-aaf2-42f3-aaf2-42f3-a4cc-9e4ef9100f65

В этом примере у работника сервиса есть одна версия приложения, которая кэшируется и используется для обслуживания двух разных вкладок. Обратите внимание, что эта версия хэша является "последним хешем манифеста", перечисленным выше. Оба клиента находятся на последней версии. Каждый клиент указан по его идентификатору из API клиентов в браузере.

Очередь задач

=== Очередь незанятых задач === Последняя отметка обновления: 1s496u Последнее выполнение обновления: никогда Очередь задач: * init post-load (обновление, очистка)

Idle Task Queue - это очередь всех незавершенных задач, которые происходят в фоновом режиме в сервисном работнике. Если в очереди есть какие-либо задачи, они перечислены с описанием. В этом примере у работника службы запланирована одна такая задача - операция после инициализации, включающая проверку обновлений и очистку устаревших кэшей.

Счетчики последнего обновления / запуска показывают время, когда произошли определенные события, связанные с незанятой очередью. Счетчик «Последний запуск обновления» показывает, когда задачи в последний раз фактически выполнялись. «Тик последнего обновления» показывает время с момента последнего события, после которого очередь может быть обработана.

Журнал отладки

Журнал отладки:

Ошибки, которые происходят внутри сервисного работника, будут регистрироваться здесь.

Инструменты разработчика

Браузеры, такие как Chrome, предоставляют инструменты для взаимодействия с работниками сферы обслуживания. Такие инструменты могут быть мощными при правильном использовании, но есть несколько вещей, которые следует иметь в виду.

При использовании инструментов разработчика работник службы работает в фоновом режиме и никогда не перезапускается. Это может привести к тому, что поведение при открытых инструментах разработки будет отличаться от поведения пользователя.

Если вы посмотрите в средстве просмотра Cache Storage, кэш часто устарел. Щелкните правой кнопкой мыши заголовок Cache Storage и обновите кэши.

Остановка и запуск работника службы на панели «Работник службы» запускает проверку обновлений.

Сервисный работник безопасности

Как и в любой сложной системе, ошибки или неправильные конфигурации могут привести к непредвиденным действиям работника службы Angular. В то время как его дизайн пытается свести к минимуму влияние таких проблем, сервисный работник Angular содержит несколько отказоустойчивых механизмов на случай, если администратору когда-либо понадобится быстро деактивировать сервисного работника.

Безотказный

Чтобы деактивировать работника службы, удалите или переименуйте файл ngsw.json. Когда запрос работника сервиса для ngsw.json возвращает 404, тогда работник сервиса удаляет все свои кеши и отменяет регистрацию, по сути, самоуничтожаясь.

Работник безопасности

В пакет NPM @ angular / service-worker также включен небольшой сценарий safety-worker.js, который при загрузке отменяет регистрацию в браузере. Этот сценарий можно использовать в качестве крайней меры, чтобы избавиться от нежелательных сервисных работников, уже установленных на клиентских страницах.

Важно отметить, что вы не можете зарегистрировать этого работника напрямую, так как старые клиенты с кэшированным состоянием могут не увидеть новый index.html, который устанавливает другой рабочий скрипт. Вместо этого вы должны предоставить содержимое файла safety-worker.js по URL-адресу сценария Service Worker, который вы пытаетесь отменить, и должны продолжать это делать до тех пор, пока не убедитесь, что все пользователи успешно отменили регистрацию старого работника. Для большинства сайтов это означает, что вы должны обслуживать работника службы безопасности по старому URL Service Worker навсегда.

Этот сценарий можно использовать как для деактивации @ angular / service-worker, так и для любых других сервисных работников, которые могли ранее обслуживаться на вашем сайте.

Предыдущая: Конфигурация сервисного работника
Далее: Авторские схемы