NodeJS 服务 Docker 镜像极致优化指北( 三 ) _生活百科

这里我的建议是，优先保证构建时间，其次在不影响时间的情况下，尽可能的缩小构建缓存体积。
以 Docker 的思维管理服务避免使用进程守护我们编写传统的后台服务时，总是会使用例如 pm2、forever 等等进程守护程序，以保证服务在意外崩溃时能被监测到并自动重启。但这一点在 Docker 下非但没有益处，还带来了额外的不稳定因素。
首先，Docker 本身就是一个流程管理器，因此，进程守护程序提供的崩溃重启，日志记录等等工作 Docker 本身或是基于 Docker 的编排程序（如 kubernetes）就能提供了，无需使用额外应用实现。除此之外，由于守护进程的特性，将不可避免的对于以下的情况产生影响：

增加进程守护程序会使得占用的内存增多，镜像体积也会相应增大。
由于守护进程一直能正常运行，服务发生故障时， Docker 自身的重启策略将不会生效，Docker 日志里将不会记录崩溃信息，排障溯源困难。
由于多了个进程的加入， Docker 提供的 CPU、内存等监控指标将变得不准确。

因此，尽管 pm2 这样的进程守护程序提供了能够适配 Docker 的版本：pm2-runtime，但我仍然不推荐大家使用进程守护程序。
其实这一点其实是源自于我们的固有思想而犯下的错误。在服务上云的过程中，难点其实不仅仅在于写法与架构上的调整，开发思路的转变才是最重要的，我们会在上云的过程中更加深刻体会到这一点。
日志的持久化存储无论是为了排障还是审计的需要，后台服务总是需要日志能力。按照以往的思路，我们将日志分好类后，统一写入某个目录下的日志文件即可。但是在 Docker 中，任何本地文件都不是持久化的，会随着容器的生命周期结束而销毁。因此，我们需要将日志的存储跳出容器之外。
最简单的做法是利用 Docker Manager Volume，这个特性能绕过容器自身的文件系统，直接将数据写到宿主物理机器上。具体用法如下：
docker run -d -it --name=app -v /app/log:/usr/share/log app运行 docker 时，通过-v 参数为容器绑定 volumes，将宿主机上的 /app/log 目录（如果没有会自动创建）挂载到容器的 /usr/share/log 中。这样服务在将日志写入该文件夹时，就能持久化存储在宿主机上，不随着 docker 的销毁而丢失了。
当然，当部署集群变多后，物理宿主机上的日志也会变得难以管理。此时就需要一个服务编排系统来统一管理了。从单纯管理日志的角度出发，我们可以进行网络上报，给到云日志服务（如腾讯云 CLS）托管。或者干脆将容器进行批量管理，例如Kubernetes这样的容器编排系统，这样日志作为其中的一个模块自然也能得到妥善保管了。这样的方法很多，就不多加赘述了。
k8s 服务控制器的选择镜像优化之外，服务编排以及控制部署的负载形式对性能的影响也很大。这里以最流行的Kubernetes的两种控制器（Controller）：Deployment 与 StatefulSet 为例，简要比较一下这两类组织形式，帮助选择出最适合服务的 Controller 。
StatefulSet是 K8S 在 1.5 版本后引入的 Controller，主要特点为：能够实现 pod 间的有序部署、更新和销毁。那么我们的制品是否需要使用 StatefulSet 做 pod 管理呢？官方简要概括为一句话：