精华 跟我一起部署和定制 CNPM——自定义包存储层
发布于 1 天前 作者 xadillax 80 次浏览 来自 分享

原文链接:https://xcoder.in/2016/07/22/lets-cnpm-storage/

CNPM 的自定义包存储层文件系统简称 NFS,我猜是 NPM File System 的意思。

在之前《跟我一起部署和定制 CNPM——基础部署》中提到过,CNPM 配置项里面有一项配置 nfs,它所对应的是一个 NFS 对象。

在同步 package 的时候,CNPM 会把源站的包下载到本地,然后传给 NFS 对象相应的函数交予去处理,由 NFS 对象返回处理结束之后该包在我们自己部署的 CNPM 对应的包下载链接。

上面的这一套流程就给我们自定义包存储提供了可能,比如我们可以把包同步到又拍云存储、阿里云 OSS 等地方去,也可以以二进制的形式存入我们自己的数据库(不推荐),甚至可以什么都不用做直接放在本地,然后把本地文件对外网暴露即可。

NFS 接口

NFS 的接口是实现定义好的,我们如果要写一个自己的 NFS 类,只需要按照约定的接口实现他们的逻辑即可。

虽然我自己不喜欢,但是 NFS 的所有函数需要在菊花函数中被实现。

下面给出接口的定义:

  • function* upload(filepath, options)
    • filepath:文件路径。
    • options
      • key:待上传文件的标识
      • size:待上传文件大小
  • function* uploadBuffer(fileBuffer, options)
    • fileBuffer:待上传文件的 Buffer
    • options
      • key:待上传文件的标识
      • size:待上传文件的大小
  • function* remove(key)
    • key: 文件标识
  • function* download(key, savePath, options)(可选实现)
    • key:文件标识
    • savePath:保存路径
    • options
      • timeout:超时时间
  • function* createDownloadStream(key, options)(可选实现)
    • key: 文件标识
    • options
      • timeout:超时时间
    • 返回一个 ReadStream
  • function[*] url(key)(可选实现,可以不是菊花函数)
    • key: 文件标识

OSS-CNPM 解析

这里拿出一个 NFS 的官方实现阿里云 OSS 版来作为解析。它的 Repo 是 https://github.com/cnpm/oss-cnpm

打开 index.js 我们能看到,的确 OssWrapper 实现了上面的一些接口。

构造函数

function OssWrapper 里面我们看到它 newali-oss 对象。

if (options.cluster) {
  options.schedule = options.schedule || 'masterSlave';
  this.client = new oss.ClusterClient(options);
} else {
  this.client = oss(options);
}

也就是说在各种上传等函数里面都是以这个 client 为主体做的事情的。

upload 和 uploadBuffer

首先我们看看 upload 函数,从外部传进来文件的 key,NFS 对象将该文件以 key 为名传到 OSS 去,并返回该文件上传之后在 OSS 上的地址。

proto.upload = function* (filePath, options) {
  const key = trimKey(options.key);
  // https://github.com/ali-sdk/ali-oss#putname-file-options
  const result = yield this.client.put(key, filePath, {
    headers: this._defaultHeaders,
  });
  if (this._mode === 'public') {
    return { url: result.url };
  }
  return { key: key };
};

uploadBuffer 其实也一样,参数第一个 fileBuffer 是一个文件二进制 Buffer 对象,而 ali-oss 包的 put 函数第二个参数既可以传一个文件路径,也可以传一个 Buffer,所以相当于把 upload 这个函数直接拿过来就能用了,于是就有了:

proto.uploadBuffer = proto.upload;

remove、download 和 createDownloadStream

这两个函数实际上也是直接调用了 ali-oss 的函数,并没有什么好讲的,大家自己看看就好了。

url

这个函数无非就是判断下有没有自定义的 CDN 域名什么的,根据不同的返回不同的网址而已。

trimKey

key 里面带的最前面的斜杠去掉。

我的 OSS-CNPM 随意改造

上面一节解析了 oss-cnpm 这个包的代码,如果官方出的几个 NFS 包不能满足,大家也能自己去写一个 CNPM 存储层的包了。

我们公司的包是直接在 OSS 上面的,所以用 oss-cnpm 并没有什么不妥。

不过对于阿里系本身的公司门来说,OSS 并不是什么大事儿,对于我们来说,OSS 的 bucket 资源还是蛮稀缺的,上次就达到上限了。所以我们目前的 NPM 包跟公司别的测试业务用的是同一个 bucket。

那么问题来了:

oss-cnpm 直接把所有文件放在根目录下建文件夹,太乱了,而且的确是有小可能冲突的。而这个包又不能让人自定义前缀什么什么的。

于是我就自己 Fork 小小改装了一下这个包,让它适合我们公司自己。

改装很简单,在上传的目录中加一个文件夹前缀。

动的是 trimKey 函数:

