容器与虚拟机的区别

1容器技术简介

对于容器，它首先是一个相对独立的运行环境，在这一点有点类似于虚拟机，但是不像虚拟机那样彻底。在容器内，应该最小化其对外界的影响，比如不能在容器内把宿主机上的资源全部消耗，这就是资源控制。

2容器与虚拟机的区别

容器和虚拟机之间的主要区别在于虚拟化层的位置和操作系统资源的使用方式。

1

1

　　容器与虚拟机拥有着类似的使命：对应用程序及其关联性进行隔离，从而构建起一套能够随处运行的自容纳单元。此外，容器与虚拟机还摆脱了对物理硬件的需求，允许我们更为高效地使用计算资源，从而提升能源效率与成本效益。

　　虚拟机会将虚拟硬件、内核（即操作系统）以及用户空间打包在新虚拟机当中，虚拟机能够利用“虚拟机管理程序”运行在物理设备之上。虚拟机依赖于hypervisor，其通常被安装在“裸金属”系统硬件之上，这导致hypervisor在某些方面被认为是一种操作系统。一旦 hypervisor安装完成， 就可以从系统可用计算资源当中分配虚拟机实例了，每台虚拟机都能够获得唯一的操作系统和负载(应用程序)。简言之，虚拟机先需要虚拟一个物理环境，然后构建一个完整的操作系统，再搭建一层Runtime，然后供应用程序运行。

　　 对于容器环境来说，不需要安装主机操作系统，直接将容器层(比如LXC或libcontainer)安装在主机操作系统(通常是Linux变种)之上。在安装完容器层之后，就可以从系统可用计算资源当中分配容器实例了，并且企业应用可以被部署在容器当中。但是，每个容器化应用都会共享相同的操作系统(单个主机操作系统)。容器可以看成一个装好了一组特定应用的虚拟机，它直接利用了宿主机的内核，抽象层比虚拟机更少，更加轻量化，启动速度极快。

　　相比于虚拟机，容器拥有更高的资源使用效率，因为它并不需要为每个应用分配单独的操作系统——实例规模更小、创建和迁移速度也更快。这意味相比于虚拟机，单个操作系统能够承载更多的容器。云提供商十分热衷于容器技术，因为在相同的硬件设备当中，可以部署数量更多的容器实例。此外，容器易于迁移，但是只能被迁移到具有兼容操作系统内核的其他服务器当中，这样就会给迁移选择带来限制。

　　因为容器不像虚拟机那样同样对内核或者虚拟硬件进行打包，所以每套容器都拥有自己的隔离化用户空间，从而使得多套容器能够运行在同一主机系统之上。我们可以看到全部操作系统层级的架构都可实现跨容器共享，惟一需要独立构建的就是二进制文件与库。正因为如此，容器才拥有极为出色的轻量化特性。

　　对Docker稍有接触的人应该都见过下图，无需更多解释，Docker减少Guest OS这一层级，所以更轻量和更高性能。

　　docker虚拟机区别

3深层区别：

　　docker虚拟机区别

更新：Docker现在已经支持windows平台，所以上面的Windows支持一栏可以忽略。

vps是虚拟服务器服务技术，是将一台服务器分割成多个虚拟专享服务器的优质服务。实现VPS的技术分为容器技术，和虚拟化技术。在容器或虚拟机中，每个VPS都可选配独立公网IP地址、独立操作系统、实现不同VPS间磁盘空间、内存、CPU资源、进程和系统配置的隔离。

VPS主机可以像独立服务器一样分割出许多虚拟主机空间，每个空间都可以放许多网站，非常适合为中小企业、小型门户网站、个人工作室、SOHO一族提供网站空间，较大独享资源，安全可靠的隔离保证了用户对于资源的使用和数据的安全。

扩展资料：

VPS技术的优势：

1、每一个VPS拥有其独立的过程、用户、文件并提供完全ROOT访问权限。

