应用部署初探：微服务的3大部署模式

在之前的文章中，我们已经充分了解了应用部署的4种常见模式（金丝雀部署、蓝绿部署、滚动部署及影子部署）。随着云原生技术逐步成熟，企业追求更为灵活和可扩展的系统，微服务架构大行其道。
 

微服务固然有诸多优点，但也给架构及运维工程师带来了新的挑战。在单体架构中，应用的设计、部署以及扩展都是作为一个单元进行，而当企业采用微服务时，可能有许多用不同语言和框架构建的相互连接的服务，从而导致部署变得更加复杂。
 

因此，企业需要采用不同的部署策略，使应用程序部署更丝滑且保证其完整性并拥有最佳性能。
 

部署模式

微服务架构可以采用不同类型的部署模式，并且每种设计都能为不同的功能和非功能需求提供解决方案。因此，服务可以用各种编程语言或框架编写。同样，它们也可以用同一编程语言或框架的不同版本来编写。
 

每个微服务都包含几个不同的服务实例，比如UI、数据库以及后端等。微服务必须独立部署和可扩展的。服务实例必须彼此隔离，并且每个服务都能够快速构建和部署，还可以合理分配计算资源。因此，部署环境必须是可靠的，服务必须被监控。
 

微服务部署模式

微服务部署模式包含若干种，但基本能分为以下三大类：

• 每台主机的单个服务实例
• 每台主机的多个服务实例
• 无服务器部署

在下文中，我们将详细介绍每种服务部署模式。
 

每台主机的多个服务实例

当采取这一模式时，用户需要配置一个或多个实体/虚拟的主机并在每个主机上运行多个服务实例。这是一种传统的应用部署方法。每个服务实例在一个或多个主机上的端口运行。
 
下图展示了该模式的架构：

这一模式有几个变体。一个变体是每个服务实例可以是一个流程或者一个流程组。例如，可以将一个Java服务实例部署为 Apache Tomcat 服务器上的一个Web 应用程序。一个 Node.js 服务实例可能由一个父进程和一个或多个子进程组成。
 

该模式的其他变体还有在同一个进程或进程组内部运行多个服务实例。例如，你可以在相同的 Apache Tomcat 服务器上部署多个 Java Web 应用或者在相同的 OSGI 容器中运行多个 OSGI bundle。
 

每台主机运行多个服务器实例的模式有其优劣。最主要的优势之一是它的资源利用率较为高效。多个服务实例共享一台服务器及其操作系统。如果一个流程或一个流程组运行多个服务实例，这样的资源利用效率则更为高效。另外，我们还可以使用脚本，通过一些配置来自动启动和关闭进程。配置会有不同的部署相关信息，比如版本号。
 

每台主机的单个服务实例

在很多情况下，微服务需要它们自己的空间以及一个被清晰分隔开的部署环境。在此类状况下，它们不能与其他服务或服务实例共享部署环境。这可能会导致资源冲突或是资源紧张，还有存在版本之间互相冲突的语言和框架的情况。
 

在此类情况下，一个服务实例只能部署在它自己的主机上。该主机既可以是物理的也可以是虚拟机。那么，此时将不会与其他服务产生冲突，并且该服务完全保持隔离状态。所有VM的资源都可用于该服务的消耗，并且易于监控。
 

唯一的问题是这一部署模式会消耗更多资源。
 

每台VM的单个服务实例

微服务架构必须健壮且可以快速启动和停止。同样的，也需要快速扩容和缩容。因此不能与其他服务共享任何资源，也要避免与其他服务的冲突。在这一模式中，你将把每个微服务打包为VM的镜像，每个服务实例就是一个虚拟机，它可以使用VM镜像来启动。
 

以下图例展示了这一模式的架构：

开发人员可以通过增加服务实例的数量来轻松扩展服务。这一部署模式可以让服务实例单独扩容，允许每个服务尤其专属的资源，使得程序员可以基于应用程序的使用模式根据需要进行扩缩容。
 

每个服务实例的隔离是最重要的优势之一。此外，开发人员可以使用云基础设施的功能，包括负载均衡和自动伸缩。但这种模式最显著的缺点是，消耗了大量的资源，需要相当长的时间来构建和管理虚拟机。
 

每个容器的单个服务实例

这一部署模式拥有虚拟机模式的优势，同时还具备更轻量、更高效的优点。在这一模式下，微服务实例运行在它们自己的容器中。
 

容器对于微服务来说是十分理想的环境，因为它不需要占用太多内存和CPU。它使用 Docker 容器运行时并支持在一个容器内部部署微服务的多个实例。这可以让资源利用更高效，并且可以根据需要扩缩容，减少不必要的开支。
 

每个容器中运行微服务的其中一个实例是一种最简单、无缝的部署方式。这意味着每个容器都有自己的数据库，并在其进程中运行。
 

容器可以让应用快速启动和扩展并且比起虚拟机所需的资源更少。
 

该模式为简化可扩展性和部署提供支持，同时隔离服务实例。更进一步的是，用户可以快速构建容器镜像，并且也可以轻松地管理容器。当然，这种方法也有其缺陷：

• 为了充分利用新版本的新特性和漏洞修复，程序员需要手动更新容器。如果你正在单个容器中运行微服务的多个实例，一次性更新它们会很耗时并且易出错

• 部署更新有时会出现问题：如果在应用程序实时运行时应用更新，可能会对用户体验产生不利影响，比如停机或数据丢失

• 尽管事实上容器技术在快速迭代发展，但是他们依旧不如虚拟机那样成熟和安全，因为容器们共享操作系统内核
   

无服务器（Serverless）部署

在某些情况下，微服务可能不需要了解底层部署基础设施，那么部署服务就会被承包给第三方供应商，他们通常是云服务提供商。企业对底层资源完全不在意，它所要做的就是在一个平台上运行微服务。它根据每次运行服务需要从平台上调用的资源来支付给服务提供商。服务提供商为每个请求挑选代码并执行。执行可能发生在任何执行沙盒中，如容器、虚拟机或其他，但它隐藏在服务本身之外。
 

服务提供商负责配置、扩展、负载均衡、打补丁和保障底层基础设施安全，目前最为常用的有：AWS Lambda、Google Functions等。
 

无服务器部署平台的基础设施是非常有弹性的，该平台会自动扩展服务以承受负载。进而花在管理低级别的基础设施上的时间会被节省下来。由于微服务提供者只需为每次调用所消耗的资源付费，因此支出也会降低。
 

总结

微服务部署模式和产品在不断发展，未来有可能会有更多的部署模式跟进。上面提到的许多模式目前都非常流行，并且被大多数微服务提供者所使用，它们是非常成功和可靠的。但随着技术的演进，业界也在思考创新的解决方案。在之后的文章，我们还将介绍如何保障应用部署的安全，请保持关注！