docker概述 - 技术栈

1 概述

1.1 技术的演进

1.1.1 业务驱动技术演进

技术的演进由业务需求驱动，不同阶段的业务场景催生了对应的技术方案：

门户网站阶段（如高校官网）：业务简单、用户量少、并发低，技术采用 Servlet + JSP，用于构建静态页面类应用。
电商初期（PC 端淘宝、京东）：业务复杂度提升，技术采用 PHP，因其开发简单适配当时需求。
复杂业务与敏捷开发阶段：Java 技术栈崛起，依托 Spring 全家桶、Spring MVC 实现敏捷开发，高效支撑复杂功能研发。
移动互联网与三高架构阶段：移动应用普及、网民激增，需应对高并发、高可用、高性能需求，技术演进到微服务架构。
微服务时代的部署需求：上千个服务的部署、上线、更新推动了 Docker 技术的爆发式应用。
注：微服务概念（类比理解）

初始状态：一个 "厨师" 负责洗菜、切菜、炒菜、端盘子等所有工作（单体应用）。
集群阶段：业务增长后，多个 "厨师" 干同样的全流程工作（集群部署，提升吞吐量）。
微服务阶段：业务进一步增长，将工作拆分 ------ 专人洗菜、专人切菜、专人炒菜、专人端盘子（将单体应用拆分为多个职责单一的服务，即微服务）。

1.1.2 部署方式的演进

软件开发中应用部署方式随技术发展不断迭代：

人工部署阶段

操作方式：开发者手动打包代码、拷贝到服务器，安装依赖库、配置环境、启动服务。
典型问题：环境不一致，相同代码在不同服务器运行结果不同，系统管理员需反复调试版本、依赖与配置。

虚拟机（Virtual Machine）阶段

技术原理：通过 Hypervisor 在物理机上创建多个隔离的系统实例，每个虚拟机拥有独立的操作系统、内存、磁盘空间。
优势：提高资源利用率，系统隔离更安全。
问题：启动慢、占用资源大。

容器（Container）阶段

技术原理：不复用整个操作系统，直接复用宿主机内核，封装轻量级、独立的运行环境，仅包含应用代码与运行时依赖。
优势：启动 "瞬时" 完成，体积仅几十 MB。
核心区别：虚拟机关注 "硬件的虚拟化"，容器关注 "应用的虚拟化"。

1.2 容器技术

容器技术的核心在于统一开发、测试、部署三个环节。

传统开发流程痛点：开发者常因环境差异与运维争执，出现 "我在我电脑上能跑啊！" 的困境。
容器的解决思路：将运行环境和应用打包在一起，从代码提交到生产运行，所有人运行的都是同一个镜像。镜像可以看作是使用容器技术打包的静态产物。它包含了应用运行所需的所有内容（代码、依赖、环境配置等），是创建容器的 "模板"。
核心理念：一次构建，随处运行（Build Once, Run Anywhere），类比手机应用的 APK 安装包，只要环境兼容即可通用运行。

1.4 docker是什么

Docker 是容器技术的一种具体实现（容器引擎、实现容器技术的工具）。
容器技术是一种技术概念（类似 "虚拟化" 的概念），核心是通过操作系统级虚拟化（如 Linux 的 Namespace、Cgroups 技术）实现进程隔离，让应用及其依赖在独立环境中运行，解决 "环境不一致" 问题。
而 Docker 是目前最流行的容器化工具，它让容器技术的使用变得简单，用于解决传统部署的环境不一致、批量管理难等问题。它简化了容器的创建、管理、分发流程，让普通用户能轻松使用容器技术。
容器技术在 Docker 出现之前就已经存在（例如 LXC 等早期容器技术），但 Docker 对容器技术进行了简化、标准化和生态化。
微服务时代下，上千个服务的部署、上线、更新需求，让 Docker（docker技术本身在微服务时代之前就已存在）凭借易用性、标准化的镜像与仓库体系等优势迅速普及，成为容器技术的主流实现，并不是 Docker 因微服务需求 "全新产生"，而是微服务的业务需求推动了 Docker 技术的爆发式应用。
Docker 容器和 Docker 镜像