2、每一个VPS可以拥有独立IP地址、端口号码、表单、以及过滤和路由规则。

3、每个VPS可以拥有自己的系统配置文件并能够装载一个应用程序。

4、每个VPS可以拥有自己的系统函数库版本或者修改现有的系统函数库版本。

5、透明化：无需重新包装、重新编译、重新测试、重新培训–所有的应用程序按照同样的方式运行。

——VPS

基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源，开发人员只需要开发业务代码并提交到平台代码库，做一些必要的配置，系统会自动构建、部署，实现应用的敏捷开发、快速迭代。在系统架构上，PaaS云平台主要分为微服务架构、Docker容器技术、DveOps三部分，这篇文章重点介绍微服务架构的实施。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

实施微服务需要投入大量的技术力量来开发基础设施，这对很多公司来说显然是不现实的，别担心，业界已经有非常优秀的开源框架供我们参考使用。目前业界比较成熟的微服务框架有Netflix、Spring Cloud和阿里的Dubbo等。Spring Cloud是基于Spring Boot的一整套实现微服务的框架，它提供了开发微服务所需的组件，跟Spring Boot一起使用的话开发微服务架构的云服务会变的很方便。Spring Cloud包含很多子框架，其中Spring Cloud Netflix是其中的一套框架，在我们的微服务架构设计中，就使用了很多Spring Cloud Netflix框架的组件。Spring Cloud Netflix项目的时间还不长，相关的文档资料很少，博主当时研究这套框架啃了很多英文文档，简直痛苦不堪。对于刚开始接触这套框架的同学，要搭建一套微服务应用架构，可能会不知道如何下手，接下来介绍我们的微服务架构搭建过程以及 需要那些 框架或组件来支持微服务架构。

为了直接明了的展示微服务架构的组成及原理，画了一张系统架构图，如下：

从上图可以看出，微服务访问大致路径为：外部请求 → 负载均衡 → 服务网关（GateWay）→ 微服务 → 数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务，各服务集群都能通过配置中心服务来获得配置信息。

服务网关（GateWay）

网关是外界系统（如：客户端浏览器、移动设备等）和企业内部系统之间的一道门，所有的客户端请求通过网关访问后台服务。为了应对高并发访问，服务网关以集群形式部署，这就意味着需要做负载均衡，我们采用了亚马逊EC2作为虚拟云服务器，采用ELB(Elastic Load Balancing)做负载均衡。EC2具有自动配置容量功能，当用户流量达到尖峰，EC2可以自动增加更多的容量以维持虚拟主机的性能。ELB弹性负载均衡，在多个实例间自动分配应用的传入流量。为了保证安全性，客户端请求需要使用https加密保护，这就需要我们进行SSL卸载,使用Nginx对加密请求进行卸载处理。外部请求经过ELB负载均衡后路由到GateWay集群中的某个GateWay服务，由GateWay服务转发到微服务。服务网关作为内部系统的边界，它有以下基本能力：

1、动态路由：动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构，但是外部系统从网关看就像是一个整体服务，网关屏蔽了后端服务的复杂性。

2、限流和容错：为每种类型的请求分配容量，当请求数量超过阀值时抛掉外部请求，限制流量，保护后台服务不被大流量冲垮；党内部服务出现故障时直接在边界创建一些响应，集中做容错处理，而不是将请求转发到内部集群，保证用户良好的体验。

3、身份认证和安全性控制：对每个外部请求进行用户认证，拒绝没有通过认证的请求，还能通过访问模式分析，实现反爬虫功能。

4、监控：网关可以收集有意义的数据和统计，为后台服务优化提供数据支持。

5、访问日志：网关可以收集访问日志信息，比如访问的是哪个服务？处理过程（出现什么异常）和结果？花费多少时间？通过分析日志内容，对后台系统做进一步优化。

我们采用Spring Cloud Netflix框架的开源组件Zuul来实现网关服务。Zuul使用一系列不同类型的过滤器（Filter），通过重写过滤器，使我们能够灵活的实现网关（GateWay）的各种功能。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