function trimKey(key) {
  return '_snpm_/' + (key ? key.replace(/^\//, '') : '');
}

这下所有在我们内部 CNPM 里面的包的链接都多了个 _snpm_/ 的前缀了。

CNPM 调用解析

上面解析了接口之后,我们来扒一扒什么时候会调用上面实现的接口们吧,这样就知道 CNPM 对于 NFS 使用的工作原理了。

controllers/registry/package/download.js

源码参考

对于包下载来说,它的路由是:

/{package}/download/{package}-{version}.tgz

然后在里面判断一下如果 NFS 对象有实现 url() 函数的话,先用 url() 函数生成对该包而言的真实下载链接。

读出这个包的 registry 信息,里面如果没有 dist 等参数的话直接 302 到刚生成的地址去。

if (typeof nfs.url === 'function') {
  if (is.generatorFunction(nfs.url)) {
    url = yield nfs.url(common.getCDNKey(name, filename));
  } else {
    url = nfs.url(common.getCDNKey(name, filename));
  }
}

if (!row || !row.package || !row.package.dist) {
  if (!url) {
    return yield* next;
  }
  this.status = 302;
  this.set('Location', url);
  _downloads[name] = (_downloads[name] || 0) + 1;
  return;
}

接下去是涉及到上一章没有提到过的一个配置参数,叫 downloadRedirectToNFS,默认为 false。如果该值为 true 的话并且刚才由 url() 函数生成了下载链接的话,也是直接 302 到真实下载链接去。

if (config.downloadRedirectToNFS && url) {
  this.status = 302;
  this.set('Location', url);
  return;
}

不过如果本身 registry 里面就没 key 这个选项的话也会直接用 url() 生成的链接给跳过去。如果没有 url() 的链接,那么直接用 registry 里面的 tarball 字段。

var dist = row.package.dist;
if (!dist.key) {
  url = url || dist.tarball;
  this.status = 302;
  this.set('Location', url);
  return;
}

上面如果都跳过去了,那么说明要开始调用事先写好的 download 那两个函数了,把文件读到 Buffer 里面,然后把 Buffer 放到 Response 里面传回去。

controllers/registry/package/remove.js

源码参考

对于删除包来说,除了把包从数据库删掉之外,还要循环遍历一遍这个包的所有版本,把所有版本的这个包都从 NFS 里面删除。

try {
  yield keys.map(function (key) {
    return nfs.remove(key);
  });
} catch (err) {
  logger.error(err);
}

这里就调用了你事先写好的 remove 了。当然你不实现也没关系,最多是包的压缩文件不删除而已。

controllers/registry/package/remove_version.js

源码参考

这里跟上一小节差不多,之前是删除整个包,这里是删除包的某一个版本,所以就不用循环删除了。

try {
  yield nfs.remove(key);
} catch (err) {
  logger.error(err);
}

controllers/registry/package/save.js

源码参考

然后就是用户 $ npm publish 用的路由了,在一堆判断之后,发布传过来的包被放在二进制 Buffer 内存里面:

var tarballBuffer;
tarballBuffer = new Buffer(attachment.data, 'base64');

接下去又判断来判断去,最后交由 NFS 的 uploadBuffer 来上传并得到结果。

var uploadResult = yield nfs.uploadBuffer(tarballBuffer, options);

var dist = {
  shasum: shasum,
  size: attachment.length
};

if (uploadResult.url) {
  dist.tarball = uploadResult.url;
} else if (uploadResult.key) {
  dist.key = uploadResult.key;
  dist.tarball = uploadResult.key;
}

看到没有,就是这里记录的它到底是 key 还是 tarball 了。

如果你的 upload 函数返回的是 { url: 'FOO' },那么就是 tarball 设置成该值,在下载的时候会直接 302 到 tarball 所指的地址去;如果返回的是 { key: 'key' } 的话,会在 dist 里面存个 key,下载的时候判断如果有 key 的话会把它传进你的 createDownloadStream 或者 download 函数去交由你的函数生成包 Buffer 并传回 Response。

controller/sync_module_worker.js

源码参考

这个文件是从源端同步相关的一些逻辑了,这里面有两个操作。

一个是 unpublish,调用的就是 NFS 的 remove,不作详谈了。

另一个就是同步了。同步包会被打散成同步一个版本,然后把每个版本同步过来。在同步版本的时候先把包文件下载到本地文件 filepath 里面去。

var r = yield urllib.request(downurl, options);

urllib 是苏千死马他们自己写的比较方便和适合他们自己的一个 http 请求库。

上面的代码 options 里面有一个文件流,链接到 filepath 目录的这个文件去,相当于这一步就是把源端的包下载到本地 filepath 去了。

经过一堆 blahblah 的判断(比如 SHASUM)之后,这个这个函数就会调用 NFS 的 upload 函数将本地文件名对应的文件上传到你所需要的地方去了。

try {
  result = yield nfs.upload(filepath, options);
} catch (err) {
  logger.syncInfo('[sync_module_worker] upload %j to nfs error: %s', err);
  throw err;
}

其结果到底是 key 还是 url 对于下载的影响跟前一小节一个道理。

小结

本章讲了如何使用和自己定制一个 CNPM 的 NFS 层,让包的走向跟着你的心走。在描述了开发规范和出示了样例代码和改造小例子之后,又解析了这个 NFS 是如何在 CNPM 里面工作的,上面已经提到了 2.12.2 版本中所有用到 NFS 的地方。

看了上面的解析之后会对 NFS 的工作流程有更深一层的了解,然后就不会有写 NFS 层的时候有种心慌慌摸不着底的情况了。

回到顶部