一、为什么使用容器
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
六、知识小结
知识点 |
核心内容 |
考试重点/易混淆点 |
难度系数 |
容器技术解决的问题 |
1. 上线流程繁琐 2. 资源利用率低 3. 扩容缩容不及时 4. 服务器环境臃肿 5. 环境不一致性 |
环境不一致性是开发与运维常见矛盾点 |
⭐⭐⭐ |
容器与虚拟机对比 |
容器:秒级启动、接近原生性能、MB级磁盘占用、进程级隔离 虚拟机:分钟级启动、5%性能损耗、GB级磁盘占用、OS级隔离 |
隔离性是本质区别(容器共享内核/虚拟机完全隔离) |
⭐⭐⭐⭐ |
Docker设计目标 |
1. 应用打包标准化 2. 开发运维职责分离 3. 多环境一致性保障 |
开发打包镜像取代传统代码提交模式 |
⭐⭐⭐ |
容器化应用场景 |
1. 微服务部署 2. CI/CD流水线 3. 测试环境快速搭建 4. PaaS平台构建 |
微服务治理与容器化天然契合 |
⭐⭐⭐⭐ |
资源利用率优化 |
虚拟机:单机运行多应用→环境混乱 容器:进程级隔离+动态资源分配 |
联合文件系统实现高效磁盘利用 |
⭐⭐⭐⭐ |
技术演进路径 |
物理机→虚拟机→容器→Serverless |
虚拟化粒度持续细化(硬件→OS→进程) |
⭐⭐⭐ |