服务部署到主机(虚机)的3种常见模型：单服务主机、多服务主机和容器调度。
单服务主机(虚机)
采用服务和底层主机之间一对一部署的方式，易于理解并且在资源需求和多个服务运行时环境之间提供了清晰和显式的隔离。
这种模型并不完美。根据每个服务的需求适当调整虚拟实例的大小需要持续的跟进和评估。如果不是在云环境中运行，可能会受到数据中心或虚拟化解决方案的限制。另外，虚拟机启动时间相对较慢，通常需要数分钟时间。
个人理解，这种方式下多个副本会启动多个虚机，即使是1核1G，虚机量会很多。虚机管理会比较复杂，部署服务会比较复杂耗时也长。资源占用比较浪费，如果15个1核的虚机，以容器方式部署到同一个主机只需要8核就能搞定。
多服务主机(单主机多静态服务)
在一台主机上运行多个服务是可行的。在这种模型的静态化方案中，服务分配到哪些主机上通过手动控制和静态化的。服务所有者在部署之前要有意识地选择每个服务应该在哪些主机上运行。
乍一看，这种方法似乎是可取的。如果主机比较稀缺或者获取新主机的成本很高，那么在生产环境中最简单的方法就是最大限度地使用现有的有限数量的主机。
但这种方法同样存在一些不足。它提高了服务之间的耦合度：将多个服务部署到同一台主机将使服务之间产生耦合，从而导致无法独立发布服务。它还提高了依赖项管理的复杂度：如果一个服务需要1.1版本的包，而另一个服务需要2.0版本的包，那么这种差异是很难协调的。没人能说清楚哪个服务拥有部署环境，因此也就没人清楚哪个团队负责管理这些配置信息。
这种方式同时会导致在对服务进行独立监控和扩容时面临巨大挑战。服务器中一个服务出现问题可能会对其他服务产生不利影响，并且这也会导致难以独立地监控各个服务的资源利用率（CPU、内存）。
汇总弊端：
1) 将多个服务部署到同一台主机将使服务之间产生耦合，从而导致无法独立发布服务。如果是将某些服务固定在某个主机上，这个感觉可以克服，取决于服务间的通信方式，如果通过注册中心的话，可以将任意多个服务部署到任意一台主机上。
2) 依赖项管理的复杂度：同一主机服务如果是依赖某个软件的不同版本，取决于各个服务间的隔离，如果在容器里边是不存在这样问题的。
3) 对服务进行独立监控时面临巨大挑战，多个服务在一台主机，比如监控其资源占用就不太方便，同时资源占用需要规划。
4) 对服务进行扩容时面临巨大挑战，如果某一类服务只能部署在一台主机上，如果要扩容，肯定要扩出来一台主机，但该主机上其它服务不一定需要扩容。
这种场景下，产品有可能只有一台主机或多台主机，单台主机的话可以思考下服务如何部署?多台主机时服务如何部署?
容器调度(单主机多调度化服务)
这个方案基本上可以解决单主机多静态服务的弊端问题。
如果可以不必考虑那些运行服务的底层主机而完全关注每个应用的独特运行时环境，就简单多了，这是平台即服务（PaaS）解决方案最初的承诺。
PaaS会提供一些用于部署和运行服务的工具，只需要很少的操作配置或者基本不暴露底层基础设施资源。尽管这些平台易于使用，但它们常常难以在自动化和控制权之间实现平衡——简化部署，但是禁止开发者定制——且高度特定于供应商。
容器提供了更加优雅的抽象。
1）工程师可以定义和分发完整的应用工件
2）虚拟机可以运行多个单独的容器，它们之间相互隔离。
3）容器提供了运维API，可供开发者使用更高级的工具来实现自动化。
这3个方面使得容器调度或编排成为可能。容器调度器是一种软件工具，通过管理共享资源池不可拆分的、容器化的应用程序的执行，将底层主机抽离出去。通常，调度器由一个主节点和一个工作节点集群组成，主节点将应用的工作任务分发给工作节点集群。自动化部署工具向此主节点发送指令执行容器部署。
不同于单主机多静态服务的部署方式，采用调度模型的服务所分配的主机是动态的，取决于每个应用所定义的资源需求（CPU、硬盘、内存）。这避免了静态化模型的不足，同时容器模型还保持了服务的独立性。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论