Docker 容器：是基于 Docker 镜像，通过 Docker 技术（Docker 引擎）启动的容器实例。它是 Docker 工具对 "容器" 这一技术概念的具体实现，具备容器的进程隔离、环境独立等特性，是镜像的可运行副本。
Docker 镜像：是 Docker 生态中对 "镜像" 概念的实现，是包含应用及依赖的只读模板，供 Docker 容器启动时使用。
简单来说，"Docker 容器" 是 Docker 工具按照 "容器" 技术标准运行起来的实例；"Docker 镜像" 是 Docker 生态里的镜像格式，用于创建 Docker 容器。

1.3 docker解决的问题

传统部署方式的问题
传统部署如 "上传 jar 包后 java -jar 启动""部署 Tomcat 并放入 war 包"，在微服务场景下暴露以下问题：

批量服务部署更新难：上百个服务需部署更新时，无法高效批量操作，手动重复上传效率极低。
服务隔离性差：多个服务部署在同一环境时，易相互影响，无法实现 "互不干扰" 的隔离需求。
大规模服务器管理复杂：面对 1000 台服务器，传统方式难以高效管理和连接。

对于此，Docker 可完美解决上述三个传统部署问题，支撑微服务时代成百上千个服务的部署、上线、更新。
技术与业务的关系：Docker 并非为微服务场景 "量身定制" 后才出现，而是先有 Docker 技术，后因它能满足微服务业务需求才得以普及（类似 AI 技术因硬件、数据条件成熟而爆发，Java 因适配敏捷开发需求而流行）。

1.7 Docker 核心组件（三个概念）

Docker Client（客户端）
是我们在命令行中输入 docker 命令的交互入口，可类比用于操作的 "网站界面"，用于向 Docker 系统发送管理命令。
Docker Daemon（守护进程）
是真正执行容器管理任务的后台服务，相当于 Docker 的 "服务端 / 后台"，负责处理 Client 发送的命令。
Docker Registry（镜像仓库）
用于存储和分发容器镜像，类比应用商店或 Git 仓库，典型例子是 Docker Hub，里面存放着如 mysql、redis 等各类应用的 Docker 镜像。

1.8 Docker 工作原理

用户通过 Client 发送命令给 Daemon，Daemon 根据命令从 Registry 拉取镜像，并在宿主机上创建容器。
示例：执行 docker run nginx 命令时，Docker 会自动从 Registry（通常是 Docker Hub）下载 nginx 镜像，然后启动一个运行 Nginx 服务的容器实例。

1.9 镜像与容器的关系

镜像（Image）：是 "静态模板"，包含应用及其运行环境，可类比手机上的应用安装包，从 Docker Hub 下载获取。
容器（Container）：是镜像的 "动态实例"，是镜像被运行起来的结果。例如 Redis 镜像运行后，就会基于 Redis 镜像，创建并运行一个 Redis 容器。
类比理解：

镜像是 "类"，容器是 "对象"；
镜像是蓝图，容器是实物。

创建逻辑：每次执行 docker run 命令，都是基于某个镜像创建一个新的容器实例。核心就是 "模板→实例" 的创建逻辑，和 Java 中 "类→对象" 的逻辑本质一致：
具体解释如下：
1.先明确对应关系：

