关于前端自动刷新cdn相关想法

背景

当前我司的前端构建+部署架构是：jenkins或者gitlabci—容器平台。

正常我们刷新cdn的流程是jenkins构建完代码后，在容器平台进行新版本发布，新版本发布成功后，手动刷新cdn。这样的操作会比较繁琐。

想法

针对上述背景，我们期望达到的目的就是版本发布完成后，自动刷新cdn，不需要手动介入。

当前现状有两个方面：

• jenkins构建完成之后，容器平台会自动发布该版本
• jenkins构建完成之后，需要手动到容器平台发布该版本

所以针对上述所有的情况，我的想法就是：
1.jenkins构建完成之后，创建一个刷新任务，这个任务包含哪个服务，要刷新什么，刷新状态等
2.写一个定时任务，去实时监听是否有未刷新的任务
3.如果获取到未刷新的任务，去监听这个任务对应服务的发布状态
4.如果服务发布状态为已经发布，那么就可以触发刷新cdn动作了

开始

1.创建一个任务平台

这个平台需要实现如下接口：
1.新增任务
2.修改任务状态
3.根据id查询任务详情
4.获取所有任务列表

具体的就差不多这些吧：

[GIN-debug] POST   /api/v1/cdnr/task         --> whyme-api/controller/cdn.AddRefreshTask (4 handlers)
[GIN-debug] GET    /api/v1/cdnr/alltask      --> whyme-api/controller/cdn.GetTaskList (4 handlers)
[GIN-debug] GET    /api/v1/cdnr/tasks        --> whyme-api/controller/cdn.GetUnCompletedTask (4 handlers)
[GIN-debug] GET    /api/v1/cdnr/task/:taskid --> whyme-api/controller/cdn.GetRefreshTaskStatus (4 handlers)
[GIN-debug] PUT    /api/v1/cdnr/task/:taskid/:status --> whyme-api/controller/cdn.UpdateRefreshTaskStatus (4 handlers)

关于任务字段的设计：

taskid 任务id
namespace 项目名称
service 服务名称
version 本次发布的服务版本
url 要刷新的地址
createtime 创建时间
updatetime 更新时间
status 0代表未刷新，1代表刷新了

如果你的刷新量级比较大或者有更高的要求，你可以上kafka，像我们就很简单，直接接mysql。

2.写一个定时任务

这个定时的复杂度取决于你上述任务字段设计的逻辑，像我上述涉及的，那这个定时任务会比较复杂点：
1.实现未刷新任务查询
2.实现服务发布状态获取
3.实现修改刷新任务
4.实现刷新cdn

如果你把这些状态status细分一下，就可以用多个定时任务分别去修改和获取，所以还是看你复杂度，如果复杂就分开，简单写在一起也没关系。

最终定时任务执行后差不多就是这个流程吧：

3.加一个友好的前端界面

写一个页面去展示你的刷新任务状态

4.加一个友好的通知机制

目前当有刷新任务完成刷新，会通知出来，不论你是用钉钉，企业微信还是邮件，自己写就完事了

开源想法

代码都很简单，开源不开源没啥必要。。真的！

想法和逻辑有了，那还不是很快就写完了