20250706-7-Docker 快速入门（上）-容器存在的意义、优势、Docker_笔记

一、为什么使用容器



1. 上线流程繁琐



1）传统上线流程的描述



• 
• 流程环节：开发→测试→申请资源→审批→部署→测试等环节
• 耗时问题：整个流程至少需要一周以上时间才能完成新项目上线
• 管理痛点：涉及资源申请、审批、部署等多个环节，每个环节都需要人工介入和等待

2）容器对上线流程的改善



• 资源池化：预先准备一批机器作为Docker主机形成资源池，需要时直接调用
• 部署优化：容器可以复用预先配置好的部署环境，避免重复配置
• 自动化程度：软件部署、配置、监控等环节可以实现自动化处理
• 效率提升：主要改善了资源申请和部署两个环节的效率

3）容器改善上线流程的局限性





• 本质局限：并未从根本上改变上线流程，只是优化了部分环节
• 审批流程：资源申请和审批等管理流程仍未实现完全自动化
• 成熟度问题：容器技术兴起时间较短，相关管理流程尚不健全

2. 资源利用率低





1）传统部署方式导致的资源利用率低



• 典型数据：大部分服务器资源利用率仅5%左右，达到10%以上的都不多
• 特殊情况：只有CPU密集型或内存密集型应用可能达到70-80%利用率
• 成本问题：低利用率导致资源浪费，增加了企业运维成本

2）虚拟化技术提高资源利用率



• 解决思路：通过虚拟化技术在一台物理机上创建多个虚拟机
• 隔离特性：虚拟机之间完全隔离，各自运行独立项目
• 管理优势：以虚拟机为单位进行项目管理和资源配置
• 效果提升：相比物理机部署方式，虚拟化显著提高了资源利用率

3）容器化技术进一步提升资源利用率



• 粒度细化：容器技术在操作系统层面进一步细分资源分配
• 轻量特性：每个容器对应一个应用，比虚拟机更加轻量级
• 架构演进：从物理机→虚拟机→容器的技术发展路径

4）容器化对资源利用率的优化与考量



• 优化重点：主要在应用层面和操作系统层面进行资源利用优化
• 实际考量：并非单纯追求资源利用率最大化，需平衡性能与稳定性
• 潜在问题：过高的资源利用率可能带来其他运维风险

3. 扩容/缩容不及时

1）扩容/缩容不及时的问题描述



• 流程繁琐：传统扩容需要经历开发→测试→申请资源→审批→部署→测试等多个环节
• 业务影响：在业务高峰期（如618、双11）扩容流程繁琐导致上线不及时
• 成本考量：平时服务器保持最小成本运行，通常只预留20%-30%的突发承载量

2）已知业务高峰期的扩容策略

• 提前规划：对可预见的业务高峰（如促销活动）提前3-5天甚至一周进行扩容
• 技术含量：已知情况下的扩容相对简单，主要依赖流程执行而非技术难度

3）未知业务突发量的应对策略



• 预留资源：业务机器增加30%承载量以应对未知突发
• 常规标准：服务器配置通常高于实际使用率30%以上
• 局限性：当突发量超出预留量时，需要更灵活的解决方案

4）弹性伸缩的介绍



• 核心能力：基于CPU、内存等指标自动扩容/缩容
• 云服务方案：阿里云（云主机弹性伸缩）、AWS（Auto Scaling）
• 技术挑战：及时扩容是弹性伸缩最具挑战性的部分

5）容器在扩容/缩容中的优势



• 环境一致性：解决传统虚拟机扩容时环境不一致问题
• 流程优化：相比虚拟机模板部署方式更快速可靠
• 部署效率：容器镜像可以快速部署，减少测试验证环节

4. 服务器环境臃肿



• 问题表现：服务器运行时间越长，系统环境越臃肿
• 维护困难：多应用混杂导致维护和迁移困难
• 安全风险：单点故障时恢复时间长（案例：被黑服务器花费数年梳理）
• 容器优势：Docker提供清晰的环境治理，应用状态一目了然

5. 环境不一致性



1）环境不一致性的问题



• 典型场景：开发→测试→线上环境存在差异
• 常见原因：操作系统、软件版本、配置参数等不一致

2）环境不一致性导致的后果



• 开发测试矛盾：开发环境正常但测试环境失败
• 责任推诿：开发与运维之间形成"甩锅"现象
• 上线风险：环境差异可能导致线上故障

3）Docker解决环境不一致性



• 统一管理：开发、测试、生产环境统一使用Docker
• 设计理念：应用打包后可在任何Docker引擎一致运行
• 价值体现：从根本上解决环境差异导致的部署问题
• 
• 架构差异：容器共享主机OS，虚拟机需要独立Guest OS
• 资源效率：容器更轻量，启动更快，资源利用率更高
• 隔离程度：虚拟机提供更强的隔离性，容器更侧重应用隔离

二、容器与虚拟机



