共计 1475 个字符，预计需要花费 4 分钟才能阅读完成。
一个微服务利用由上百个服务形成，服务采纳不同语言和框架。每个服务能够有本人的部署、资源、扩大和监控需要。例如，能够依据服务需要运行若干个服务实例，除此之外，每个实例必须有本人的 CPU，内存和 I / O 资源。只管很简单，然而更挑战的是服务部署必须疾速、牢靠和性价比高。
单主机多服务实例模式
应用单主机多服务实例模式，须要提供若干台物理或者虚拟机，每台机器上运行多个服务实例。很多状况下，这是传统的利用部署办法。每个服务实例运行一个或者多个主机的 well-known 端口。
这种模式有一个参数代表每个服务实例由多少过程形成。例如，能够在 Tomcat 上部署一个 Java 服务实例作为 web 利用；而一个 Node.js 服务实例可能有一个父过程和若干个子过程形成。这种模式有另外一个参数定义同一过程组内有多少服务实例运行。例如，能够在同一个 Tomcat 上运行多个 Java web 利用，或者在同一个 OSGI 容器内运行多个 OSGI 捆绑实例。
单主机多服务实例模式的毛病之一是服务实例间很少或者没有隔离，除非每个服务实例是独立过程。如果想准确监控每个服务实例资源应用，就不能限度每个实例资源应用。因而有可能造成某个蹩脚的服务实例占用了主机的所有内存或者 CPU。
单主机多服务实例模式的毛病之二是运维团队必须晓得如何部署的具体步骤。服务能够用不同语言和框架写成，因而开发团队必定有很多须要跟运维团队沟通事项。其中复杂性减少了部署过程中出错的可能性。
单主机单服务实例模式
应用单主机单实例模式，每个主机上服务实例都是各自独立的。有两种不同实现模式：单虚拟机单实例和单容器单实例。
单虚拟机单服务实例模式
应用单虚拟机单实例模式，个别将服务打包成虚拟机 image。每个服务实例是一个应用此 image 启动的 VM。下图展现了此架构：
- 资源利用效率不高。每个服务实例占有整个虚机的资源，包含操作系统。
- IaaS 依照 VM 来免费，而不论虚机是否忙碌。
- 部署服务新版本比较慢。虚机镜像因为大小起因创立起来比较慢，同样起因，虚机初始化也比较慢，操作系统启动也须要工夫。
- 运维团队有大量的创立和治理虚机的工作。
单容器单服务实例模式
应用单容器单服务实例模式时，每个服务实例都运行在各自容器中。容器是运行在操作系统层面的虚拟化机制。一个容器蕴含若干运行在沙箱中的过程。从过程角度来看，他们有各自的命名空间和根文件系统；能够限度容器的内存和 CPU 资源。某些容器还具备 I / O 限度，这类容器技术包含 Docker 和 Solaris Zones。下图展现了这种模式：
应用这种模式须要将服务打包成容器 image。一个容器 image 是一个运行蕴含服务所需库和利用的文件系统。某些容器映像由残缺的 linux 根文件系统组成，其它则是轻量级的。例如，为了部署 Java 服务，须要创立蕴含 Java 运行库的容器映像，兴许还要蕴含 Tomcat，以及编译过的 Java 利用。
一旦将服务打包成容器映像，就须要启动若干容器。个别在一个物理机或者虚拟机上运行多个容器，可能须要集群管理系统，例如 k8s 或者 Marathon，来治理容器。集群管理系统将主机作为资源池，依据每个容器对资源的需要，决定将容器调度到那个主机上。
容器的长处跟虚机很类似，服务实例之间齐全独立，能够很容易监控每个容器耗费的资源。跟虚机类似，容器应用隔离技术部署服务。容器治理 API 也能够作为治理服务的 API。
然而，跟虚机不一样，容器是一个轻量级技术。容器 image 创立起来很快，容器启动也很快。
maping930883.blogspot.com/2016/06/architect021.html
