深入了解云引擎
这篇文档希望向有经验的开发者介绍云引擎背后的更多细节,如希望快速地开始使用云引擎,请查看 快速开始部署云引擎应用。
云引擎适合什么样的应用
云引擎是一个基于容器技术实现的、进程级别的运行环境,开发者只需关注应用的进程本身,而不需要关注操作系统级别的环境。
在云引擎上,应用的进程可以专注在实现业务逻辑,通过标准化的接口来和云引擎交互:
- 应用可以使用 Git 来托管代码,云引擎会从指定的仓库拉取代码
- 应用通过依赖清单(如
package.json
)来描述应用对环境的需求,云引擎会自动地准备好这些环境 - 应用从环境变量中读取配置,云引擎提供了管理环境变量的能力
- 应用本身不包含数据或共享状态无状态、通过网络来访问数据,云引擎提供了托管的数据库和缓存服务
- 应用可以在云引擎上完成构建过程,云引擎提供了可自定义的构建机制
- 应用可以以多进程的方式运行,以便横向扩展
- 应用本身是完整的 、可运行的(而不需要嵌入一个宿主环境),通过网络对外提供 HTTP 服务
- 应用只需将日志写入到标准输出,云引擎会将日志收集起来以便查看
云引擎很大程度上受到了 12-Factor 的影响,你可以在它的官网上了解到更多构建现代化、可移植、易于扩展和维护的后端服务的方法论。
构建
云引擎针对多种语言提供了构建支持,我们称之为「运行环境(Runtime)」,云引擎会根据项目代码的结构去判断项目的类型,例如根目录包含 package.json
就会被认为是 Node.js 项目。
在开发者使用 Git 或命令行工具将代码上传到云引擎后,云引擎就会开始一个「构建」的过程,云引擎会根据项目的运行环境安装依赖(如 npm install
)、构建可执行文件(如 go build
)、执行用户自定义的命令(可在 leanengine.yaml 中配置)。
构建过程最后会生成一个「版本」用于后续的部署,其中包含了应用的源代码、下载的依赖和构建出的可执行文件(部分运行环境),版本有一个类似 20210913-150821 的编号,在应用内是唯一的。
构建缓存
为了加速构建的过程,云引擎采用了「分层缓存(Layered Cache)」的缓存机制,即如果一个步骤需要执行的操作没有变化,那么就不实际执行,直接采用前一次执行的结果(缓存);但如果某个步骤需要执行的操作发生了变化,那么从此之后的所有步骤都需要重新执行。举例来说如果项目的依赖清单(如 package.json
)没有发生变化,那么就不会重新执行依赖安装,而是采用前一次安装好的结果,整个构建过程就会快很多。
构建缓存只是一种 加速构建的机制,云引擎并不保证依赖没有变化就一定能使用缓存。
如果在项目依赖的版本指定为某个范围,且两次部署之间依赖声明文件无改动,但该依赖发布了新版本(新版本仍在指定的范围之内),那么,由于缓存机制的存在,在缓存过期前,仍会安装之前的依赖版本,而非指定范围内的最新版本。
如果希望这种情况下,始终安装指定范围内的最新版本依赖,那么需要使用 --no-cache
禁用缓存。
资源限制
构建过程 的资源限制为:
- 2 个 CPU 核心: CPU 使用率最高为 200%
- 30 分钟 CPU 时间: 如果构建命令消耗了太多 CPU 时间会被强制停止。
- 4 GB 内存: 如果在构建过程中遇到了 "Out of memory" 或 "memory allocation error" 错误,可能是消耗了超过 4 GB 的内存导致的,需要调整构建命令来使用更少的内存,比如限制并发执行的编译器进程数量。