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