Redis 镜像 = Java 中的 "类（Class）"：是静态的、只读的 "模板"，里面包含了 Redis 程序本身、运行 Redis 所需的依赖库、配置文件等所有 "基础素材"，就像类中定义的属性和方法。
Redis 容器 = Java 中的 "对象（Object）"：是通过 "模板" 创建出来的 "动态实例"，会占用宿主机的内存、CPU 等资源，能实际提供 Redis 服务（比如存储数据、响应请求），就像通过new 类名()创建的对象，开辟了内存空间，能执行类中定义的逻辑。
2.具体过程（对应 Java 的创建逻辑）：
第一步：你先从 Docker 仓库（类似 Java 的类库）下载 Redis 镜像（类似你编写好的 Java 类文件），此时镜像只是存放在宿主机上的静态文件，不占用运行资源，也不提供服务。
第二步：执行docker run redis命令（类似 Java 中new Redis()），Docker 会基于 Redis 镜像这个 "模板"，在宿主机上创建一个 Redis 容器：
会给容器分配独立的内存空间（类似 Java 对象在堆中开辟内存）；
会加载镜像中的 Redis 程序、依赖库到内存中；
会基于镜像中的配置，初始化 Redis 的运行参数（类似 Java 对象初始化属性值）；
最终启动 Redis 服务，此时容器就是 "正在运行的 Redis 实例"，能对外提供服务（类似 Java 对象调用方法执行功能）。
3.关键补充：
一个 Redis 镜像可以创建多个 Redis 容器（类似一个 Java 类可以new出多个对象）：比如你可以同时启动 3 个 Redis 容器，它们都基于同一个 Redis 镜像创建，但各自有独立的内存空间、数据存储（默认情况下），相互隔离，就像 3 个独立的 Redis 服务。
容器停止后，实例会 "暂停"（类似 Java 对象失去引用前的状态），但镜像这个 "模板" 依然存在，后续可以再次基于它创建新的容器（类似再次new对象）。
4.注
镜像本身是静态、只读的模板，运行命令不会改变镜像本身，更不会让镜像 "变成" 容器 ------ 就像 Java 里的 "类"，执行 new 不会让类本身变成对象，而是基于类创建了新的对象。
容器是独立的动态实例，是 Docker 读取镜像中的内容（程序、依赖、配置），在宿主机上分配资源（内存、CPU）后，新建的运行实体，和原镜像完全是两个不同的 "东西"（一个静态模板，一个动态实例）。
简单说：镜像永远是 "模板"，容器永远是 "基于模板新建的实例"，二者不会相互转化。

1.10 物理机、虚拟化、容器化的区别

物理机和虚拟化和容器化区别

|------|----------------------------------------------------------------------------------------|--------------------------------------------------------------------|
| 技术类型 | 说明 | 示例 |
| 物理机 | 一台独立的硬件设备，资源未做拆分，供单一或少数场景使用。 | 一台配备 128 核 CPU、1.5T 内存、30T 磁盘的服务器（或个人笔记本）。 |
| 虚拟化 | 通过软件（如 KVM、VMware）将物理机资源（CPU、内存、磁盘等）拆分为多个相互独立的 "虚拟电脑"（虚拟机），提升资源利用率。每个虚拟机有自己的操作系统，相互隔离。 | 将一台 64 核、500G 内存、30T 磁盘的物理机，用 KVM 拆分成 100 台 2 核 4G 的独立虚拟服务器，且相互隔离。 |
| 容器化 | 在虚拟化拆分出的虚拟服务器（或物理机）上，运行多个轻量级、隔离的 Docker 容器，进一步优化资源与环境管理。 | 在一台由虚拟化拆分出的 2 核 4G 虚拟服务器上，运行 20 个 Docker 容器。 |

注：

容器化：是在操作系统层面做隔离，不虚拟完整硬件和操作系统，而是复用宿主机的操作系统核心（内核），将应用和其运行环境打包成轻量级的容器。它比虚拟化更轻量，启动快、资源占用少，用于高效管理应用的运行环境。因为复用宿主机内核（容器只带应用和必要环境），相当于 "只装一个软件"，不用启动额外操作系统，所以启动快（秒级）、占内存少（比虚拟机省很多资源）。
电脑 / 服务器的操作系统（比如 Windows、Linux）分成两部分：

