新增syncMode为none时的缓存依赖功能

[hezhengxu2018]

基础的需求是对标Verdaccio的代理时缓存依赖或者Nexus的代理仓库缓存的功能。

即不会创建定时任务去同步依赖，在当前仓库依赖找不到，重定向到上游仓库时对包的信息做缓存，下次访问时不会再出现找不到依赖重定向的情况。由于没有创建同步任务，仓库的存储压力与网络带宽的压力也会大大减少。对于中小型公司来说不会用到整个npm仓库的依赖也不需要同步某个依赖的所有版本，相对于all和exist模式来说开启缓存的none会是更好的选择。相对于 #335 syncByInstall 功能来说是一种更懒的模式。

计划在config文件中新增cacheWhenInstall选项，仅在syncMode为none时生效。如果有更符合直觉理解的配置项或者可以合并的模式可以讨论。

[fengmk2]

@hezhengxu2018 来贡献一个？

[hezhengxu2018]

可以试一下。没有后端开发经验，可能会出现很多反模式。

[hezhengxu2018]

cnpmcore在设计之初就是一个主动同步的npm仓库，而verdaccio和nexus则只有代理仓库的功能，两者在实现上有所不同。在实际实现代理功能的过程中发现比预期的要复杂，同步是正向的添加依赖，缓存是逆向的添加依赖，代理缓存时不能直接复用之前同步的逻辑。计划修改内容如下：

1. 在nfs中新增与packages同级的目录proxy-mode-cached-manifests用于缓存代理模式下获取的manifest文件，减少向上游仓库的请求次数与响应速度。
2. 数据库中新增表proxy_cached_package_manifests用于记录在代理模式下已缓存的依赖及访问nfs中的manifests文件必要信息。
3. 代理模式仅在syncMode为none时生效，但是会定时更新已经缓存的依赖的manifests信息。同步的是依赖的索引而不是依赖本身，与syncMode的描述不相悖。nexus中有配置项Maximum metadata age可自定义manifests文件的同步周期，理应为此添加单独的配置项，默认值可设为30分钟去同步一次已缓存依赖的manifest信息。
4. 在代理仓库模式下访问以下接口时会获取上游仓库中已缓存的索引信息（而非cnpmcore的数据库中依赖信息），若404则访问上游仓库获取并缓存：

• GET /:fullname
• GET /:fullname/:versionOrTag
• GET /:fullname/-/:filenameWithVersion.tgz
• GET /-/package/:fullname/dist-tags
  其中：

• 只有访问GET /:fullname/-/:filenameWithVersion.tgz接口时会触发依赖的缓存（即依赖的publish流程）
• tag的add、remove逻辑不做修改，即若该用户是包的所有者，对tag的add和remove是直接写入cnpmcore的数据库，查看时访问的是上游仓库的tag信息。（这部分接口返回可能会让用户迷惑,查看到的tag和实际存储的tag不一致，或者代理模式下不应修改上游仓库中的tag信息？）

5. 目前考虑对标nexus仅支持一个上游仓库的模式而非verdaccio中支持的多个上游链路（即仅访问config中的sourceRegistry，不会根据registry表中的多个同步仓库去依次访问）
6. syncPackageBlockList配置项对代理仓库同样生效，在同步黑名单中的依赖在代理缓存时应同样处于黑名单中（或者代理仓库模式下需要一个独立的黑名单？）
7. 周期性的ping上游仓库，如果上游仓库无法连接则使用本地数据库的manifest（即传统syncMode为none时的状态），缓存过的依赖版本依旧可以访问，保证用户在安装已缓存依赖时不受限于代理仓库与上游仓库的网络状况。上游仓库恢复访问则切换至传统的代理模式。

上述逻辑中是否存在不合理的或者不完善的部分？

[fengmk2]

@hezhengxu2018 挺完善的，可以动手起来。我们走的是持续迭代模式，最初版本做到基本可用即可。

[hezhengxu2018]

#390 暂时没有实现新增数据库表及定时更新的功能，目前仅通过nfs的storeKey访问代理的缓存。这两个功能想基本的功能验证过了再添加。另外缓存包的逻辑很多地方是用的PackageSyncerService里的逻辑，但是细节的地方又不一样。这部分逻辑在更新缓存的定时任务的时候也会用到，希望能提取出来。

[hezhengxu2018]

将proxyMode拆分成syncSpecificVersion和proxyMode两次pr

[hezhengxu2018]

直接使用nfs上的文件不是一个好设计，经常会忘了清理nfs上的文件导致返回不符合预期。可以直接存在数据库中或者至少应该通过数据库来获取nfs文件的地址，而不是直接通过key访问。

[fengmk2]

nfs 是给本地开发使用的，真实部署场景都是走云存储。