> “写代码一分钟，写 Commit Message 两行泪”  
> —— 一位被历史代码支配的程序员



## 为什么要在意 Commit Message ?

想象一下，你正调试一个项目，`git log` 滚动出来的全是这样的信息: 

```

fix bug
update
123
final_final_really_final

```

是不是感觉灵魂受到了暴击? 半年后的你，根本不知道自己当时修了啥 bug，更别提帮别人 review 代码了

Commit Message 就像项目的“日记”，写好它，团队能心有灵犀；写烂它，未来的自己会哭晕在厕所

---

## 一点规范，大大不同

业界其实早有共识，最常见的就是 **Conventional Commits 规范**

它给 Commit Message 设计了一套语法，简单又高效:

```

<type>(<scope>): <subject>

```

例如: 

```

feat(auth): 新增用户登录功能
fix(api): 修复分页接口返回条数错误
docs(readme): 更新使用文档示例

```

这样一眼扫过去，就能知道每个提交是 **新增功能、修 bug、写文档**，还是别的

---

## 常见的 type 类型

- **feat**：新功能
- **fix**：修 bug
- **docs**：文档修改
- **style**：代码格式 (空格、缩进、分号之类，不影响逻辑)
- **refactor**：代码重构 (既不是修 bug，也不是加功能)
- **test**：增加或修改测试
- **chore**：杂项，比如构建流程、依赖管理
- **perf**：性能优化
- **ci**：持续集成相关改动

---

## 为什么要这样？

- **可读性强**：几百个 commit 里，你能迅速找到关键信息
- **自动化友好**：很多工具能根据规范生成 **更新日志 (CHANGELOG)**，甚至触发自动发版
- **团队更和谐**：写清楚做了什么，review 更快，不用互相猜谜
- **利于新人上手**：新人看日志就能快速理解项目演进，不需要到处问

---

## 写得更优雅的小技巧

- **一句话说重点**：不要写“修复问题”，要写“修复分页接口返回数量错误”
- **不要带情绪**：什么“终于搞定了啊啊啊啊”——半年后看只会笑不出来
- **正文可以展开**：第一行简明扼要，必要时换行写详细说明
- **多用英文关键词，正文随意**：`type(scope)` 建议用英文，描述可以中英文结合

---

## 工具加持，让规范变习惯

- **Commitlint**  
  自动校验 commit 格式，不合格直接拦下

- **Husky**  
  Git hooks 工具，可以在 `git commit` 前强制执行校验，让团队所有人都守规范

- **Commitizen (cz-cli)**  
  交互式输入 commit message，手把手帮你填，完全不用担心格式

