如何部署微服务架构下的应用程序（？）微服务后端java运维程序员

一个微服务应用由上百个服务构成，服务采用不同语言和框架。每个服务可以有自己的部署、资源、扩展和监控需求。例如，可以根据服务需求运行若干个服务实例，除此之外，每个实例必须有自己的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