为什么要容器化

微服务把单体应用拆分成多个服务后，能够快速迭代开发；但是，因为服务的增多，会导致运维和测试的成本直线升高。为了降低运维、测试成本，一个比较好的选择就是以容器化为基础的一种协作流程 —— DevOps。

DevOps

概念

DevOps 可以简单理解为开发、运维结合，开发者不再只负责写代码，还要负责服务的测试、上线、发布甚至故障处理的整个流程中（怎么感觉开发越来越苦逼了┓( ´∀` )┏），这样的话就可以把运维、测试从繁重的工作中解放出来。

要求

DevOps 要求开发、测试、发布流程完全自动化。做到完全自动化的前提是：开发人员能将自己本地的开发、测试通过的运行环境，能够复制到测试环境中，通过测试后再复制到生产环境。

这个操作看着简单，但其实涉及到系统环境等各种原因，会导致完成难度变的很大。于是，我们需要一种能够隔离环境，并容易迁移的方案。传统的虚拟机能够解决这个问题，但是由于虚拟机存在资源占用大等各种问题，所以并不是很理想；幸运的是，我们已经有了一些新的替代方案，比如：Docker。

容器化方案 —— Docker

Docker 是一种容器（Container）技术，Docker 容器本质上是运行在操作系统上的一个进程。但与普通进程不同的是，他通过 Namespace 和 Cgroups 机制，可以拥有自己的文件系统、网络配置、进程空间、用户 ID 等，这使得容器进程就像一个运行在操作系统上的系统，其目的是隔离容器间、容器和宿主机的环境。

• 核心亮点
  • 镜像（Image）
    • Docker 镜像可以打包运行环境和程序（甚至整个操作系统）
    • Docker 以相同的镜像可以启动无数的具有相同环境的容器
    • Docker 以不同的镜像可以启动无数的具有不同环境的容器
    • Docker 可以以极小的代价启动无数的容器（比虚拟机更少的资源占用，但也可以达到隔离环境的目的）
  • 镜像分层机制
    • Docker 以分层技术打包镜像
      • 使得多个镜像可以共用某些镜像层，可以减少镜像的磁盘占用和拉取镜像时的网络带宽占用
• 应用场景
  • 多个环境隔离（开发环境、测试环境、生产环境等）
  • 环境迁移（服务器更换等，只需要在新的环境安装 Docker，然后拉取镜像运行容器即可）

Docker（容器化方案）的出现，使我们的 DevOps 流程更加的完整，在生产力提升的路上迈进了一大步。但是，容器有个特点，它一般是不会去配置一个固定 IP 的（实际上配置固定 IP 影响或许会更大），没有固定 IP，其它服务如何知道这个服务（容器）的存在？

为了解决这个问题，我们需要一个运维平台，它需要有在系统上创建、销毁容器的能力，需要对容器运行的整个生命周期有控制权，并能够对容器进行管理，大佬们给取了个名字 —— 容器运维平台。

容器运维平台

容器运维平台通常包含以下几个组成部分：

• 镜像仓库
• 资源调度
• 容器调度
• 服务编排

镜像仓库

Docker 容器的运行依赖镜像，镜像必须存在于容器需要运行的机器，这个时候我们需要一个集中存储镜像的服务（你肯定不会想自己一个个的打包成压缩包，然后上传到服务器，再导入 Docker 的！），即镜像仓库（是不是有点耳熟？没错，原理上其实是跟 git 差不多的）。

参考 gitlab 的需求（权限管理、代码（镜像）同步、高可用），你可能也会需要一个私有镜像仓库服务？
没错，大佬们还是已经有类型的方案了 —— Harbor（不展开讲了，博主其它文章里也有讲，可以自行站内搜索查看）。

资源调度

镜像仓库解决了镜像的存储、访问问题；决定 Docker 镜像要分发到哪些服务器上，是资源调度需要解决的问题。

• 难点
  • 对接各个不同的集群
    • 物理机集群
    • 虚拟机集群
    • 公有云集群
  • 统一管理不同集群的权限、成本核算、环境初始化等
• 解决方案
  • 大佬说没有（2018 年）什么能直接拿来用的（等我研究过后可能回来填坑）

容器调度

在大规模（少则几十、几百，多则成千上万）部署应用容器的时候，人工做操显然已经不合适了，这个时候我们需要一个能够控制容器部署的调度系统，

• 核心功能
  • 主机过滤
    • 功能：限制容器创建时需要的机器类型（配置等）
    • 方式
      • 存活过滤（主机可能故障下线）
      • 硬件过滤（根据应用的内存、CPU 等需求，分配到不同配置的机器上）
  • 调度策略
    • 功能：给应用选择最优策略（最合适的机器），通常通过打分机制判定；可以减轻主机资源使用碎片化问题
• 常见调度系统
  • Swarm
  • Mesos
  • Kubernetes（K8S）

服务编排

服务编排的需求来源与服务间的互相依赖、服务发现、扩缩容等。

• 服务依赖
  • 需求：在微服务中，存在很多服务依赖关系，没有一个合适的依赖管理，在服务启动的时候，可能会出现大量请求错误等
  • 解决方案
    • Docker Compose：Docker 官方自带
    • K8S：K8S 有一整套的解决方案，其中包含服务依赖管理
• 服务发现
  • 需求：服务启动后，想对外提供服务，就需要把自己暴露出去
  • 解决方案
    • Nginx：以 reload 机制为核心，通过修改节点配置列表来实现服务发现
    • 注册中心：参考同系列文章中的注册中心
• 扩缩容
  • 需求：很多服务可能存在早晚高峰等问题，机器过少提供不了服务，机器多则浪费资源，我们需要一种机制，能够保证服务器在高峰的时候增多，低峰的时候减少
  • 解决方案
    • 通常通过 CPU 使用率等指标来控制扩缩容（具体做法每家可能不太一样）

总结

综合考虑，K8S 是一个不错的选择。很多文章里说小公司不合适，维护麻烦等问题，其实小公司大部分会选择一些云厂商来部署服务，如阿里云这样的，他们大部分提供 K8S 服务。如阿里云就提供了托管 Master 的 K8S 服务（非广告、没收钱、不要怕），用户只需要部署服务就行，基本可以不管 Master。