由于近两年一直在从事 serverless 系统的开发，本篇文章算是在未来 serverless 开发方向的一些心得，对这套开发模式未来的一些走向提供一些自己的所见所想，也基于目前过于传统的 serverless 的实现在表达不满的同时，自己也重写做了一些实现以及在项目中的一些工程化的实践，得出一些结论和大家共享。当然毕竟一千个人的眼里就有一千个哈姆雷特，所以意见不同请轻喷，感谢。

序言

在双逢干涉中，我们有理由怀疑这个世界的真实性。在 docker 诞生后，我们可以虚拟化当前的环境。那么如果实现一个让代码层面就直接实现虚拟化，是不是有点意思？

虚拟化-核心

核心作为实现 node.js 虚拟化的第一步，我们要有各种欺骗代码的一些技巧。比如为每块代码都提供出对应的容器,而对于容器而言需要虚拟的部分主要在于虚拟 module 和 process 以及一个重写过的 require 。大致结构如下：

虚拟的 module 的主要作用是打断和宿主 module 的联系，也就是说在虚拟容器中发生的引用可能对于宿主 module 来说根本就没有发生过。

虚拟 process 的目的是让虚拟环境对 process 的修改只对自己生效，而不会影响到宿主环境的 process ，即是环境变量方向的一种欺骗。

重写的 require 目的和虚拟 module 的区别主要是实现对系统模块或第三方模块或引用路径的重写或权限限制。比如不允许你引用当前目前外的代码，再比如就是重写 fs 模块，让你读取的文件表明是在服务器而实质是可能是某个分布式数据库中。

源代码传送门: https://github.com/virtual-less/vaas-core

虚拟化-服务框架

有了核心，我想是时候跟目前传统的微服务架构和函数即服务再见了，首先我们要有更加优雅的实现。

是时候跟使用仓库隔离来防止引用说再见了👋 我们可以直接在引用层拦截 ✅
是时候跟 callback 和 ctx.body={...}这种丑陋的写法说再见了👋 我们直接用 return 返回数据，throw 抛出异常✅
是时候跟中心化路由这种集中化配置导致易发冲突的方式说再见了👋 我们直接用装饰器的中心化路由实现 [具体如下个例子] ✅

import {VaasServerType, Decorator } from 'vaas-framework'
export default class Hello {
    @Decorator.VassServer({type:'http',method:'get',routerName:'/hello'})
    async hello({req,res}:VaasServerType.HttpParams) {
        return {
            hello:'world'
        }
    }
}

以上是虚拟化服务框架中最简单的代码例子，这里代表了在 /hello/hello 中能返回{hello:'world'}的结果。其中：

每一个变量有拥有其变量提示
路由通过装饰器 VassServer 来配置，同时支持另外两种类型 rpc 和 websocket
通过 return 返回数据，通过 throw 来抛出 Error 类型异常

既然作为使用虚拟化框架，也就意味着不同的 APP 不能相互实现阻塞和相互的影响，所以在架构实现上对于每个 App 都支持配置多线程数量，且每个多线程中使用 vm 进行对应的虚拟化工作。同时依托于线程池控制，即可实现多个请求复用 worker 。而每个 App 的代码非常巧妙在 worker 中进行了缓存且被不断的使用，直到长期无请求导致 worker 过期回收。具体架构如下：

这个架构之下还有一个好处就是不需要过度关心内存泄漏问题，因为单次请求结束且超时时间外没有新连接则默认释放内存，这个模式类似 PHP ，但是和 PHP 不同点为不会马上释放，且可以复用多线程的模式。

如果想要体验，可以使用 npm 的初始化脚本进行体验(系统需要支持 git 且需要在命令行中翻墙，win 系统请谨慎尝试)

npm init vaas

源代码传送门: https://github.com/virtual-less/vaas-framework

虚拟化-服务平台

光有框架，我觉得还是远远不够的，所以我决定使用框架作为底层提供出一个为私有企业定制的一套部署平台，也就是说你可以直接在这个平台上部署一些虚拟化的 App ，同时可以支持直接在平台上实现 App 相关的配置。也就是说这个服务平台的作用是当框架开发完成若干 APP ，可以直接使用这个平台来管理 APP 并实现动态部署，让开发和发布更加简单。同时这个平台也是基于虚拟化-服务框架进行开发的一个 APP 。

目前服务平台使用了 ETCD 作为配置中心来实现 APP 配置和部署配置。并实现了配置界面：

App 配置主要用于限制对代码的一些权限配置和性能限制，比如不希望代码读文件则可以不添加 fs 模块权限。如下：

域名配置主要用于当我们需要域名直接打到 app 时做的一些域名上的配置，这样访问就不需要还带有 app 路径。如下：

在使用 ETCD 作为平台配置组件时，中间发生了一个小插曲，在使用 ETCD 的时候搜索了一圈居然没有支持 ETCD3.5 以上的 npm 包😂，所以顺手简单整合封装了一波。

源代码传送门: https://github.com/zy445566/netcd

同时使用 S3 文件服务的完全实现 minio 来作为代码文件服务的管理，包括我们需要发布一些 APP 也是执行vaas deploy 命令先上传到 minio 的服务上，并修改 ETCD 配置来完成部署。再由平台来通过校验本地代码和对比 ETCD 的代码地址区别来决定保证第一时间完成部署。具体架构如下：

这个基本是一个最简化的 serverless 部署平台，实现了前后端，对于想要自己定制的，下面也开放的源码，按照自己企业要求修改即可。

源代码传送门:

后端: https://github.com/virtual-less/vaas-platform

前端: https://github.com/virtual-less/vaas-platform-ui

结语

通过底层的虚拟化，开发层面上框架层，到最后使用层面的平台层，严格来说这其实是代码层面上的 serverless 的开源实现。但是比目前 serveless 平台来比较的话，更关注于个人或企业内部的使用，而不是对外开放使用。同时在代码使用方式和开放部署流程上的一些优化与提升。在服务架构上来说未来不一定说一定会朝着虚拟化这个方向前进，但一定会是一个必经之路。

虚拟化服务， JS 服务架构的未来

序言

虚拟化-核心

虚拟化-服务框架

虚拟化-服务平台

结语