ServiceWorker架构：高效令牌与网络同步解析

学习文章要努力，但是不要急！今天的这篇文章《Service Worker架构：高效令牌与网络同步实现》将会介绍到等等知识点，如果你想深入学习文章，可以关注我！我会持续更新相关文章的，希望对大家都能有所帮助！

在现代Web应用中，尤其是在渐进式Web应用（PWA）或使用Trusted Web Activity (TWA) 的原生应用场景下，Service Worker扮演着关键角色。它不仅能提供离线能力，还能拦截和处理网络请求，从而成为集中管理认证令牌的理想场所。然而，当认证令牌需要周期性更新时，如何确保所有并发的网络请求都能获取到最新的令牌，并且在令牌更新过程中能够优雅地等待，是一个需要精心设计的挑战。

挑战：Service Worker中的令牌管理与请求同步

设想一个场景：你的Web应用依赖于一个具有生命周期的认证令牌，该令牌每隔一定时间（例如15分钟）需要刷新。Service Worker负责：

1. 首次启动时获取令牌并存储。
2. 拦截所有出站网络请求，并为它们附加此令牌。
3. 令牌过期前，周期性地刷新令牌。
4. 最重要的是，在令牌刷新期间，所有新的网络请求都必须等待新令牌的到来，然后才能继续执行，并使用这个新令牌。

最初，开发者可能会考虑使用某种“可变Promise”或Proxy对象来实现Promise的动态更新。然而，Promise一旦被resolve或reject，其状态就不可改变。试图直接修改一个已完成的Promise是徒劳的。解决方案的关键在于理解：我们不需要修改Promise本身，而是需要替换存储Promise的变量。

解决方案：基于Promise的令牌刷新与请求同步

核心思路是维护一个指向当前有效令牌Promise的变量。当需要刷新令牌时，我们创建一个新的Promise来代表令牌获取过程，并用这个新Promise替换掉旧的变量。所有依赖令牌的网络请求都将await这个变量所指向的Promise。

1. 令牌获取函数

首先，定义一个异步函数来负责实际的令牌获取逻辑。这个函数应该返回一个Promise，该Promise在令牌成功获取后解析为令牌字符串。

/**
 * 模拟异步获取认证令牌的函数。
 * 实际应用中会包含API调用、错误处理等逻辑。
 * @returns {Promise<string>} 解析为认证令牌字符串的Promise。
 */
async function fetchAuthToken() {
  console.log("正在获取新的认证令牌...");
  // 模拟网络请求延迟
  await new Promise(resolve => setTimeout(resolve, 1000));
  const newToken = "Bearer_New_Auth_Token_" + Date.now();
  console.log("令牌获取成功:", newToken);
  return newToken;
}

2. 令牌 Promise 管理

我们需要一个变量来存储当前的令牌Promise。在Service Worker启动时初始化它，并在令牌需要刷新时更新它。

let currentTokenPromise = null; // 用于存储当前认证令牌的Promise

/**
 * 初始化或刷新认证令牌。
 * 该函数会更新 currentTokenPromise 变量。
 */
async function initializeOrRefreshToken() {
  console.log("开始初始化/刷新令牌...");
  currentTokenPromise = fetchAuthToken(); // 创建一个新的Promise并赋值
  try {
    await currentTokenPromise; // 等待令牌获取完成
    console.log("令牌已准备就绪或已刷新。");
  } catch (error) {
    console.error("令牌获取失败:", error);
    // 错误处理：将 currentTokenPromise 设置为 null，以便后续请求可以触发重试
    currentTokenPromise = null;
    // 可以在这里实现更复杂的错误重试逻辑
  }
}

// Service Worker启动时立即获取令牌
initializeOrRefreshToken();

// 设置定时器，每15分钟刷新一次令牌
const TOKEN_REFRESH_INTERVAL = 15 * 60 * 1000; // 15分钟
setInterval(() => {
  console.log("定时刷新令牌触发...");
  initializeOrRefreshToken();
}, TOKEN_REFRESH_INTERVAL);

3. 网络请求集成

现在，任何需要认证令牌的网络请求都可以简单地await currentTokenPromise。如果currentTokenPromise已经解决，请求将立即获取令牌；如果它仍在等待令牌获取或刷新，请求将自动暂停，直到Promise解决。

