企业官网建设流程全解析

简介：一份名为《Docker和微服务技术的崛起》的入门文档，面向软件开发者、运维人员以及云原生技术爱好者，系统梳理了IT基础设施从硬件虚拟化到容器化的演进过程。文档以SOA（面向服务架构）为起点，分析了单体架构在扩展性、维护性方面的痛点，进而引出微服务架构的核心思想，并重点讲解Docker如何通过容器化封装微服务，以及Kubernetes在服务编排、负载均衡、容错恢复中的重要作用。文中配有架构示意图和关键概念对照图，直观展示不同模式下的服务关系，可帮助读者快速理解微服务拆分、容器隔离、水平扩展等核心知识。资源为单个docx文档，压缩包仅112KB，下载后即可用常见办公软件打开阅读。目前已有120人学习浏览，适合希望建立现代应用开发知识体系的技术人员，作为轻量级入门参考。

1. Docker与微服务技术的崛起：容器解决了微服务部署的什么问题

一个大版本迭代后，测试环境里20个微服务要重新部署，最耗时的不是改代码，而是安装各自依赖的JDK、Python、Redis客户端和动态链接库。开发配好了环境，测试机器又对不上，最后只能甩一句“在我机器上能跑”。Docker和微服务技术的崛起，本质上是用镜像把“环境”变成可携带、可校验的构建产物，让容器的资源隔离和秒级启动支撑起微服务的独立发布。

容器不是虚拟机，它共享宿主机内核却拥有独立的文件系统、网络和进程命名空间。一台8C16G的机器，单靠虚拟机只能起几个实例，用Docker可以同时跑上百个轻量容器，这也让微服务按需扩容成为可能。下面从安装、编排、排错到镜像瘦身，直接给出可复现的命令和参数。

2. Docker安装与核心操作：从零跑通本地容器环境

2.1 Linux和Docker Desktop的安装命令与前提条件

Linux上安装Docker，常见做法是配置官方或云厂商的Docker CE源，再安装docker-ce、docker-ce-cli和containerd.io。以Ubuntu 22.04为例：

sudo apt-get update sudo apt-get install -y ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io sudo systemctl enable --now docker

这段命令先安装证书和gnupg，用--dearmor把GPG密钥转成keyring；signed-by指定密钥路径，规避apt-key已废弃的告警。发行版代号从/etc/os-release动态读取，不需要额外安装lsb-release。enable --now同时完成启动和开机自启。安装完成后执行docker --version，能看到Docker version开头的版本号输出。CentOS或RHEL用户把仓库文件换成https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo，再yum install -y docker-ce docker-ce-cli containerd.io即可；注意CentOS 7的旧内核需要额外安装container-selinux。

Windows和macOS一般用Docker Desktop安装包，Windows下依赖WSL2。启动失败最常见的报错是Virtualization support not detected，需要先到BIOS打开Intel VT-x或AMD SVM Mode，然后在“Windows功能”里勾选“虚拟机平台”和“适用于Linux的Windows子系统”。macOS要求4GB以上内存和硬件虚拟化，安装后首次启动需要授权管理员权限。如果内网环境无法联网，离线安装可以先在有网机器下载对应版本的Docker Engine二进制包或Docker Desktop安装器，再通过U盘拷入内网，但要注意内核版本和glibc兼容性。

2.2 镜像、容器、仓库：三个核心对象与常用命令

微服务镜像的传递依赖仓库，容器是镜像的运行实例。镜像是模板，容器是模板创建出的隔离进程，仓库是存放模板的中央位置。docker pull从仓库拉取，docker build生成本地镜像，docker run启动容器。常用命令如下：

执行docker run时，Docker先检查本地是否有镜像，没有则从仓库拉取，再创建可写层并启动进程。两个容易踩的坑：-d后容器立刻退出，多半是前台进程没启动，立即docker logs看原因；-p端口冲突时改映射到别的端口，或先docker ps找出占用容器的id再处理。这里也会遇到docker权限错误，典型症状是每次都要加sudo，解决办法放到第4章，因为它和daemon权限强相关，单独处理更容易定位。

2.3 用Dockerfile构建一个微服务镜像

以Node.js写的用户服务为例，项目里必须提交package-lock.json，然后在根目录写Dockerfile：

FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY src ./src ENV NODE_ENV=production EXPOSE 3000 USER node CMD ["node", "src/server.js"]

构建并启动：

docker build -t user-service:1.0.0 . docker run -d --name user-service -p 8080:3000 user-service:1.0.0 curl http://localhost:8080/health

node:18-alpine比node:18小一半以上，但缺少部分原生库，遇到node-gyp编译失败时改回slim版本。COPY package*.json单独放在RUN npm ci之前，是为了利用构建缓存：只有依赖变化时才重跑npm ci，源码改动不会重新下载依赖。USER node避免以root运行进程，降低容器被攻破后的提权风险。EXPOSE 3000只是声明，真正对外暴露端口靠docker run -p。很多IDE也提供“右键打包Docker镜像”的入口，比如IDEA的Docker插件会自动生成临时Dockerfile，但CI流水线里更建议直接执行docker build，保证参数和基础镜像版本可控。