服务注册与发现

由于微服务架构是由一系列职责单一的细粒度服务构成的网状结构，服务之间通过轻量机制进行通信，这就引入了服务注册与发现的问题，服务的提供方要注册报告服务地址，服务调用放要能发现目标服务。我们的微服务架构中使用了Eureka组件来实现服务的注册与发现。所有的微服务（通过配置Eureka服务信息）到Eureka服务器中进行注册，并定时发送心跳进行 健康 检查，Eureka默认配置是30秒发送一次心跳，表明服务仍然处于存活状态，发送心跳的时间间隔可以通过Eureka的配置参数自行配置，Eureka服务器在接收到服务实例的最后一次心跳后，需要等待90秒（默认配置90秒，可以通过配置参数进行修改）后，才认定服务已经死亡（即连续3次没有接收到心跳），在Eureka自我保护模式关闭的情况下会清除该服务的注册信息。所谓的自我保护模式是指，出现网络分区、Eureka在短时间内丢失过多的服务时，会进入自我保护模式，即一个服务长时间没有发送心跳，Eureka也不会将其删除。自我保护模式默认为开启，可以通过配置参数将其设置为关闭状态。

Eureka服务以集群的方式部署（在博主的另一篇文章中详细介绍了Eureka集群的部署方式），集群内的所有Eureka节点会定时自动同步微服务的注册信息，这样就能保证所有的Eureka服务注册信息保持一致。那么在Eureka集群里，Eureka节点是如何发现其他节点的呢？我们通过DNS服务器来建立所有Eureka节点的关联，在部署Eureka集群之外还需要搭建DNS服务器。

当网关服务转发外部请求或者是后台微服务之间相互调用时，会去Eureka服务器上查找目标服务的注册信息，发现目标服务并进行调用，这样就形成了服务注册与发现的整个流程。Eureka的配置参数数量很多，多达上百个，博主会在另外的文章里详细说明。

微服务部署

微服务是一系列职责单一、细粒度的服务，是将我们的业务进行拆分为独立的服务单元，伸缩性好，耦合度低，不同的微服务可以用不同的语言开发，每一个服务处理的单一的业务。微服务可以划分为前端服务（也叫边缘服务）和后端服务（也叫中间服务），前端服务是对后端服务做必要的聚合和剪裁后暴露给外部不同的设备（PC、Phone等），所有的服务启动时都会到Eureka服务器进行注册，服务之间会有错综复杂的依赖关系。当网关服务转发外部请求调用前端服务时，通过查询服务注册表就可以发现目标服务进行调用，前端服务调用后端服务时也是同样的道理，一次请求可能涉及到多个服务之间的相互调用。由于每个微服务都是以集群的形式部署，服务之间相互调用的时候需要做负载均衡，因此每个服务中都有一个LB组件用来实现负载均衡。

微服务以镜像的形式，运行在Docker容器中。Docker容器技术让我们的服务部署变得简单、高效。传统的部署方式，需要在每台服务器上安装运行环境，如果我们的服务器数量庞大，在每台服务器上安装运行环境将是一项无比繁重的工作，一旦运行环境发生改变，就不得不重新安装，这简直是灾难性的。而使用Docker容器技术，我们只需要将所需的基础镜像（jdk等）和微服务生成一个新的镜像，将这个最终的镜像部署在Docker容器中运行，这种方式简单、高效，能够快速部署服务。每个Docker容器中可以运行多个微服务，Docker容器以集群的方式部署，使用Docker Swarm对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像，在镜像仓库中对所有镜像进行管理。

服务容错

