序言

  在容器化技术迅速普及的今天，应用架构早已从单体走向微服务，随之而来的，是数量不断增长的容器实例与更加复杂的部署组合。对于开发和运维团队而言，单靠手动方式去创建、启动、管理这些容器，已经变成一件低效且极易出错的工作。

  Docker Compose 正是在这样的背景下诞生。它以一个简洁的 YAML 文件，将复杂的多容器应用抽象成“可定义、可复用、可一键启动”的工程，使开发者能够在本地快速搭建完整的服务环境，让运维人员轻松管理多实例部署。通过它，我们可以避免重复繁琐的命令操作，更能像管理一个整体项目一样描述和控制成百上千个容器。

  本篇文章将从 Compose 的基础概念、安装方式、常用命令到网络机制、外部容器链接方式等多个角度进行全面梳理，让你在理解 Compose 核心理念的同时，也能掌握实际使用中的细节与技巧，为构建稳定、灵活的容器化环境提供坚实基础。

2020-06-12 注：部分图片需要重画及排版

前言

  阅读此文之前，应首先阅读初识 Zookeeper 一文中什么是分布式协调服务？及分布式锁两小节。

什么是容器？

• 一种虚拟化的方案
• 操作系统级别的虚拟化
• 只能运行相同或相似内核的操作系统
• 依赖于 Linux 内核特性：Namespace 和 Cgroups

序言

前言

  在传统的单体应用中，所有用户请求都由同一台服务器处理，会话（Session）信息通常保存在服务器内存中即可。
  客户端第一次登录后，服务端会创建一个 Session 并生成 SessionId，保存在服务端内存中，同时将 SessionId 通过 Cookie 返回给客户端。之后客户端的每次请求都会携带该 SessionId，服务端即可识别用户的登录状态。

  然而，随着业务规模扩大和访问量增加，单台服务器已无法承受高并发请求，我们往往会采用 Nginx + 多台应用服务器 的负载均衡方式进行水平扩展。
  此时，Session 共享问题便随之出现。

序言

  随着技术的不断发展，为了使用户拥有更好的体验，许多网站在登陆界面额外提供了使用手机验证码的登陆方式。
  该功能基本使用 Redis 数据库实现，不仅能提高效率，还可以减少维护量。
  下面我们通过一个简单的例子来了解一下 Redis 是怎么实现这种功能的。

序言

  当主机宕机后出现故障后无法及时恢复，可以在从机执行slave no one命令使其上位变为主机，但是，这样的人工操作带来一个问题，难道半夜主机宕机还要通知运维起来输命令吗？
  这显然不符合常理，为了自动化管理这个过程，Redis 引入了哨兵机制。