- **changelog 工具**  
  例如 [standard-version](https://github.com/conventional-changelog/standard-version)，可以根据 commit 自动生成更新日志

---

## 结语

程序员的世界里，代码会老去，Bug 会重生，但 commit log 会一直陪你
所以，下次提交的时候，别再敷衍了事，让你的 commit 规范起来吧

**毕竟：Commit 不规范，队友两行泪；Message 写得好，自己少烦恼。**

让你的 Git Commit Message 优雅起来

微服务架构是一种将应用拆分为多个独立服务的设计模式，每个服务负责单一功能，独立部署与扩展

本章将介绍如何使用 Docker 构建微服务架构，实现模块化部署、服务隔离与高可用性



---

## 什么是微服务架构

微服务架构的核心理念：

- 每个服务专注于单一业务功能
- 服务之间通过网络通信（如 HTTP、gRPC）
- 每个服务可独立部署、扩展与维护
- 技术栈可异构（不同服务使用不同语言或框架）

---

## Docker 与微服务的天然契合

Docker 提供了微服务架构所需的基础能力：

- 每个服务运行在独立容器中，互不干扰
- 使用 Compose 或 Swarm 编排多个服务
- 快速构建与部署，适合 CI/CD 流程
- 支持服务发现与网络隔离

---

## 微服务架构示例

假设我们构建一个电商系统，包含以下服务：

- `frontend`：用户界面
- `product-service`：商品管理
- `order-service`：订单处理
- `user-service`：用户管理
- `gateway`：统一入口与路由
- `db`：数据库服务

---

## 使用 Docker Compose 构建微服务栈

```yaml
version: '3.8'
services:
  gateway:
    image: yourname/gateway
    ports:
      - "8080:8080"
    depends_on:
      - frontend
      - product
      - order
      - user
    networks:
      - backend

  frontend:
    image: yourname/frontend
    networks:
      - backend

  product:
    image: yourname/product-service
    networks:
      - backend

  order:
    image: yourname/order-service
    networks:
      - backend

  user:
    image: yourname/user-service
    networks:
      - backend

  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - dbdata:/var/lib/postgresql/data
    networks:
      - backend

volumes:
  dbdata:

networks:
  backend:
```

---

## 服务通信与路由

- 所有服务连接到同一个网络 `backend`
- 可通过服务名称进行 DNS 解析（如 `http://product:3000`）
- `gateway` 负责统一入口与路由转发，可使用 Nginx 或 API Gateway 实现

---

## 微服务的部署策略

- 每个服务独立构建镜像，版本可控
- 使用标签区分环境（如 `v1.0-dev`, `v1.0-prod`）
- 可使用 Swarm 或 Kubernetes 实现弹性伸缩与故障恢复

---

## 微服务的挑战与建议

| 问题 | 建议 |
|------|------|
| 服务间通信复杂 | 使用 API Gateway 或服务网格 |
| 数据一致性难 | 采用事件驱动架构或 Saga 模式 |
| 部署频率高 | 引入 CI/CD 流水线 |
| 日志分散 | 使用集中式日志系统（如 ELK、Prometheus） |

---

## 总结

Docker 为微服务架构提供了理想的运行环境

通过容器化部署、网络隔离与服务编排，你可以构建出高可用、易扩展的分布式系统

Docker入门系列 (12) - Docker 微服务架构实践

在实际部署中，我们常常希望容器能够像系统服务一样运行：自动启动、守护运行、统一管理

本章将介绍如何将 Docker 容器与系统服务（如 systemd）集成，实现容器的后台运行、开机自启与日志管理



---

## 为什么要集成系统服务

虽然 Docker 本身支持后台运行（`-d` 参数），但在生产环境中，使用系统服务管理容器具有以下优势：

- 容器随系统启动自动运行
- 容器崩溃后自动重启
- 与其他服务统一管理（如 Nginx、PostgreSQL）
- 支持日志收集与权限控制

---

## 使用 systemd 管理容器

### 创建 systemd 服务文件

路径：`/etc/systemd/system/myapp.service`

```ini
[Unit]
Description=My Docker App
After=docker.service
Requires=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run --rm -p 8080:80 --name myapp yourname/myapp
ExecStop=/usr/bin/docker stop myapp

[Install]
WantedBy=multi-user.target
```

说明：

- `ExecStart`：容器启动命令
- `ExecStop`：容器停止命令
- `Restart=always`：容器异常退出后自动重启

---

### 启动与管理服务

```bash
sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl enable myapp
sudo systemctl start myapp
```

查看状态：

```bash
sudo systemctl status myapp
```

停止服务：

```bash
sudo systemctl stop myapp
```

---

## 使用 Docker restart 策略

无需 systemd，也可通过 Docker 自带的重启策略实现守护运行：

```bash
docker run -d --restart=always yourname/myapp
```

可选策略：

- `no`：默认，不自动重启
- `on-failure`：仅在非 0 状态退出时重启
- `always`：始终重启
- `unless-stopped`：除非手动停止，否则始终重启

---

## 日志管理建议

- 使用 `docker logs` 查看容器日志
- 将日志输出重定向到文件或日志系统（如 journald、ELK）
- 在 systemd 中添加日志限制：

```ini
StandardOutput=journal
StandardError=journal
```

---

## 与 Supervisor 集成（可选）

除了 systemd，还可以使用 Supervisor 管理容器进程：

```ini
[program:myapp]
command=docker run --rm -p 8080:80 yourname/myapp
autostart=true
autorestart=true
stderr_logfile=/var/log/myapp.err.log
stdout_logfile=/var/log/myapp.out.log
```

---

## 总结

将 Docker 容器与系统服务集成，可以提升部署的稳定性与可维护性

无论是使用 systemd、Supervisor 还是 Docker 自带的重启策略，都能实现容器的自动运行与统一管

Docker入门系列 (11) - Docker 与系统服务集成

镜像是容器的基础，而镜像仓库则是容器生态的核心枢纽

本章将介绍 Docker Registry 的使用方式，包括官方仓库 Docker Hub、自建私有仓库，以及镜像的推送、拉取与版本管理，帮助你构建安全、高效的镜像分发体系



---

## 什么是 Docker Registry

Docker Registry 是用于存储和分发 Docker 镜像的服务。常见类型包括：

- **Docker Hub**：Docker 官方公共仓库，支持公开与私有镜像
- **Harbor**：企业级私有仓库，支持权限控制与镜像扫描
- **自建 Registry**：使用官方 `registry` 镜像快速部署本地仓库

---

## 镜像的命名规范

镜像名称格式：

```
[仓库地址]/[用户名或组织]/[镜像名]:[标签]
```

示例：

```
nginx:latest
yourname/myapp:v1.0
registry.example.com/backend/api:v2
```

---

## 登录与认证

登录 Docker Hub：

```bash
docker login
```

登录私有仓库：

```bash
docker login registry.example.com
```

退出登录：

```bash
docker logout
```

---

## 镜像推送与拉取

推送镜像到远程仓库：

```bash
docker tag myapp yourname/myapp:v1.0
docker push yourname/myapp:v1.0
```

拉取镜像：

```bash
docker pull yourname/myapp:v1.0
```

查看本地镜像：

```bash
docker images
```

---

## 自建私有 Registry

快速部署：

```bash
docker run -d -p 5000:5000 --name registry registry:2
```

推送镜像到本地仓库：

```bash
docker tag myapp localhost:5000/myapp
docker push localhost:5000/myapp
```

拉取镜像：

```bash
docker pull localhost:5000/myapp
```

---

## Harbor 简介

Harbor 是一个企业级镜像仓库，支持：

- 用户与角色权限管理
- 镜像签名与漏洞扫描
- LDAP/AD 集成
- Web UI 与 API 支持

部署方式：

- 使用 Helm 安装到 Kubernetes
- 使用 Docker Compose 本地部署

---

## 镜像版本管理建议

- 使用语义化版本号（如 `v1.0.0`）
- 避免使用 `latest` 标签部署生产环境
- 定期清理过期镜像，节省存储空间
- 使用标签策略区分环境（如 `dev`, `staging`, `prod`）

---

## 总结

镜像仓库是容器化部署的基础设施之一

通过合理使用 Docker Hub、自建 Registry 或 Harbor，你可以实现镜像的集中管理、安全分发与版本控制

Docker入门系列 (10) - Docker Registry 镜像仓库管理

容器是临时的，但数据不是

本章将深入讲解 Docker 的数据管理机制，重点介绍 Volume（数据卷）的使用方式、挂载策略与最佳实践，帮助你实现容器间的数据共享与持久化存储



---

## 为什么需要数据卷

默认情况下，容器中的数据会随着容器销毁而丢失

为了解决数据持久化与共享问题，Docker 提供了三种挂载方式：

- **Volume**：由 Docker 管理的挂载点，推荐使用
- **Bind Mount**：将宿主机目录挂载到容器中，灵活但不隔离
- **tmpfs**：将数据存储在内存中，适用于敏感或临时数据

---

## 使用 Volume 的基本方式

创建数据卷：

```bash
docker volume create mydata
```

查看卷列表：

```bash
docker volume ls
```

挂载卷到容器：

```bash
docker run -d -v mydata:/app/data nginx
```

容器中的 `/app/data` 目录将映射到 `mydata` 卷中

---

## Bind Mount 示例

将宿主机目录挂载到容器：

```bash
docker run -d -v /home/user/config:/etc/nginx nginx
```

适用于配置文件、日志文件等需要直接访问的场景

---

## tmpfs 示例

将数据存储在内存中：

```bash
docker run -d --tmpfs /app/cache nginx
```

适用于缓存、会话等不需要持久化的数据

---

## Volume 与 Compose 集成

在 `docker-compose.yml` 中定义卷：

```yaml
version: '3.8'
services:
  db:
    image: postgres
    volumes:
      - dbdata:/var/lib/postgresql/data

volumes:
  dbdata:
```

Compose 会自动创建并挂载 `dbdata` 卷，实现数据库持久化

---

## 查看与清理卷

查看卷详情：

```bash
docker volume inspect mydata
```

删除未使用的卷：

```bash
docker volume prune
```

删除指定卷：

```bash
docker volume rm mydata
```

---

## 最佳实践

- 使用 Volume 而非 Bind Mount 进行持久化，避免宿主机依赖
- 将数据卷与容器生命周期解耦，提升可维护性
- 定期备份数据卷内容，防止数据丢失
- 对敏感数据使用加密挂载或专用存储插件

---

## 总结

数据卷是容器化部署中不可或缺的一部分

通过合理使用 Volume、Bind Mount 与 tmpfs，你可以实现数据的持久化、共享与隔离