一个微服务应用由数百个服务组成，服务使用不同的语言和框架。每个服务都可以有自己的部署、资源、扩展和监控要求。例如，可以根据服务需求运行多个服务实例。此外，每个实例必须有自己的CPU、内存和I/O资源。尽管复杂，但更具挑战性的是服务部署必须快速、可靠且具有成本效益。单机多服务实例模式使用单机多服务实例模式，需要提供多台物理机或虚拟机，每台机器上运行多个服务实例。在许多情况下，这是应用程序部署的传统方法。每个服务实例都运行在一个或多个主机的知名端口上。该模式有一个参数表示每个服务实例由多少个进程组成。例如，Java服务实例可以作为Web应用程序部署在Tomcat上；一个Node.js服务实例可能由一个父进程和多个子进程组成。此模式有另一个参数，用于定义在同一进程组中运行的服务实例数。例如，可以在同一个Tomcat上运行多个JavaWeb应用程序，或者在同一个OSGI容器内运行多个OSGI包实例。单主机多服务实例模式的缺点之一是服务实例之间很少或没有隔离，除非每个服务实例都是一个单独的进程。如果要准确监控每个服务实例的资源使用情况，就不能限制每个实例的资源使用情况。所以一个坏的服务实例有可能占用主机的所有内存或CPU。单主机多服务实例模型的第二个缺点是运维团队必须知道如何部署的详细步骤。服务可以用不同的语言和框架来编写，所以开发团队必须要和运维团队有很多交流。复杂性增加了部署过程中出错的可能性。单主机单服务实例模式采用单主机单实例模式，每台主机上的服务实例都是独立的。有两种不同的实现方式：单VM单实例和单容器单实例。单虚拟机单服务实例模式采用单虚拟机单实例模式，一般将服务打包成虚拟机镜像。每个服务实例都是一个以此映像启动的虚拟机。下图说明了这种架构：资源利用效率不高。每个服务实例占用整个虚拟机的资源，包括操作系统。IaaS按VM计费，与虚拟机是否繁忙无关。部署新版本的服务很慢。由于其大小，虚拟机映像的创建速度相对较慢。同样的道理，虚拟机初始化也比较慢，操作系统启动也需要时间。运维团队有很多工作是创建和管理虚拟机。单容器单服务实例模式当使用单容器单服务实例模式时，每个服务实例都在自己的容器中运行。容器是一种在操作系统级别运行的虚拟化机制。一个容器包含多个在沙箱中运行的进程。从进程上看，它们有自己的命名空间和根文件系统；可以限制容器的内存和CPU资源。某些容器也有I/O限制，此类容器技术包括Docker和SolarisZones。下图展示了这种模式：使用这种模式需要将服务打包成容器镜像。容器镜像是一个文件系统，它运行包含所需服务的库和应用程序。一些容器镜像由完整的Linux根文件系统组成，其他容器镜像是轻量级的。例如，要部署Java服务，需要创建一个容器映像，其中包含Java运行时，可能还有Tomcat，以及已编译的Java应用程序。将服务打包成容器镜像后，需要启动多个容器。通常，多个容器运行在物理机或虚拟机上，可能需要集群管理系统，如k8s或Marathon等来管理容器。集群管理系统将宿主机看作一个资源池，根据每个容器的资源需求来决定将容器调度到哪个宿主机上。容器的优势类似于虚拟机。服务实例是完全独立的，可以很容易地监控每个容器消耗的资源。与虚拟机类似，容器使用隔离技术来部署服务。容器管理API也可以用作管理服务的API。然而，与虚拟机不同，容器是一种轻量级技术。容器镜像创建快，容器启动快。mapping930883.blogspot.com/2016/06/architect021.html
