sitemap 是一种 xml 格式的文本文件，是提供给搜索引擎使用的。搜索引擎可以通过定期读取 sitemap 文件来更新相关网站的索引。因此，sitemap 文件实际上以 xml 格式包含了网站的页面信息。本站的 sitemap 文件是这个样子的，片段如下：

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xhtml="http://www.w3.org/1999/xhtml">
    <url>
        <loc>https://www.gryen.com</loc>
        <lastmod>2020-03-31T00:00:00+08:00</lastmod>
        <changefreq>daily</changefreq>
        <priority>0.1</priority>
    </url>
    <url>
        <loc>https://www.gryen.com/articles</loc>
        <lastmod>2020-03-31T00:00:00+08:00</lastmod>
        <changefreq>monthly</changefreq>
        <priority>0.1</priority>
    </url>
    <url>
        <loc>https://www.gryen.com/articles/show/10.html</loc>
        <lastmod>2017-05-23T10:47:31+08:00</lastmod>
        <changefreq>monthly</changefreq>
        <priority>0.2</priority>
    </url>
    ...
</urlset>

sitemap 应该是搜索引擎抓取时当下网站的状态的，反映整个网站当时的全貌，是整个网站的一个概览。

一种做法是在搜索引擎读取 sitemap 时动态生成内容，与动态网站用户访问时从数据库抓取内容填充到页面一样。

但是这样做有两个问题：一是网站内容比较多的时候，遍历所有数据生成 sitemap 比较慢，可能会影响收录；二是 sitemap 既然是提供当前网站网页概览的，那么只需要在网站发生变更，比如增加或者删除网页时更新就可以了，网站更新频率不高（低于搜索引擎读取 sitemap 的频率）的情况下，每次搜索引擎读取时都动态生成同样的 sitemap 文件，太浪费资源了。

比较好的做法是生成一份静态的 sitemap.xml 文件，在网站发生变更时，更新这个 sitemap.xml 文件就可以了。

利用 Laravel 事件和队列，实现在创建、删除文章等情况下更新 sitemap.xml

事件的使用

事件机制提供了不影响正常业务流程，做一些额外处理的能力。像是更新 sitemap.xml 文件，它不属于我正常发表一篇文章的流程，它的成功与失败，并不影响到我将一篇文章发表到网站上。所以，只需要在特定的条件下，触发这个事件就可以了，至于它什么时间执行完成，甚至成功与否，都不在发表文章的过程中关心。Laravel 也提供给了这样的一种事件处理机制。

Laravel 项目里面有两个文件夹看起来和事件有关系：Events 和 Listeners，一个负责事件定义，一个提供事件监听器。此外，EventServiceProvider 中还定义了事件和监听器之间的映射。具体实施起来比想象中更容易：

1. 在 EventServiceProvider 中定义事件和监听器的映射EventServiceProvider.php

/**
  * The event listener mappings for the application.
  *
  * @var array
  */
 protected $listen = [
     Registered::class => [
         SendEmailVerificationNotification::class,
     ],
     'App\Events\PublishArticle' => [
         'App\Listeners\GenSiteMapListener',
     ],
 ];

1. 执行 php artisan event:generate 事件和监听器就都生成好了。PublishArticle.php

<?php

namespace App\Events;

use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;

class PublishArticle { 
    use Dispatchable, InteractsWithSockets, SerializesModels;

    /**
    *   Create a new event instance.*
    *   @return void
    */
    public function __construct()
    { 
        //
    }

    /**
    *   Get the channels the event should broadcast on.
    *   @return \Illuminate\Broadcasting\Channel|array
    */
    public function broadcastOn()
    { 
        return [];
    }
}

GenSiteMapListener.php

<?php

namespace App\Listeners;

use App\Article;
use App\Events\PublishArticle;
use Carbon\Carbon;
use Illuminate\Contracts\Queue\ShouldQueue;
use Spatie\Sitemap\Sitemap;
use Spatie\Sitemap\Tags\Url;