/**
 * 发送一个需要认证令牌的网络请求。
 * @param {RequestInfo} input - 请求的URL或Request对象。
 * @param {RequestInit} [init] - 请求的选项。
 * @returns {Promise<Response>} 响应Promise。
 */
async function sendAuthenticatedRequest(input, init = {}) {
  // 如果 currentTokenPromise 为 null，说明令牌尚未初始化或上次获取失败，
  // 此时应尝试重新初始化令牌。这提供了首次失败后的重试机制。
  if (!currentTokenPromise) {
    console.warn("currentTokenPromise 为空，尝试重新初始化令牌...");
    await initializeOrRefreshToken(); // 尝试重新获取令牌
    // 如果 initializeOrRefreshToken 再次失败，currentTokenPromise 仍为 null，
    // 此时 await currentTokenPromise 将不会阻塞，而是直接执行下一步，
    // 导致请求在没有令牌的情况下发送或抛出错误。
    // 更好的做法是让 initializeOrRefreshToken 抛出错误，或返回一个拒绝的Promise。
    if (!currentTokenPromise) {
      throw new Error("无法获取认证令牌，请求无法发送。");
    }
  }

  const token = await currentTokenPromise; // 等待令牌可用
  console.log("使用令牌发送请求:", token);

  // 克隆请求头并添加认证信息
  const headers = new Headers(init.headers);
  headers.set('Authorization', token);

  return fetch(input, { ...init, headers });
}

// 示例：在Service Worker中拦截fetch事件并使用上述函数
self.addEventListener('fetch', event => {
  // 假设只有特定的API请求需要认证
  if (event.request.url.startsWith('/api/')) {
    event.respondWith(sendAuthenticatedRequest(event.request));
  } else {
    event.respondWith(fetch(event.request));
  }
});

// 模拟客户端发起请求
async function clientSideRequestExample() {
  try {
    console.log("客户端发起请求...");
    const response = await fetch('/api/data'); // 客户端通过Service Worker发送请求
    const data = await response.json();
    console.log("请求成功，数据:", data);
  } catch (error) {
    console.error("请求失败:", error);
  }
}

// 可以在 Service Worker 内部模拟调用，或者通过 postMessage 从主线程触发
// clientSideRequestExample();

错误处理与健壮性考虑

上述方案已经包含了基本的错误处理，即在fetchAuthToken失败时将currentTokenPromise重置为null，并在下次sendAuthenticatedRequest调用时触发initializeOrRefreshToken进行重试。然而，这仍有改进空间：

1. 拒绝的Promise： 如果fetchAuthToken失败，它会返回一个拒绝的Promise。currentTokenPromise将存储这个拒绝的Promise。这意味着后续所有await currentTokenPromise的请求都会立即抛出错误，直到下一次定时刷新或手动重试成功。这在某些情况下可能是期望的行为，但在其他情况下可能需要更精细的控制。
2. 重试策略： 当initializeOrRefreshToken失败时，简单地将currentTokenPromise设置为null并等待下一次请求触发重试，可能会导致短时间内大量请求失败。可以考虑实现指数退避（exponential backoff）等更复杂的重试机制，或者在initializeOrRefreshToken内部进行多次重试。
3. 避免死锁： 确保fetchAuthToken本身不会依赖于sendAuthenticatedRequest，以避免循环依赖和潜在的死锁。令牌获取通常是一个独立的网络请求，不应被Service Worker的拦截逻辑所影响。
4. Service Worker生命周期： Service Worker可能会在不活动一段时间后被浏览器终止。当它重新启动时，currentTokenPromise会重置，initializeOrRefreshToken将再次被调用。这与我们的设计是兼容的。

总结

通过简单地替换存储Promise的变量，而不是试图修改Promise本身，我们可以优雅地解决Service Worker中认证令牌的动态更新和网络请求同步问题。这种方法利用了JavaScript Promise的内置特性，使得代码简洁、逻辑清晰。结合健壮的错误处理和重试机制，可以构建一个高效且可靠的Service Worker令牌管理系统，从而提升Web应用的性能和用户体验。

今天关于《ServiceWorker架构：高效令牌与网络同步解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！