微服务之间存在错综复杂的依赖关系，一次请求可能会依赖多个后端服务，在实际生产中这些服务可能会产生故障或者延迟，在一个高流量的系统中，一旦某个服务产生延迟，可能会在短时间内耗尽系统资源，将整个系统拖垮，因此一个服务如果不能对其故障进行隔离和容错，这本身就是灾难性的。我们的微服务架构中使用了Hystrix组件来进行容错处理。Hystrix是Netflix的一款开源组件，它通过熔断模式、隔离模式、回退（fallback）和限流等机制对服务进行弹性容错保护，保证系统的稳定性。

1、熔断模式：熔断模式原理类似于电路熔断器，当电路发生短路时，熔断器熔断，保护电路避免遭受灾难性损失。当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，执行fallback逻辑直接返回，不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为50%，超过阀值将自动启动熔断模式。服务隔离一段时间以后，熔断器会进入半熔断状态，即允许少量请求进行尝试，如果仍然调用失败，则回到熔断状态，如果调用成功，则关闭熔断模式。

2、隔离模式：Hystrix默认采用线程隔离，不同的服务使用不同的线程池，彼此之间不受影响，当一个服务出现故障耗尽它的线程池资源，其他的服务正常运行不受影响，达到隔离的效果。例如我们通过andThreadPoolKey配置某个服务使用命名为TestThreadPool的线程池，实现与其他命名的线程池隔离。

3、回退（fallback）：fallback机制其实是一种服务故障时的容错方式，原理类似Java中的异常处理。只需要继承HystixCommand并重写getFallBack()方法，在此方法中编写处理逻辑，比如可以直接抛异常（快速失败），可以返回空值或缺省值，也可以返回备份数据等。当服务调用出现异常时，会转向执行getFallBack()。有以下几种情况会触发fallback：

1）程序抛出非HystrixBadRequestExcepption异常，当抛出HystrixBadRequestExcepption异常时，调用程序可以捕获异常，没有触发fallback，当抛出其他异常时，会触发fallback；

2）程序运行超时；

3）熔断启动；

4）线程池已满。

4、限流： 限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并fallback，防止后台服务被冲垮。

Hystix使用命令模式HystrixCommand包装依赖调用逻辑，这样相关的调用就自动处于Hystrix的弹性容错保护之下。调用程序需要继承HystrixCommand并将调用逻辑写在run()中，使用execute()（同步阻塞）或queue()（异步非阻塞）来触发执行run()。

动态配置中心

微服务有很多依赖配置，某些配置参数在服务运行期间可能还要动态修改，比如：根据访问流量动态调整熔断阀值。传统的实现信息配置的方法，比如放在xml、yml等配置文件中，和应用一起打包，每次修改都要重新提交代码、打包构建、生成新的镜像、重新启动服务，效率太低，这样显然是不合理的，因此我们需要搭建一个动态配置中心服务支持微服务动态配置。我们使用Spring Cloud的configserver服务帮我们实现动态配置中心的搭建。我们开发的微服务代码都存放在git服务器私有仓库里面，所有需要动态配置的配置文件存放在git服务器下的configserver（配置中心，也是一个微服务）服务中，部署到Docker容器中的微服务从git服务器动态读取配置文件的信息。当本地git仓库修改代码后push到git服务器仓库，git服务端hooks(post-receive，在服务端完成代码更新后会自动调用)自动检测是否有配置文件更新，如果有，git服务端通过消息队列给配置中心（configserver，一个部署在容器中的微服务）发消息，通知配置中心刷新对应的配置文件。这样微服务就能获取到最新的配置文件信息，实现动态配置。

以上这些框架或组件是支撑实施微服务架构的核心，在实际生产中，我们还会用到很多其他的组件，比如日志服务组件、消息服务组件等等，根据业务需要自行选择使用。在我们的微服务架构实施案例中，参考使用了很多Spring Cloud Netflix框架的开源组件，主要包括Zuul（服务网关）、Eureka（服务注册与发现）、Hystrix（服务容错）、Ribbon（客户端负载均衡）等。这些优秀的开源组件，为我们实施微服务架构提供了捷径。

如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。