1. 虚拟机的层次结构



1）虚拟机层次结构概述

• 
• 核心差异：虚拟机通过Hypervisor层实现硬件虚拟化，容器通过Docker引擎直接共享主机操作系统内核

2）计算机硬件层

• 组成要素：包含CPU、内存、硬盘等物理组件，是所有虚拟化技术的基础支撑
• 运行基础：任何操作系统都必须基于计算机硬件才能运行，是层次结构的最底层

3）主机系统（宿主机）层



• 专业术语：在虚拟化领域称为"宿主机"，如Windows系统直接安装在硬件之上
• 功能定位：为上层虚拟化软件提供基础运行环境，管理底层硬件资源

4）Hypervisor层

• 核心地位：是整个虚拟化技术的核心组件（如VMware软件）
• 工作原理：
  • 位于物理硬件与操作系统之间的中间层
  • 模拟虚拟机所需的CPU、内存、网络等虚拟设备
  • 负责多个虚拟机之间的资源调度分配
• 实现效果：使多个操作系统可以共享同一套物理硬件

5）虚拟机操作系统层



• 
• Guest OS：每个虚拟机运行独立的完整操作系统（如演示中的10多个CentOS实例）
• 隔离特性：
  • 具备完整的二进制文件和库文件
  • 提供完全隔离的服务器级环境
  • 用户感知如同使用独立物理计算机

6）虚拟机内的应用程序



• 运行位置：部署在Guest OS之上的应用软件
• 架构特点：每个虚线框代表一个包含完整OS栈的虚拟机单元

2. 容器的层次结构



• 关键变化：
  • Hypervisor替换为Docker引擎
  • 省去Guest OS层，容器直接共享主机OS内核
• 核心优势：轻量化部署应用，不需要完整的操作系统环境
• 隔离特性：相比虚拟机提供的是应用级隔离而非系统级隔离

3. 虚拟机与容器的对比



• 
• 核心差异：容器是操作系统级别的虚拟化技术，而虚拟机是系统级的完整虚拟化

1）启动速度

• 容器优势：秒级启动，直接运行在宿主机内核上，无需加载操作系统内核
• 虚拟机劣势：分钟级启动，需要完成硬件自检、内核加载等完整启动流程
• 实际体验：创建容器时通过一条命令即可立即运行，而虚拟机需要等待完整启动过程

2）运行性能

• 容器特性：
  • 接近原生性能：通过进程级隔离实现，仅对特定进程进行逻辑隔离
  • 技术原理：利用Linux命名空间和控制组(cgroups)技术实现资源隔离
  • 性能损耗：抽象层转换处理会带来极小开销，但影响可忽略不计
• 虚拟机特性：
  • 5%性能损失：主要来自Hypervisor层的硬件虚拟化开销
  • 典型场景：IO操作需经虚拟磁盘转换，CPU/内存需经Hypervisor调度
  • 行业现状：实际业务中通常通过增加机器数量来弥补性能损失

3）磁盘占用

• 容器优势：
  • MB级占用：利用联合文件系统技术最大化利用磁盘空间
  • 存储原理：仅打包项目代码和依赖关系，共享宿主机内核
• 虚拟机劣势：
  • GB级占用：单个虚拟机磁盘文件通常达4GB以上（如演示中的CentOS镜像）
  • 存储原理：需要包含完整操作系统，包括内核和设备驱动
• 实际案例：VMware虚拟机工作目录中的.vmdk文件通常超过10GB

4）数量

• 容器优势：
  • 成百上千实例：基于进程级隔离，类似运行多个脚本进程
  • 实现基础：依赖宿主机PID等系统资源限制，通常现代系统支持充分
• 虚拟机限制：
  • 几十台规模：128G内存+64核CPU服务器通常运行40-50台
  • 资源制约：实际数量取决于业务负载，更多考虑性能余量

5）隔离性

• 容器特性：
  • 进程级隔离：通过沙盒机制实现逻辑隔离
  • 资源可见性：共享宿主机硬件资源，无独立设备模拟
• 虚拟机特性：
  • 系统级隔离：完全模拟独立硬件环境（CPU/内存/磁盘/网络）
  • 隔离优势：每个虚拟机拥有专属虚拟设备，隔离更彻底
• 典型差异：容器内无法看到独立硬件设备，而虚拟机可配置专属硬件参数

6）操作系统支持

• 容器局限：主要支持Linux系统，Windows支持有限且不实用
• 虚拟机优势：支持几乎所有主流操作系统（Windows/Linux/macOS等）
• 技术原因：容器依赖Linux内核特性，而虚拟机通过完整OS模拟实现跨平台

7）封装程度

• 容器特点：
  • 轻量封装：仅包含应用代码和依赖库
  • 内核共享：直接使用宿主机内核，无独立内核
• 虚拟机特点：
  • 完整封装：包含客户操作系统内核和所有系统组件
  • 独立环境：提供完整的系统调用接口和设备驱动

