解读
它是一种云计算模型, 在这种模式下面, 开发人员可以搭建和运行应用, 而且不用去管服务器底层架构或者是运行环境这些东西里的任何资源, 他们只要把代码写好了就行, 然后把写好后的那个程序上传到提供云服务的那家企业给出来的服务里面去就完事了, 接下来会由这个服务那边来出面去处理后续所有的事, 包括根据当时收到的那些请求的数量多少来自行决定要不要自动地让应用程序变强或者变弱。
在这个模型里面, 开发人员呢, 只需要为那些实际在使用的、应用程序所占据的资源的费用进行支付就行, 完全不需要去管那些预配好的或者是闲置下来的资源所产生的费用方面的问题, 正因为有这种状况的存在, 所以使得这个模型的运作模式变得在经济上更加划算并且效率更加高的状态。
另外需要注意的一点是，这绝对不等于说这个概念就是没有服务器的意思, 而真正想要表达的含义是说, 开发人员在相关的操作过程中, 根本不需要负责去管理那些服务器本身所涉及到的各种事务内容。
｜ 的优势｜ 的挑战
让对应用的托管进行简化, 虽然这样做了, 但是也存在一些挑战, 在这些挑战里头, 最大的两个挑战就是应用的可移植性以及冷启动的问题。
在不同的平台那里, 无论是工具还是开放接口这种事物, 都会存在不少差异。这对于开发者来说, 要在开发应用之前, 必须先决定使用哪个平台。原因在于应用的开发细节部分, 通常会与特定的平台产生耦合关系。而针对冷启动这个问题, 它是一件非常具有挑战性的事务。
在这一点上, 不同的平台也都花费了非常大的力气去努力, 这些努力的表现形式有好多, 比如提前预留实例名额, 再比如支持在一个实例里处理多个请求, 还可以靠着运用机器学习算法来预先推测流量的情况, 然后提前就把资源准备好；到了进行代码开发的这一侧呢, 开发者也可以采取对代码实施构建操作、打包操作, 以及压缩操作等多种手段, 把这些操作的目的归结为减少代码最终的总体积大小, 这样做的直接结果就是能显著加快应用部署时的上传效率, 同时也能大幅缩短应用在冷启动状态下所需的时间长度, 产生这个良好结果的深层原因就在于此, 因为如果代码体积变小了, 那么从云端拉取这部分代码所耗费的时间就变少了, 接着应用在本地开始启动运作的时候, 所消耗的时间也随之变得简短。
的诞生
我们发现应用的从开发阶段一直到最终提交部署的整个过程, 里面存在着非常广阔的能够进行优化的空间, 尤其是在相关的技术背景下面情况更是如此, 因为现有的状况已经让应用构建变得足够简单和轻松了, 所以我们可以尝试制作这样一个特别的工具出来, 去协助开发者朋友们把自己完成的应用程序通过一键操作的方式直接发送到平台上面去, 同时要求这个操作步骤必须既容易理解又速度极快, 以此来充分满足对于应用程序需要被经常反复部署这一实际存在的需求。
｜ 的愿景
它的愿景是希望帮助开发者把任意应用部署到任意平台, 所以它的口号就定在了这里。
｜ 的挑战
我们如果想要把目标实现的话, 我们需要把两个挑战去解决一下, 那这两个挑战是什么呢, 一个是我们要怎么去做适配以应对那些各个种类的应用程序的问题, 另外一个是我们要怎么去做适配以应对那些各个种类的平台设备的问题。
我们把应用生命周期这个概念进行了一层抽象的操作, 并且定义了一套专门用于统一的应用的适配规则的内容。然后根据这些适配规则来对当前所处的应用程序去执行构建操作、编译操作以及部署操作的具体事情。
这样做的主要目的是为了简化整体的部署流程方面的事情, 并且最终能够实现一种叫做一键部署的这样的能力的一种情况的存在。针对市面上常见的各种前后的端的框架的应用类型, 我们做了预先的定义的工作。
当系统的识别过程发现当前的应用程序正好属于某一个特定的这种框架下的应用的时候, 就会自动地进行匹配出那套相对比较合适的那种规则的事情, 并把规则给应用于具体的场景之中。通过这样的方式来达到一种零配置的这样的一种状态, 并最终实现了一键部署的效果。
这些框架的适配规则是开源的, 所以社区里面其他相关人员也能够适配他们自己心里想要的那个框架。在目前的状况下, 它一共支持了超过30款框架以及6个部署平台。
我们不仅仅是拥有那些适配规则, 而是需要做到让这些规则能够通过相应的功能解释得明白, 这样才能去满足各种各样的应用以及平台所提出的不同的需求情况。
为了解决这个问题, 我们设计出了一种叫做组件化的机制手段, 把针对各种不同的平台去做适配的具体实现工作, 分割成了一个一个独立的组件单元, 然后再根据既定的规则去触发并启动那些对应的组件项目, 让它们协同参与一起, 最终把整个关于应用的部署操作任务给完成完毕。
这些被划分出来的功能模块, 有些是可以预先放置准备好的状态，也可以是按照实际需求进行下载安装之后再进行使用的状态。
｜ 设计与实现
把组件当作是原子化的能力单位, 然后根据已经匹配到的框架、平台还有编程语言这种条件, 去激活那些确实需要使用到的组件, 靠着这些已经被激活起来的组件一块儿共同努力, 这样就能在一次部署的操作当中把它们搞定, 面向未来的状况, 要去满足不同场景之下在使用部署能力这方面的需求, 因此打算采用那种叫做 CLI 的方式去对外提供接口, 这样一来, 就能够和比如像我们平时用的 VS Code 这个编辑器呢, 或者是代码仓库里面那个持续集成工具相互结合得比较方便, 从而一起进行工作。
为了能适用于任何应用, 并且能够把应用部署到任何平台这个地方, 我们去抽象出来了一套一般性的, 就是通用的部署的规则。那么开发者方面的人呢, 他们可以依据自己所在业务的应用的具体状况情况。然后通过使用那种用.yml这个格式写的配置文件的内容来自定义他们的部署规则内容是什么。
与此同时的地方, 系统里面还默认预先放置了很多种常见的开发框架的部署规则。对于这些常见的框架我们这边是可以做到没有需要去配置任何东西就能直接使用这样的零配置的状态。并且可以实现用一个指令或者一个动作去完成整个过程的一键部署的目标实现。
｜ 智能适配过程
为了把部署的步骤给简化掉, 去实现一个不用配置的状态, 然后搞出一个能够一键完成部署的这个本事。所以呢, 这边对于那些常用的、属于主流框架的东西, 还有那些主流的, 专门用来进行部署的平台, 都做了个默认的适配动作出来。
正如上图所示, 一个开发者先选择了一个部署平台, 例如腾讯云云函数, 其本质就是激活了一种由腾讯云部署所指定的模式；然后系统会根据项目代码中的特征来智能识别当前所处的框架种类, 在上图中显示该框架被识别为框架, 据此判断这是一个属于静态站点类型的项目, 并且会随即自动地激活特定的部署模式；最后, 该平台机制将会依据腾讯云与前述模式两者在共同的作用域内处于运行时的状态, 并去分别激活与之对应的组件和相关配置项, 通过这些组件和配置的共同协作来最终完成整个任务的部署工作。
在这其中, 模式这东西, 实际上它就是一堆配置项凑在一起弄出来的东西。它会把你日常经常要用到的那些配置, 都给提前定义好。所以呢, 咱们根本用不着一个个去调。只要简单地通过一个模式来配一下, 就能把那些复杂的、基础的原子能力, 一下子全都弄好了。
｜ 支持的框架与平台
当前的情况是, 它支持的数量超过了 30 种, 这包括了前端框架, 也包括了后端框架, 这些都是主流的开发框架。与此同时, 它还覆盖了 6 个部署平台。那些开发框架的具体例子有, 诸如 Next.js、Koa.js、Nest.js、Vite、Vue、React、Flet、以及 UmiJS。
这些都属于前后端的框架范畴。至于部署平台这边, 它包含了腾讯云云函数、阿里云函数计算、还有 Azure。值得注意的是, Azure 还在开发当中。除此之外, 还有 AWS、某个平台、以及云服务器。
｜ 效果演示｜ 未来规划
未来的发展会往两个方向走, 一个是支持更多的前后端框架, 另一个是支持更多的平台。现在市场上存在的框架就有很多很多, 往后还会有越来越新的框架冒出来, 部署平台也是一样的道理。我们打算靠社区开发者大家的力气, 一道儿一起建设, 好让系统能够支持更多种类的框架和平台。