云计算服务器虚拟化的核心技术，CPU虚拟化：CPU虚拟化把物理CPU抽象成虚拟CPU，任意时刻一个物理CPU只能运行一个虚拟CPU的指令。

内存虚拟化：内存虚拟化技术把物理机的真实物理内存统一管理，包装成多个虚拟的物理内存分别供若干个虚拟机使用，蚂牢使得每个虚拟机拥有各自独立的内存空间。

设备与I/O虚拟化：设备与I/O虚拟化技术对物理机的真实设备进行统一管理，包装成多个虚拟设备给若干个虚拟机使用，响应每个虚拟机的设备访问请求歌轿攀和I/O请求。

网络虚拟化：网络虚拟化是将多个硬件或软件网络资源及相关的网络功能集成到一个可用软件中统一管控的过程，并且对于网络应用而言，该网络环境的实现方式是透明的。

实时迁移技术：实时迁移技术是在虚拟机运行过程中，将整个虚拟机的运行状态完整快速地从原来所在的宿主机硬件平台迁移到新的宿主机硬件平台上，并且整个迁移过程是平滑的，用户几乎不会察爷蚊觉到任何差异。

感兴趣的话点击此处，免费了解一下

亿万克作为中国战略性新兴产业领军品牌，拥有中国第一、世界前二的行业领先技术，致力于新型数据中心建设，构筑云端安全数字底座，为客户提供集产品研发、生产、部署、运维于一体的服务器及IT系统解决方案业务，所有产品和技术完全拥有自主知识产权，应用领域涵盖云计算、数据中心、边缘计算、人工智能、金融、电信、教育、能源等，为客户提供全方位安全自主可控技术服务保障。

Docker容器是一个开源的应用程序引擎，允许开发人员打包他们的应用程序，并依赖于一个便携容器的包，然后发布到任何流行的Linux机器上，也可以实现虚拟化。

容器完全是沙盒机制，没有任何接口(像iPhone应用程序)。很少有性能开销，并且可以很容易地在机器和数据中心中运行。最重要的是，他们不依赖任何语言、框架或系统。

虚拟化最初被称为资源的抽象，它是单个物理资源的多个逻辑表示，或者是多个物理资源的一个逻辑表示。特定于服务器虚拟化的是多个物理资源的单一逻辑表示。

虚拟化技术可以扩展硬件的容量，简化软件的重新配置过程。CPU虚拟化技术可以是多CPU并行的单CPU仿真，同时允许一个平台同时运行多个操作系统，应用程序可以在不同的空间和相互影响下运行，从而提高计算机的工作效率。

在实际的生产环境中，虚拟化技术主要用于解决物理硬件过剩的高性能，旧的硬件容量的重构过低的重用，透明底层物理硬件，从而最大限度地利用物理硬件。

容器技术虚拟化技术提升效率

容器技术已经引起了业内的广泛关注，有充分的证据表明，容器技术能够大大提升工作效率。

虚拟化技术已经成为一种被大家广泛认可的服务器资源共享方式，它可以在按需构建操作系统实例的过程当中为系统管理员提供极大的灵活性。由于hypervisor虚拟化技术仍然存在一些性能和资源使用效率方面的问题，因此出现了一种称为容器（Container）的新型虚拟化技术来帮助解决这些问题。

起初，大家普遍认为基于hypervisor的方式可以在最大程度上提供灵活性。所有虚拟机实例都能够运行任何其所支持的操作系统，而不受其他实例的影响。然而，越来越多的用户发现hypervisor提供这样一种广泛支持的特性其实是在给自己制造麻烦。对于hypervisor环境来说，每个虚拟机实例都需要运行客户端操作系统的完整副本以及其中包含的大量应用程序。从实际运行的角度来说，由此产生的沉重负载将会影响其工作效率及性能表现。