3. 用Docker Compose编排微服务依赖：网络、健康检查与私有仓库

3.1 为什么单机编排离不开docker compose

微服务项目拆开后，本地至少需要API服务、MySQL、Redis，有时还有消息队列。手动执行多个docker run，端口、数据卷、网络和启动顺序全凭记忆，换个人就重演一遍依赖安装的混乱。常见做法是使用docker compose把这些声明在一个YAML中，一条docker compose up -d拉起全部服务。

docker compose解决的问题是单机多容器编排，Kubernetes解决跨主机集群调度。很多团队先拿Compose在开发机复现生产拓扑，再转换到Kubernetes清单，这也是Compose能成为微服务技术里最常见过渡工具的原因。Compose内的服务默认在同一个自定义网络，服务之间直接用服务名当主机名，不需要关心容器IP，这比一堆docker run --link干净得多。

3.2 一个用户服务加MySQL和Redis的最小compose文件

在项目根目录放docker-compose.yml：

services: db: image: mysql:8.0 container_name: order-db environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: order_db ports: - "3306:3306" volumes: - db_data:/var/lib/mysql command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-proot123"] interval: 5s timeout: 3s retries: 10 redis: image: redis:7-alpine ports: - "6379:6379" volumes: - redis_data:/data command: ["redis-server", "--appendonly", "yes"] user-service: build: ./user-service ports: - "8080:3000" environment: - DB_HOST=db - REDIS_HOST=redis depends_on: db: condition: service_healthy redis: condition: service_started volumes: db_data: redis_data:

启动命令为docker compose up -d，状态查看用docker compose ps，日志用docker compose logs -f user-service。这个示例使用了Docker Compose v2，注意depends_on下的condition在旧版docker-composev1里不支持，直接用会报配置错误。depends_on只保证启动顺序，并不能保证服务真正就绪，所以db加healthcheck，mysqladmin ping成功后user-service才启动；redis是service_started，意味着容器一进入运行态就继续。DB_HOST=db和REDIS_HOST=redis是Compose网络自动解析的服务名，应用代码不需要写死IP。command里的--character-set-server=utf8mb4是MySQL 8推荐的编码配置，避免中文乱码。如果同一套编排里还有另一个Redis，要做主从的话，从节点启动命令直接写redis-server --replicaof redis 6379。

常用子命令如下表：

3.3 配置私有仓库与镜像源，解决镜像拉取慢

开发阶段用Docker Hub没问题，生产环境微服务镜像通常放到私有仓库。自建仓库最简单的是跑一个registry容器：

docker run -d -p 5000:5000 --name registry -v /opt/registry:/var/lib/registry registry:2 docker tag user-service:1.0.0 192.168.1.10:5000/user-service:1.0.0 docker push 192.168.1.10:5000/user-service:1.0.0

其它机器拉取时，内网HTTP仓库需要在/etc/docker/daemon.json中声明insecure-registries；镜像拉取慢也常见，配置registry-mirrors指向云厂商提供的专属镜像源：

{ "registry-mirrors": ["https://<your-mirror-id>.mirror.aliyuncs.com"], "insecure-registries": ["192.168.1.10:5000"] }

保存后执行sudo systemctl restart docker。registry-mirrors只对Docker Hub生效，私有仓库和第三方仓库还是直连。不要使用来历不明的公共加速地址，防止镜像被篡改或内容过期。团队规模超过几十人后，registry自带的扁平目录没有权限管理和界面，常见做法是部署Harbor作为私有仓库；Harbor支持项目隔离、LDAP和漏洞扫描，本身也是一套微服务。如果只是内部小团队，直接跑registry:2更省事，重点是把docker push权限收敛到CI，避免开发机手动推送绕过扫描。

4. 微服务生产排错：Docker启动失败、权限异常与资源控制

4.1 Docker服务启动失败与Virtualization Support Not Detected

Docker Desktop在Windows上启动失败时，如果弹窗写着Docker Desktop failed to start because virtualization support wasn't detected，先打开任务管理器，性能页面看虚拟化是否“已启用”。如果没有，重启进BIOS把Intel Virtualization Technology或AMD SVM Mode设为Enabled，保存退出。回到Windows后，在“启用或关闭Windows功能”中勾选“虚拟机平台”和“适用于Linux的Windows子系统”，再执行：

wsl --set-default-version 2 wsl --shutdown

Linux上docker服务启动失败多数和containerd或iptables相关。先看状态和日志：

systemctl status docker --no-pager -l journalctl -u docker --no-pager -n 80

如果看到提示failed to start daemon: Devices cgroup isn't mounted，老内核需要重新挂载cgroup，现代发行版通常不会出现；如果错误指向iptables，执行systemctl restart containerd后清理/var/lib/docker里的残留锁文件再启动。另一个隐藏原因是磁盘写满，df -h /var/lib/docker确认可用空间，镜像和日志堆积都会撑爆分区。