8）技术定位差异

• 
• 容器核心价值：
  • 应用层面：解决快速部署、高效管理问题
  • 环境特性：提供基本的独立运行环境和资源限制
• 虚拟机核心价值：
  • 资源层面：提升服务器资源利用率
  • 环境特性：提供完全隔离的系统环境
• 行业现状：
  • 公有云仍依赖虚拟机技术保障多租户隔离
  • 容器技术补充了应用部署和管理领域的空白
  • 两种技术互补共存，不存在完全替代关系

三、Docker是什么

• 开源容器引擎: 当前使用最广泛的开源容器技术，已成为容器技术的代名词（其他引擎包括rkt、podman等）
• 操作系统级虚拟化: 基于容器化技术实现，容器以特殊进程形式在宿主机运行，提供完全隔离的沙盒环境
• 内核依赖: 利用Linux内核特性Namespace（资源隔离）和Cgroups（资源限制）实现容器化
• 应用打包工具: 类似压缩包机制，将应用及其环境打包成标准格式，可在任何Docker环境保持一致性运行

四、Docker设计目标

1. 提供简单的应用程序打包工具



• 
• 集装箱设计思想: 类比货运集装箱，实现应用隔离运输（Docker logo中鲸鱼代表宿主机，集装箱代表应用）
• 打包机制: 类似ZIP压缩包，将应用代码+环境打包成镜像（image），保证在任何Docker环境解压运行结果一致
• 应用层解决方案: 主要解决应用部署层面的标准化问题，实现"一次构建，到处运行"

2. 开发人员和运维人员职责逻辑分离

• 开发新职责:
  • 镜像打包: 将项目代码和运行环境打包成可部署的Docker镜像
  • 自主部署: 将镜像部署到运维提供的容器平台（传统流程中仅提交代码）
• 运维新职责:
  • 平台管理: 专注于容器集群的高效管理（监控/日志/调度）
  • 资源优化: 提升资源利用率，制定应急预案
• 核心优势:
  • 成本节约: 减少60%以上的部署沟通成本（大公司实践数据）
  • 问题定位: 发布问题可快速定位到具体镜像责任方
  • 标准接口: 开发只需关注镜像规范，运维专注平台能力

3. 多环境保持一致性



• 环境标准化: 通过镜像统一开发/测试/生产环境配置，消除"在我机器能跑"问题
• 生命周期管理: 应用从构建到退役全程使用相同镜像规范
• 技术债预防: 避免服务器环境臃肿，新成员可快速理解环境架构
• 行业影响: 该特性是Docker能快速普及的关键因素（2013-2016年爆发式增长）

五、Docker应用场景



1. 应用程序打包和发布



• 标准化封装：通过容器镜像实现应用程序及其依赖环境的统一打包，解决"在我机器上能跑"的环境一致性问题
• 跨平台部署：打包后的镜像可在任何支持Docker的平台上运行，实现开发、测试、生产环境的无缝迁移

2. 应用程序隔离



• 资源隔离：在同一物理机上运行多个项目时，容器提供进程、网络、文件系统等资源的隔离，确保应用间互不可见
• 资源限制：可对CPU、内存等资源进行配额限制，防止单个容器耗尽主机资源（如：限制某个微服务最多使用2G内存）
• 安全边界：相比传统虚拟机更轻量级，但比直接部署提供更好的安全隔离性

3. 持续集成部署



• CI/CD核心组件：现代持续集成环境（如Jenkins、GitLab CI）普遍集成Docker作为构建和交付单元
• DevOps实践：容器技术实现"构建一次，随处运行"，消除环境差异导致的部署问题
• 标准化流程：从代码提交到自动化测试再到生产部署，全程使用容器作为交付物

4. 微服务



• 独立部署：每个微服务可打包为独立容器，拥有专属的数据库和运行环境（如订单服务与支付服务分离）
• 渐进式升级：避免传统单体应用"牵一发而动全身"的问题，单个服务故障不影响整体系统可用性
• 弹性伸缩：配合K8s可快速实现微服务的水平扩展（如促销期间单独扩容商品查询服务）
• 运维治理：解决微服务带来的运维复杂度问题，通过容器编排统一管理数十上百个服务实例

5. 快速搭建测试环境



• 即开即用：通过官方镜像快速部署复杂中间件（如Hadoop集群、Redis集群等）
• 环境复用：测试完成后可销毁容器，不影响主机环境，下次测试时重新拉起相同镜像
• 降低门槛：使开发/测试人员无需深入掌握系统配置（如免去搭建分布式系统的繁琐步骤）

6. 提供PaaS产品



• 云服务基础：主流云平台（如阿里云、AWS）的PaaS服务均基于容器技术构建
• 标准化运行时：用户只需关注业务代码，无需管理底层服务器和中间件
• 多租户隔离：通过容器实现租户间的资源隔离和安全隔离，保障SLA

六、知识小结