标签：启动 占用 com 指定 虚拟化 netflix images 持续集成 超时
Chris Richardson 微服务系列翻译全7篇链接：
原文链接：Choosing a Microservices Deployment Strategy
部署一个单体应用意味着运行着庞大应用的多个副本，通常需要 N 台服务器（物理机或虚拟机），在每台服务器上运行 M 个应用实例。部署单体应用一般并不特别直接，但还是比部署微服务应用简单。
一个微服务应用包括几十甚至数百个服务，使用不同的语言和框架写成，每个服务都是一个拥有特定的部署、资源、扩展性及监控需求的小应用。例如：根据服务需求运行若干个服务实例，而且每个服务实例必须配套提供适当的 CPU、内存 和 I/O 资源。更具挑战性的是，部署服务还必须快速、可靠、高效。
该模式下，需要多台物理机或虚拟机，在每个主机上部署多个服务实例。这是比较传统的部署方法。每个服务实例运行在一至多台主机的端口上，主机通常像照看宠物一样来管理这些服务。如下图所示：
这一模式有几个变型。其中之一就是每个服务对应一个或一组进程。例如：在 Apache Tomcat 服务器上部署 Java 服务实例作为 web 应用，一个 Node.js 服务实例可能包含一个父进程或一至多个子进程。
另一个变型是在一个进程或进程组中运行多个服务实例。例如：在同一台 Apache Tomcat 服务器中部署多个 Java web 应用，或者在一个 OSGI 容器中运行多个 OSGI 组件。
单主机多服务部署的优点：
1）资源利用率高，多个服务实例共享服务器及操作系统。如果一个进程或进程组运行多个服务实例的话，效率就更高了，比如多个web应用共享同一台 Apache Tomcat 服务器和 JVM。
2）部署服务实例快，只需将服务拷贝到主机并启动。如果服务是 Java 编写的，复制 JAR包 或者 WAR 包；如果是 Node.js 或者 Ruby 等其它语言，拷贝源代码即可。通过网络复制这些字节数还是比较小的。
3）由于没有太多开销，启动服务通常很快。如果服务实例运行在同一容器的进程或进程组，可以动态部署到容器或使用重启容器的方式启动服务。
不足在于：
1）服务实例之间没有隔离。虽然可以准确监控每个服务实例的资源使用情况，但是并不能限制每个实例使用的资源，很有可能一个异常的服务实例会消耗掉主机的所有内存和 CPU资源。
2）同一进程运行多个服务实例根本没有隔离性，所有服务实例共享一个 JVM 堆。一个异常的服务实例能够轻易的破坏运行在同一进程中的其它服务实例。此外，也无法监控每个服务资源使用的情况。
3）对运维团队来讲，需要了解部署服务的具体细节。服务可能用不同的语言和框架写成，因而开发团队必须分享给运维团队大量的细节。这种复杂性增加了部署中出错的风险。
这一模式有两种不同实现：每台虚拟机部署一个服务实例和每台容器部署一个服务实例。
该模式下，把每个服务打包为一个虚拟机镜像，例如 Amazon EC2 AMI。每个服务实例（例如 EC2 实例）使用虚拟机镜像启动。下图展示了此模式的结构：
这也是 Netflix 部署视频流媒体服务的最初方案。Netflix 使用 Aminator 把每个服务实例打包成 EC2 AMI，每个运行的服务实例就是一个 EC2 实例。
有多种工具可用来构建虚拟机镜像。可以配置持续集成（CI）服务器（例如 Jenkins）来调用 Aminator，把服务打包为 EC2 AMI。Packer.io 是另一个自动化创建虚拟机镜像的工具，不同于 Aminator，它支持包括 EC2、DigitalOcean、VirtualBox 和 VMware 在内的多种不同虚拟化技术。
Boxfuse 公司使用更加优秀的方式来构建虚拟机镜像，克服了下面会讲到的虚拟机镜像的不足。Boxfuse 把 Java 应用打包为一个迷你的虚拟机镜像。这些镜像能够快速构建、启动，由于只暴露了有限的可能被攻击的端口，所以也更安全。
CloudNative 使用 Bakery 这款 SaaS 工具来创建 EC2 AMI。用户的微服务通过测试后，能够配置 CI 服务器调用 Bakery，把服务打包为 AMI。使用 Bakery 这样的 SaaS 工具意味着你不需要浪费宝贵的时间来设置创建 AMI 的基础设施。
每台虚拟机一个服务实例的优点：
不足：
使用每台容器部署一个服务实例时，每个服务实例运行在自有容器中。容器是操作系统层面的虚拟化机制，一个容器由运行在沙盒中的一个或多个进程组成。从进程的角度看，它们有着自己的端口命名空间和根文件系统。用户能够限制容器的内存和 CPU 资源，有些容器还能限制 I/O 速率。容器技术的代表包括 Docker 和 Solaris Zone。下图展示了这种模式的架构：
使用这种模式时，用户将服务打包为容器镜像。一个容器镜像就是运行服务所需的应用和库组成的文件系统镜像。一些容器镜像还包括完整的 Linux 根文件系统。以部署 Java 服务为例，构建的容器镜像包括 Java 运行时或者Apache Tomcat 服务器以及编译好的 Java 应用。
一旦将服务打包为容器镜像，就可以启动一到多个容器了。通常一台物理机或虚拟主机上会运行多个容器，可以使用 Kubernetes 或 Marathon 这样的集群管理工具来管理容器。集群管理工具把主机看做资源池，根据每个容器需要的资源和每个主机上可用的资源来调度容器。
每台容器一个服务实例的优点类似虚拟机具有的优势：
不足：
有趣的是，容器和虚拟机之间的区别变的模糊起来。如前文所述，Boxfuse 能够快速构建和启动虚拟机，Clear Container 项目则致力于创建轻量级的虚拟机镜像，unikernel 技术也引起了大家的注意。Docker 近期（注：2016 年 1 月 21 日）收购了 Unikernel Systems。
AWS Lambda 就是 serverless 部署技术的范例。它支持 Java、Node.js 和 Python 服务。为了部署一个微服务，你需要把服务打包为 ZIP 文件并上传到 AWS Lambda，还要提供元数据，指定处理请求的函数名称。AWS Lambda 自动为微服务运行足够的实例来处理请求。可以简单根据每个请求花费的时间和消耗的内存来计费。开发人员无需担心服务器、虚拟机或容器的各个方面。
Lambda 函数是一个无状态的服务，通过调用 AWS 服务处理请求。例如，一个 Lambda 函数在一张图片被上传到 S3 时候调用，他能在 DynamoDB 表中插入一条记录，并向 Kinesis stream 发送一条消息来触发图片的处理。一个 Lambda 函数也可以调用第三方 web 服务。
有以下四种方法来调用 Lambda 函数：
可以看出，AWS Lambda 是部署微服务的一个便捷的方式。基于请求的定价方式意味着用户只需要为服务实际运行的业务付费。此外，用户无需考虑 IT 基础设施的问题，从而能够专注于应用的开发。
然而，AWS Lambda 也有一些局限性。它并不适合被用来部署长期运行的服务，比如消费来自第三方消息的服务。请求需要在 300 秒内完成，由于 AWS Lambda 理论上能够针对每个请求运行单独的实例，因此服务必须保持无状态。此外，它还必须用一种支持的编程语言来编写。服务也需要快速启动，否则将会超时或停止。
部署一个微服务应用充满挑战。应用由几十个甚至上百个用不同的语言和框架实现的服务所组成，每个服务都是一个拥有独立部署、资源、扩展和监控需求的微应用。微服务部署的模式有多种，包括单虚拟机单服务实例和单容器单服务实例。另一个有趣的微服务部署方法则是 AWS Lambda，一个 serverless 的方式。
标签：启动 占用 com 指定 虚拟化 netflix images 持续集成 超时
原文地址：http://www.cnblogs.com/butterfly100/p/7827783.html