4.2 Failed to connect to the Docker API：权限与daemon异常

Windows端出现failed to connect to the docker api at npipe:////./pipe/dockerDesktopLinuxEngine，本质是Docker Desktop的Linux后端没有启动，或客户端与引擎的命名管道没有就绪。确认托盘图标没有停留在“Docker Desktop正在启动”，仍未解决就重启Docker Desktop，或者执行wsl --shutdown后重新打开。升级Docker Desktop后出现该问题，卸载并清空%AppData%\Docker目录再重装。

Linux上的等价报错是Cannot connect to the Docker daemon at unix:///var/run/docker.sock。先确认daemon是否启动，再判断是不是docker权限错误。让当前用户免sudo进入docker组：

sudo groupadd docker 2>/dev/null || true sudo usermod -aG docker $USER newgrp docker

newgrp docker只对当前会话生效，重新登录后长期有效。执行docker run hello-world验证，能拉取并运行就说明权限已生效。

注意：docker组权限等同于root，能操作Docker就能挂载宿主机目录并运行特权容器，生产服务器上不要随意添加用户，必要时用Rootless模式。

4.3 给微服务设置资源限制与日志轮转

容器默认不受CPU和内存限制，多个微服务共享一台机器时，某个服务内存泄漏会拖垮全部进程。常见做法是启动时显式限定：

docker run -d --name user-service \ --cpus=1.0 \ --memory=512m \ --memory-swap=1g \ --pids-limit=128 \ --log-opt max-size=10m \ --log-opt max-file=3 \ -p 8080:3000 user-service:1.0.0

参数含义如下表：

在docker-compose.yml里对应的写法是deploy.resources.limits.cpus和memory，但deploy字段在Swarm模式和普通docker compose up之间一直有兼容性坑：旧版docker-compose需要--compatibility才生效，某些Compose v2版本在单机模式也会直接忽略。所以单机部署不要依赖Compose里的deploy字段做资源限制，把服务启动参数收敛到启动脚本或Makefile，docker run的--memory和--cpus是最可靠的。观察是否生效，用docker stats --no-stream看实时CPU和内存，然后docker inspect <id> | grep -A6 Memory确认限制写入。容器反复退出时，先看docker inspect <id>里的OOMKilled字段，是true说明内存不足，优先调大资源而不是只查业务日志。

5. 进阶：用Docker多阶段构建压缩微服务镜像的实战参数

5.1 构建阶段与运行阶段分离

单阶段构建Java微服务时，JDK、Maven依赖、编译中间文件全塞进镜像，体积动辄1GB。多阶段构建把编译和打包拆成两个阶段，最终镜像只保留JAR和运行时。以Spring Boot服务为例：

FROM maven:3.9-eclipse-temurin-17 AS build WORKDIR /build COPY pom.xml . RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests -Dmaven.test.skip=true FROM eclipse-temurin:17-jre-alpine RUN addgroup -S app && adduser -S app -G app WORKDIR /app COPY --from=build /build/target/order-service-*.jar app.jar USER app ENV JAVA_OPTS="-XX:MaxRAMPercentage=75.0 -Xss512k" EXPOSE 8080 ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

FROM maven:3.9-eclipse-temurin-17 AS build为构建阶段命名，后面COPY --from=build只拷贝JAR包，省去JDK、Maven本地仓库和编译中间文件。eclipse-temurin:17-jre-alpine只带JRE，alpine进一步压缩体积。addgroup和adduser创建非root用户，避免容器主进程是root。JAVA_OPTS里的-XX:MaxRAMPercentage=75.0很关键：JVM默认堆上限是物理内存的四分之一，容器限制512m时，这个参数让堆按容器限额的75%自动调整，不会因为固定-Xmx过大导致OOMKill。构建后执行docker images | grep order-service，通常能从1GB降到250MB以内。项目根目录的.dockerignore也要补上：

.git target .idea *.iml Dockerfile .dockerignore

否则docker build会把整个项目目录发给daemon，构建上下文可能几百MB，拉低打包速度。

5.2 镜像瘦身的三个检查点

先看层大小，docker history <image>输出每一层的创建命令和占用空间，发现某层异常大就回看Dockerfile对应的RUN，比如RUN npm install后存在/tmp缓存，应该在同一条命令里清理。再看基础镜像标签，node:18-alpine和node:18相差几百MB，能选slim或alpine就别用全量版。最后看缓存顺序，把COPY pom.xml和RUN mvn dependency:go-offline放在COPY src前面，保证源码变更后依赖层仍可复用。

验证瘦身后的镜像是否可用：先docker run --rm -it <image> /bin/sh进入容器，检查工作目录和启动脚本权限，再正常启动容器并请求健康检查接口。生产CD阶段接入trivy image <image>做静态漏洞扫描，高危漏洞直接让流水线失败；这一步放在推送私有仓库之前，多阶段构建的镜像瘦身效果才真正落到交付流程里。

本文还有配套的精品资源，点击获取