class GenSiteMapListener implements ShouldQueue {

    /**
    *   Create the event listener.*
    *   @return void
    */
    public function __construct()
    { 
        //
    }

    /**
    *   Handle the event.
    *   @param PublishArticle $event
    *   @return void
    */
    public function handle(PublishArticle $event)
    { 
        $publicPath = public_path('sitemap.xml');
        $siteMap = Sitemap::create();

        $siteMap
             ->add(Url::create(action('HomeController@index'))
             ->setLastModificationDate(Carbon::yesterday())
             ->setChangeFrequency(\Spatie\Sitemap\Tags\Url::CHANGE_FREQUENCY_DAILY)
             ->setPriority(0.1))
             ->add(Url::create(action('ArticlesController@index'))
             ->setLastModificationDate(Carbon::yesterday())
             ->setChangeFrequency(\Spatie\Sitemap\Tags\Url::CHANGE_FREQUENCY_MONTHLY)
             ->setPriority(0.1));

        Article::all()->each(function ($article) use ($siteMap) {
            if ($article->status === 1) {
                $siteMap->add(Url::create(action('ArticlesController@show', [$article->id]))
                    ->setLastModificationDate($article->updated_at)
                    ->setChangeFrequency(\Spatie\Sitemap\Tags\Url::CHANGE_FREQUENCY_MONTHLY)
                    ->setPriority(0.2));
            }
        });

        $siteMap->writeToFile($publicPath);
        $siteMap = null;
    }
}

上面代码中包含了生成 sitemap.xml 具体逻辑的实现，用到了 spatie/laravel-sitemap 这个库。

触发事件只一行代码：

event(new PublishArticle());

把它放到创建文章或者删除文章等需要更新 sitemap.xml 的操作里面，保证能触发就可以了，参考：ArticlesController.php#L103

队列的使用

实现了事件之后，实际上只是将代码从正常发表文章的逻辑中抽离了，实际执行起来，它还是同步的。也就是说，如果生成 sitemap.xml 的过程需要 1 分钟，那么，在发表文章的时候，就需要多等上 1 分钟，这显然还是对我们发表文章的过程产生了影响。我们想要的是让生成 sitemap.xml 的过程异步去执行，我们只是在发表文章时触发它，它自己选择合适的时机去执行，我们不用多等 1 分钟就能将文章发表了。

这就用到了队列，我们将这个任务放入队列中，队列来决定什么时候执行这个任务。

Laravel 中使用队列只需要在事件监听器中实现 ShouldQueue 接口就可以了，代码见上面 GenSiteMapListener.php，然后我们还要对队列做一些配置工作，配置 Laravel 采用哪种方式实现队列和采取什么样的策略。

队列的配置

除了同步执行的队列 sync 以外，Laravel 支持 database、beanstalkd、sqs 以及 redis 多种队列实现策略，这里只介绍 redis 策略的配置，其他配置方式可参考 Laravel 的队列配置文件 config/queue.php 和官方相关说明文档。使用 redis 方式的队列，需要在 .env 文件中配置：

QUEUE_CONNECTION=redis

config/queue.php 中 redis 的配置节点保持默认就可以了，需要注意的是失败队列的配置，也就是以下部分;

'failed' => [
        'driver' => env('QUEUE_FAILED_DRIVER', 'database'),
        'database' => env('DB_CONNECTION', 'mysql'),
        'table' => 'failed_jobs',
    ],

这里面的配置也不需要更改，需要留意的是 table 中的 failed_jobs 这个表，laravel 默认是不会生成的，需要我们执行 php artisan queue:failed-table 生成 migration，然后执行 php artisan migrate 来生成 failed_jobs 表。

以上，采用 redis 的 laravel 队列配置完成。要让它开始工作，还得执行：

php artisan queue:work --tries=3

其中，--tries=3 参数给出了默认尝试的次数，失败后会记录到上一步生成的 failed-table 表中，否则队列将不停尝试。

