微服务笔记27：容器调度与服务编排

容器调度

有一部分带需要发布服务的机器，但是在发布服务的时候应该选择哪些机器部署，这就是调度需要解决的问题。
机器少量的时候，认为选择还是可以支持，如果数量多大上百台，上千台，那么就不能人肉运维了。
三个解决方案：Docker原声的Swarm，以及Mesos,和谷歌开源的k8s.

容器调度解决的问题

1. 主机过滤

• 存活过滤：选择的节点必须是可用的。
• 硬件过滤：Web集群与大数据集群。集群类别不同需要的资源不同，Web属于密集计算类型那么CPU利用率比较高。
  大数据属于数据存储，IO要求比较高。
  新增容器属于大数据类型，那就需要添加到大数据集群中去，而不是Web集群中。
• 容器层次的过滤：某个主机才会被加入侯选集功能。

2. 调度策略
   为了解决容器创建时选择哪些主机合适的问题。
   Swarm 提供了两种策略spread和binpack.提供的策略是根据配置进行打分。
   spread 选择一个资源使用最少的节点，让容器尽可能的分布在不同的主机上。负载比较均衡。
   binpack 选择资源使用最多的节点，让容器运行在少数机器上。
   根据业务选择策略。

服务编排

服务编排需要考虑到三个方面 1. 服务依赖。 2. 服务发现 3. 自动扩缩容。

1. 服务依赖
   官方提供的方式是通过Docker-compose yaml文件编程进行依赖挂靠。先启动哪个容器，再启动后面的容器。
2. 服务发现
   调度完成后，需要将启动的节点服务加入到线上的服务中去。
   服务发现机制大概有两种：

• 基于Nginx的服务发现：针对HTTP服务的，通过节点列表配置利用reload机制加载配置文件。
• 注册中心的服务发现：针对RPC服务的，通过注册中心的服务发现机制。

3. 自动扩缩容
   容器完成调度后，需要做到姿容的扩缩容。
   时间规律性的产品，白天人数多，那么需要的机器容器就多，需要自动的扩容。晚上机器少，可以做到缩容。