首先，每种操作系统和应用程序堆栈都需要使用DRAM。对于多个运行简单应用程序的小型虚拟机实例来说，这种方式可能产生很大的系统开销，降低性能表现。加载并卸载这些堆栈镜像需要花费很长时间，并且还会增加容器技术服务器的网络连接数量。对于极端情况来说，如果用户在上午9点同时启动上千台虚拟桌面，还有可能导致网络风暴的发生。

部署虚拟服务器的目的之一在于快速创建新的虚拟机实例。然而从网络存储当中复制镜像需要花费大量时间，这些操作会延长启动过程，无疑会限制系统灵活性。

因此我们可以选择使用容器技术。只需要通过简单的观察我们便能够发现容器技术的出现是为了解决多操作系统/应用程序堆栈的问题：

在单台服务器当中为所有虚拟机实例使用相同的操作系统对于大部分数据中心来说都不算是真正的限制。流程管理（Orchestration）可以轻松处理这种变化

许多应用程序堆栈都是相同的（如LAMP）

对于大规模集群来说，在本地硬盘当中存储操作系统副本将会使得更新过程变得更为复杂

最为重要的是，容器技术可以同时将操作系统镜像和应用程序加载到内存当中。还可以从网络磁盘进行加载，因为同时启动几十台镜像不会对网络和存储带来很大负载。之后的镜像创建过程只需要指向通用镜像，大大减少了所需内存。

容器技术能够在同一台服务器上创建相比于之前两倍的虚拟机实例数量，因此无疑将会降低系统总投入。但是必须认真进行规划，因为双倍的实例数量同样意味着对于运行这些实例的服务器带来了双倍的I/O负载。

我们需要了解除了避免可能发生的启动风暴之外，容器技术是否还有任何其他性能方面的优势。能否改进IOPS？能够提升网络连接效率并且降低容器间的延迟，解决伴随实例数量增加而产生的问题？

美国某传统服务器大厂商的某实验室完成了至今为止大部分权威实验，其研究结果表明容器技术相比于hypervisor，容器技术的许多关键指标都有重大改进。在进行的所有测试当中，容器技术几乎拥有和本地平台一样的运行速度，尽管网络延迟测试还没有完成。

上述厂商的研究表明容器技术在多个领域当中都比hypervisor拥有更好的性能表现。容器技术的运行速度几乎是hypervisor的两倍，在评分当中非常接近于本地操作系统。在和KVM的对比当中，容器技术在硬盘随机读取(84,000 vs 48,000 IOPS)和写入(110,000 vs 60,000 IOPS )方面拥有非常优秀的表现，如果使用本地固态硬盘可以实现更好的SQL性能表现。

1、什么是虚拟主机

所谓虚拟主机就是我们常说的共享主机，多数情况下站长都是从“共享主机”开始建站的。一台服务器链接很多网站，彼此共享这台服务器的硬件设置和宽带资源。因其价格便宜，比较适合建站初期使用。

2、什么是VPS主机

所谓VPS主机，可以将一台服务器划分为多个虚拟专享服务器，每个VPS主机都可以独立分配IP地址、操作系统、CPU资源等，同时，VPS拥有系统的root权限，能够任意切割磁盘空间大小、分配用户权限等。价格相比虚拟主机较贵，技术要求也比较高。

3、两者有什么区别？

1)在功能上

VPS主机相比较虚拟主机来说，更灵活一些，运营和管理也没有太多的局限性，性能也更高一些，如果你的网站流量数据比较大，那么可以选择VPS的主机。

2)在操作上

上面我们也提到了，虚拟主机因为是共享一个“服务器”，比较适合小白，vps能够自由分配ip地址等自身的独特性，对技术要求相当高。同时，vps主机可以作为虚拟服务器自建操作系统，虚拟主机不可以。

3)资源占用不同

vps独享硬盘资源，用户对服务器全权掌控，虚拟主机提供的则是硬件资源共享功能，用户只有部分掌控权。

4)软件硬件隔离

VPS能够隔离软件和硬件，虚拟主机则不行。相对来说，VSP主机安全性更高一些。