另外，这是个需要在后台一直执行的任务，需要我们给它配置守护进程。laravel 提供了使用 Supervisor 实现守护进程的方法，当然也可以使用其他方式实现，比如 ubuntu 系统的 service。

定时任务

NestJS 定时任务可通过miaowing/nest-schedule实现。

定时任务的实现

1. 按照 miaowing/nest-schedule 的说明文档，将 nest-schedule 模块导入到项目中：

 import { Module } from '@nestjs/common';
 import { ScheduleModule } from 'nest-schedule';

 @Module({
   imports: [
     ScheduleModule.register(),
   ]
 })
 export class AppModule {
 }

2. 需要支持定时任务的服务继承 NestSchedule 类：

import { Injectable } from '@nestjs/common';
 import { Cron, Interval, Timeout, NestSchedule } from 'nest-schedule';

 @Injectable() // Only support SINGLETON scope
 export class ScheduleService extends NestSchedule {    
   @Cron('15 16 * * *')
   async cronJob() {
     console.log('executing cron job');
   }

3. 执行定时任务的方法添加@Cron('15 16 * * *')注解。这条注解的意思是“每天16:15” 执行一次定时任务。这里似乎与常见的 Cron 表达式不一样：第一个数据段代表的不是秒而是分，由此可见，miaowing/nest-schedule 不支持秒级的定时任务。

以上三步就能实现定时任务的功能了。

需要留意的问题

• 不知何故，开启服务后，定时任务并没有执行，必须手动访问过任意一个 controller 之后，定时任务才会开启。开始猜测是在子模块导入的原因，尝试在根模块注入之后，问题依旧，难道与Only support SINGLETON scope有关系？
• @Cron('15 16 * * *')中的表达式并非常见的 Cron 表达式，第一个数据段代表的是分而不是秒，且不支持如：“0/15 * * * *每15分钟执行一次”这样的配置，逗号分隔符是支持的，因此每15分钟执行一次可以配置成“0,15,30,45”。

发送 Exchange 邮件

Exchange 邮件的支持借助gautamsi/ews-javascript-api来实现。

Exchange 邮件发送实现

1. 导入相关方法

import {
   ExchangeService, ExchangeVersion,
   Uri as ExchangeUri,
   WebCredentials, EmailMessage, MessageBody, ConfigurationApi
 } from 'ews-javascript-api';

2. 新建ExchangeService 服务

const exch = new ExchangeService(ExchangeVersion.Exchange2007_SP1);

3. 配置登录凭据以及服务地址

exch.Credentials = new WebCredentials(ewsConfig.username, ewsConfig.password);
 exch.Url = new ExchangeUri(ewsConfig.host);

4. 构建要发送的邮件实体，Subject 为邮件的标题，Body 为邮件的内容，收件人地址可以通过msgattach.ToRecipients.Add(address)方法实现：

const msgattach = new EmailMessage(exch);

 msgattach.Subject = mailContent.Subject;
 msgattach.Body = new MessageBody(mailContent.Body);
 msgattach.ToRecipients.Add(address);

5. 发送邮件

 msgattach.SendAndSaveCopy() // 此方法返回 Promise

按照上述步骤实现，可能会出现鉴权不通过的问题，可能是 NTLM 认证的问题，NTLM 是 telnet 的一种验证身份的方式，是 Windows NT 早期版本的标准安全协议。可以安装另外一个库@ewsjs/xhr， 尝试以下配置：

...
import { XhrApi } from '@ewsjs/xhr';
...
const exch = new ExchangeService(ExchangeVersion.Exchange2007_SP1);
const xhr = new XhrApi({ rejectUnauthorized: false }).useNtlmAuthentication(username, password);

ConfigurationApi.ConfigureXHR(xhr);

完整代码如下：

import {
  ExchangeService, ExchangeVersion,
  Uri as ExchangeUri,
  WebCredentials, EmailMessage, MessageBody, ConfigurationApi
} from 'ews-javascript-api';

/**
* 发邮件
*/
mailToSomeOne(address: string, mailContent: {
    Subject: string,
    Body: string
}): void {
    const exch = new ExchangeService(ExchangeVersion.Exchange2007_SP1);
    const xhr = new XhrApi({ rejectUnauthorized: false }).useNtlmAuthentication(ewsConfig.username, ewsConfig.password);

    ConfigurationApi.ConfigureXHR(xhr);

    exch.Credentials = new WebCredentials(ewsConfig.username, ewsConfig.password);
    exch.Url = new ExchangeUri(ewsConfig.host);

    const msgattach = new EmailMessage(exch);

    msgattach.Subject = mailContent.Subject;
    msgattach.Body = new MessageBody(mailContent.Body);
    msgattach.ToRecipients.Add(address);

    msgattach.SendAndSaveCopy().then(res => {
      console.log(res);
    }, (err) => {
      console.error(err);
    });
}

需要留意的问题

• 权限部分可能并非使用 NTLM 方式，@ewsjs/xhr还支持 Cookies Auth，可查阅文档。

刷新重试策略

如果 API 返回 access_token 失效，那么从 API 获取新的 access_token，并重试失败的请求。
如果 refresh_token 也失效，让用户去登录。

实现过程

使用 Angular 的拦截器可以拦截 API 请求，可以在请求前后做些处理。要使用拦截器，只需要实现 HttpInterceptor 接口的 intercept 方法。一个不做任何处理的拦截器是下面这个样子。

示例：

import { Injectable } from '@angular/core';
import {
  HttpEvent, HttpInterceptor, HttpHandler, HttpRequest
} from '@angular/common/http';

import { Observable } from 'rxjs';

@Injectable()
export class NoopInterceptor implements HttpInterceptor {

  intercept(req: HttpRequest<any>, next: HttpHandler):
    Observable<HttpEvent<any>> {
    return next.handle(req);
  }
}

token 刷新就是在 intercept 方法里面做的。

可以在请求发出前对 HttpRequest 进行处理，比如获取请求头中的数据或者更改请求等等。

示例：

intercept(req: HttpRequest<any>, next: HttpHandler):
    Observable<HttpEvent<any>> {
    const token = req.headers.get('Authorization');
    console.log(token);

    return next.handle(req);
}

intercept 方法返回的是一个 Observable。因此，对 response 做后置处理可以使用 rxjs6 的 pipe。

示例：

intercept(req: HttpRequest<any>, next: HttpHandler):
    Observable<HttpEvent<any>> {
    return next.handle(req).pipe(some code...);
}

我在项目中，对 Angular 的 HttpClient 做了一次封装，对外提供了一个 HttpService。 请求头的前置处理，比如设置 token 等的处理放在了 HttpService 中了：
示例：

...
let headers = new HttpHeaders();

headers.append('Authorization', ''[token]);
...

所以在处理 token 刷新的拦截器中，只需判断 API 请求是否设置了 token 信息就可以筛选出需要处理的请求了，需要处理的对 response Observable 使用 pipe，不需要的就直接返回 next.handle(req)。

处理过程用到了 rxjs 的几个操作符：map、tap、concatMap、retryWhen、delay，前期投入的时间也主要是花在了这些操作符上，rxjs 的数据流操作方式与以往开发经验还是有很大不同，需要思维的转换。

复习下这几个操作符。

• map：对源 Observable 发出的值应用处理，并将结果作为 Observable 发出，常用的操作符，相当于 promise 的 then；
• tap：没有副作用的进行一些透明地操作，比如打印日志、数据采集可以使用这个操作符；
• concatMap：这个与 map 的区别：map 订阅后输出 Observable，订阅 concatMap 输出值；
  示例：

  becomeHero() {
    return of('hero');
  }

  const source = of(1);

  source.pipe(
    map(() => this.becomeHero())
  ).subscribe(res => {
    console.log('map:', res); // 输出：map:Observable {_isScalar: true, _subscribe: ƒ, value: "hero"}
  });

  source.pipe(
    concatMap(() => this.becomeHero())
  ).subscribe(res => {
    console.log('concatMap:', res); // 输出：concatMap:
hero
  });

• retryWhen：出错后重试修改后的源；
• delay：延迟源 Observable 的发送。

按照刷新策略，Angular 中使用 rxjs 实现的重试逻辑如下所示。在 Angular 中间件拦截器中，先筛选出需要刷新控制的请求。这里使用 rxjs 的 map 操作符判断此请求是否需要刷新，需要刷新的抛出错误，以被 retryWhen 操作符接收做重试处理，否则，返回正确的结果。由于是 token 失效的请求重试，所以 retryWhen 里面需要获取新的 token 并重新设置到此请求当中，否则依然用旧的 token 尝试请求是一定会失败的。这里是放在了 tap 操作符当中处理的。然后在 map 操作符当中控制下刷新的次数。最后通过 delay 操作符设置下重试的时间间隔，整个逻辑就完成了。

示例：

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<any> {

// 判断是否是需要校验的请求，不是的直接放行
if (!req.headers.get('Authorization')) {
  return next.handle(req);
}

const response = next.handle(req)
  .pipe(
    map((res: HttpResponse<any>) => {
      // 判读是否需要重试，抛出错误的请求会进入 retryWhen 走重试逻辑，否则返回结果
      if (Lhas(res, 'body.status') && Lget(res, 'body.status') === 401) {
        throw res;
      }

      return res;
    }),
    retryWhen(error => {
      return error
        .pipe(
          concatMap(() => this.handleToken()), // handleToken 是获取 token 的逻辑，代码贴到下面
          tap(token => {
            // 重新设置 token
            const headersMap = new Map();

            headersMap.set('authorization', [`${token}`]);

            Lset(req, 'headers.headers', headersMap);

            return req;
          }),
          map((res, count) => {
            // 重试次数控制
            if (count > 0) {
              throw res;
            }

            return res;
          }),
          delay(1000), // 延迟重试
        );
    }
    )
  );

上面代码中获取 token 的处理逻辑贴在下面。这段代码逻辑处理了一个页面中多个请求都 token 失效的情况，这种情况下会造成发送多个 refreshToken 请求，这样不仅仅会造成资源的浪费，最重要的是可能会导致第一个获取到 token 的请求重试时，第二个 refreshToken 请求也成功了，然后第一个重试就因 token 被刷新调而失败了。这里是通过定义一个刷新时间间隔（timeDebounce）来控制的。将 token 放在本地存储中（cookie 或者 localStorage），如果是间隔时间内的请求就直接本地取 token 返回，超过间隔时间的请求才从网络获取 token。间隔时间需要根据页面接口调用数量及处理时间来确定，比如设置为10秒的意思是所有的请求都会在10秒内发出，这几个请求都设置了新的 token 并发出了请求。

示例：

/**
* 刷新 token
* @param req
*/
handleToken(): Observable<any> {
  const currentTime = new Date().getTime();
  const accessTokenFromLocal = getAccessTokenFromLocal();
  const reGetTokenFromNet = this.refreshToken() // 请求接口，刷新 token
    .pipe(
      map(this.saveToken.bind(this))
    );

  // 没有 refreshTokenTime， 或
  // 没有 accessTokenFromLocal，或
  // 重试间隔大于 timeDebounce 秒，从网络获取，并记录时间
  if (!this.refreshTokenTime ||
    !accessTokenFromLocal ||
    currentTime - this.refreshTokenTime > this.timeDebounce) {
    this.refreshTokenTime = currentTime;
    return reGetTokenFromNet;
  } else {
    return accessTokenFromLocal;
  }
}

到此为止，整个 token 的刷新重试流程就完成了。