【51CTO.com快译】在过去的几年中，由于微服务架构(Microservices architecture)能够提供高级别的软件可扩展性，因此十分流行。尽管大多数组织都能够接受这种架构模式，但是他们也或多或少地遇到了，诸如如何将应用程序分解成为基于微服务的模式等多方面的挑战。
过去，我们曾经帮助美国最大的电信公司等客户，成功地实现了基于REST的微服务应用部署。我们在降低运营成本的同时，提高了整体服务的可用性。下面，我们将分享四种受欢迎的微服务部署策略，并在此基础上和您讨论：企业应该如何利用微服务来获得更高的敏捷性、灵活性、以及可扩展性。
微服务部署的挑战
通常，部署单体(monolithic)应用意味着您需要配置多台物理服务器或虚拟机，并在每台服务器上运行某个大型应用程序的多个实例。这样的部署方式虽然简单直接，但是对于微服务应用却并不一定适合。
首先，在部署微服务应用之前，您必须熟悉编写此类服务所涉及到的各种框架和语言。由于每一项服务都可能涉及到其特定的部署，不同的资源要求，以及扩展和监控方面的需求，因此这往往是最大的挑战之一。其次，就企业的角度而言，他们希望部署服务的过程尽量实现快速、可靠、且具有一定的成本效益。可见，我们需要通过灵活、可扩展的多种微服务部署模式，来应对广泛的组件集成请求。
微服务的部署策略
1.基于主机(物理机或虚机)的多服务实例
“基于主机的多服务实例”模式是最为传统的应用程序部署方法。在该模式下，软件开发人员可以提供单个或多个物理机或虚机，同时在每个主机上运行多个服务实例。此模式有几种不同的实现形式，其中包括：将每一个服务实例都作为一个单独的进程，或是在同一进程中运行多个服务实例。
优点
由于多个服务实例使用的是同一服务器、及其操作系统，因此它们的资源使用效率相对较高。
由于您只需要将服务复制到主机上，即可运行之，因此服务实例的部署也相对较快。例如：如果某个服务是由Java编写的，那么您只需要复制JAR或WAR文件;而如果它是用Node.js或Ruby编写的，则复制源代码便可。
如果某个服务本身带有进程，您可以直接启动之;当然也可以将其动态地部署到某个容器中。而如果该服务属于某个容器进程(或进程组)，而且正运行在多个实例里，那么您可以直接对它进行重启。
挑战
除非每个实例都是一个单独的进程，否则您对服务实例的实际控制权并不大。而且，您无法限制每个实例能够使用到的资源比例。这将带来主机内存被大量消耗的隐患。
如果多个服务实例在同一进程中运行，它们之间会缺乏隔离关系。这通常会导致在相同进程中，某个行为异常的服务能够直接影响、甚至中断其他的服务。
由于运营团队需要了解服务的详细信息，因此在部署期间，他们可能发生人为错误的风险较高。显然，开发和运营团队之间需要通过必要的信息交换，来尽可能地消除复杂性。
2.基于主机(物理机或虚机)的服务实例
此类微服务的部署方法能够让您在对应的主机上单独地运行每一个实例。此处的实例包括：基于单个虚拟机的服务实例，和基于单个容器的服务实例。
基于单个虚拟机的服务实例模式，能够让您将每个服务打包成为诸如Amazon EC2 AMI的虚拟机(VM)镜像。此处的实例就是指那些通过既有镜像运行起来的VM。目前，使用该模式的一个典型应用便是Netflix的视频流服务。为了构建自己的VM，您可以配置诸如Jenkins之类的连续集成服务器，当然也可以直接使用packer.io。
优点
基于虚拟机的服务实例有着一项显著的优点：由于是独立运行，它的内存使用数量是受限的，并且无法从其他服务中窃取额外的资源。
您可以利用诸如AWS之类成熟的云基础架构，来实现负载平衡和自动扩展。
由于一旦服务被打包成为了VM，那么在某种程度上说，该服务就会变成黑匣子，也就是实现了对于服务的封装，因此部署的整个过程会变得更加简单和可靠。
挑战
由于在典型的公共IaaS中，VM的大小通常是固定的，因此用户使用起来并不太方便。而随着资源利用率的低下，部署的成本则会反而升高。毕竟IaaS提供商收取VM费用时，是不会顾及VM的真正使用率的。
由于VM镜像的大小各不相同，它们在创建和实例化的速度上会有所差异，因此这可能会直接导致新版本部署进程的缓慢。不过，用户通常可以通过使用轻量级的VM，来克服此类缺陷。
在管理上，基于单个虚拟机的服务实例模式，往往需要运营团队通过使用工具来构建和管理虚拟机，以节省运维的时间。当然，您也可以通过使用诸如Box fuse之类的解决方案。
3.基于容器的服务实例
众所周知，常见的容器技术包括：Docker和Solaris Zones。在这种部署模式下，每个服务实例都运行在其各自的容器中，因此也被称为操作系统级别的虚拟化机制。
为了使用该模式，您需要将服务打包成为一个文件系统类型的镜像(通常被称为容器镜像)，其中包含执行该服务所需的应用程序、及其库文件。在完成打包之后，您需要启动一到多个容器，并在物理机或虚拟机上运行它们。为了管理多个容器，许多开发人员都会选择使用诸如Kubernetes或Marathon之类的集群管理器。
优点
类似前面基于虚拟机的服务实例模式，该模式也可以独立运作。您可以跟踪每个容器当前使用到的资源数量。不过与前者相比，该模式的最大优势在于容器往往是轻量级的，而且其构建的速度非常快。此外，由于不涉及到任何操作系统的启动机制，因此容器的启动也非常迅速。
挑战
尽管此类基础架构日趋成熟，但是基于容器的服务实例仍然落后于虚拟机架构。并且由于它们共享主机操作系统的内核，因此在安全性上也不及虚拟机。
同样与虚拟机所面临的挑战一样，您需要花时间从事较为繁重的容器镜像管理工作。也就是说，如果没有使用诸如Amazon EC2 Container Service(ECS)之类的托管容器解决方案的话，您必须手动管理容器，乃至虚拟机的基础架构。
此外，由于大多数针对容器的部署都是遵循基于虚拟机的定价模式，这就会导致用户必须增加额外的部署成本，以及进行超额的虚拟机配置，从而应对突发的负载高峰。
4.无服务器部署
作为微服务部署的第四种策略，无服务器部署技术能够支持Java、Node.js和Python服务。AWS Lambda是全球开发人员使用最多的无服务技术。在该部署模式下，您需要将服务打包成为一个ZIP文件，然后将其上传到Lambda函数(即一种无状态服务)中。
同时，您需要提供各种元数据，这些元数据带有在处理请求时所调用到的不同函数名称。Lambda函数需要自动运行足够多的微服务实例，以处理不同的请求。而作为用户，您只需根据所花费的时间、以及消耗的内存，为每个请求支付费用便可。
优点
由于您只需根据服务器的工作量付费，因此无服务器部署的最大优势便是价格。
由于能够从虚拟机、容器等IT架构方面解放出来，因此您可以有更多时间去专注于应用程序的开发。
挑战
无服务器部署的最大挑战是：它不能被用于那些长期运行的服务中。所有请求都必须在300秒内完成。
由于Lambda函数可能会为每个请求运行不同的实例，因此您的服务也必须是无状态的。
您的服务必须使用其支持的语言进行编写，并且必须能够快速启动，否则将会面临超时或被终止的危险。
总结
众所周知，如果没有正确的策略，微服务应用的部署可能会寸步难行。而在选择适合本企业的部署策略之前，我们需要全面考虑当前服务是由何种语言编写而成，其对应的框架，相应的部署、扩展与管理要求等方面。鉴于上述四种微服务部署方式，我们常用到的是通过平台即服务(Platform as a Service)的方式，将原有的单体应用程序迁移到无服务器的架构之中。
原文标题：Right Strategies for Microservices Deployment，作者：Rahul Singh
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