「外壳」：就是你能看到的桌面、图标、操作界面，还有各种系统工具（比如文件管理器）；
「内核」：是操作系统的 "核心大脑 + 执行者"，藏在后台，负责管理 CPU、内存、磁盘这些硬件资源，还负责让软件（比如微信、浏览器）能调用这些硬件运行。

虚拟机是通过软件（如 VMware、KVM）在物理机上虚拟出一整套独立的硬件和操作系统。比如你的笔记本电脑（物理机）安装虚拟机后，相当于在电脑里 "复刻" 了另一台独立的 "电脑"，它会占用物理机的内存、CPU 等资源，有自己独立的操作系统（比如物理机是 Windows，虚拟机可以装 Linux）。
虚拟化中的拆分不是硬分配，而是动态共享 + 逻辑隔离，不是把物理资源直接切开分给每台虚拟机，而是让多台虚拟机 "共享使用" 物理资源，同时相互隔离。
具体如下：
为什么 64 核能 "拆" 出 100 台 2 核的虚拟机？

首先明确：虚拟机的 "2 核 CPU""4G 内存" 是逻辑配置，不是物理上把 CPU 芯片切开。
物理机的 64 核 CPU，是 "总资源池"，100 台虚拟机的 "2 核" 是各自的 "最大可使用额度"，但不会同时跑满。
举个例子：就像你家有 1 个水龙头（64 核），100 个人（虚拟机）各拿 1 个杯子（2 核额度）接水，不会 100 个人同时挤在水龙头前，大多时候只有少数人在用水，水龙头的总流量（CPU 总性能）能满足这些人的需求。
同理，100 台 2 核虚拟机的 "总逻辑核数 200 核"，是 "峰值需求总和"，但实际运行中，大部分虚拟机处于低负载状态（比如有的虚拟机只是待机、跑简单程序），64 核的物理 CPU 完全能动态分配、满足它们的实际需求。
内存的 "拆分" 逻辑也一样
物理机 500G 内存，100 台虚拟机每台配置 4G，总逻辑内存 400G，没超过 500G 的物理总量（留了冗余）。
即使总逻辑内存超过物理内存，虚拟化软件也会用 "内存置换" 技术（比如把暂时不用的内存数据存到磁盘），保证虚拟机正常运行（只是性能会受影响，实际配置时会避免这种情况）。
拆分的核心目的：提高资源利用率
如果不拆分，64 核 500G 的物理机只给 1 个用户用，大多时候 CPU、内存都是闲置的（比如你用笔记本时，很少会把 CPU、内存跑满）。
虚拟化拆分后，让多台虚拟机共享这些闲置资源，每台虚拟机都觉得自己在用 "独立的电脑"，但实际是共享物理机的资源，这样物理机的资源就被充分利用了。
简单说：虚拟化的 "拆分" 是 "逻辑上的独立分配 + 物理上的动态共享"，不是硬切硬件，而是通过软件实现资源的高效复用和隔离。

1.11 注

一、容器技术、容器、镜像

要理清这个问题，我们可以从概念的层级和关系来拆分：

容器技术：是一种技术理念和方法，核心是 "将应用与运行环境打包，实现环境一致、轻量隔离"，是一套解决软件部署问题的技术体系。
容器（Container）：是容器技术的产物 / 实例，是镜像运行起来后的 "动态实体"，就像用 "模板（镜像）" 生成的 "具体对象"。
再结合 "镜像" 的概念来看：
镜像是容器技术打包出的静态模板（包含应用 + 环境的所有内容）；
容器是基于这个模板运行起来的动态实例
举个生活中的例子：
「容器技术」好比 ""批量生产蛋糕的工艺"（技术方法）；
「镜像」好比 "蛋糕模具 + 预拌好的蛋糕糊"（静态模板）；
「容器」好比 "用模具烤出来的一个具体蛋糕"（动态实例）。
所以，容器技术是一套方法，容器是该技术产生的实体产物，二者不是同一个概念