微服务部署模式

有了这些额外的优势，架构师和运营工程师也面临着许多新的挑战。之前，他们管理一个应用程序;现在他们不得不管理许多。每个应用程序都需要自己的支持服务，如数据库、消息队列等等。因此，利益相关者需要考虑不同的部署策略，在这些策略中，可以很好地部署整个应用程序，同时保持其完整性并提供最佳性能。

部署模式

微服务架构师提出了可以用来部署微服务的不同类型的模式。每种设计都为不同的功能和非功能需求提供了解决方案。

所以微服务可以用多种编程语言或框架编写。同样，它们可以用同一种编程语言或框架的不同版本编写。每个微服务包括几个不同的服务实例，如UI、DB和后端。微服务必须能够独立部署和扩展。服务实例必须相互隔离。服务必须能够快速构建和部署自身。必须为该服务分配适当的计算资源。部署环境必须可靠，服务必须受到监控。

每台主机多个服务实例

为了满足本节开始时提到的需求，我们可以考虑一个解决方案，通过它我们可以在一台主机上部署多个服务的服务实例。主机可以是物理的或虚拟的。因此，我们在一台共享主机上运行来自不同服务的许多服务实例。

我们可以用不同的方法来做这件事。我们可以将每个实例作为一个进程启动。我们也可以启动多个实例作为同一个实例的一部分进程，有点像网络应用。我们还可以使用脚本来自动化一些配置的启动和关闭过程。配置将具有不同的与部署相关的信息，比如版本号。

通过这种方法，资源可以得到非常有效的利用。

每台主机的服务实例

很多情况下，微服务需要自己的空间，需要明确分离的部署环境。在这种情况下，他们不能与其他服务或服务实例共享部署环境。可能会有资源冲突或稀缺的机会。当用同一种语言或框架编写的不同版本的服务不能放在一起时，可能会出现问题。

在这种情况下，服务实例可以部署在自己的主机上。主机可以是物理机，也可以是虚拟机。

在这种情况下，不会与其他服务发生任何冲突。该服务保持完全隔离。虚拟机的所有资源都可供服务使用。它很容易被监控。

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

每个虚拟机的服务实例

在许多情况下，微服务需要自己独立的部署环境。微服务必须是健壮的，并且必须快速启动和停止。同样，它也需要快速向上扩展和向下扩展。它不能与任何其他服务共享任何资源。它不能与其他服务发生冲突。它需要更多的资源，而资源必须适当地分配给服务。

在这种情况下，服务可以构建为虚拟机映像并部署在虚拟机中。

扩展可以快速完成，因为新虚拟机可以在几秒钟内启动。所有虚拟机都有自己的计算资源，这些资源根据微服务的需求进行适当分配。不会与任何其他服务发生任何冲突。每个虚拟机都被适当地隔离，并且可以获得负载平衡支持。

每个容器的服务实例

在某些情况下，微服务非常微小。它们的执行消耗很少的资源。然而，他们需要被隔离。不得有任何资源共享。他们同样无法承受共处一地的代价，并且有可能与其他服务发生冲突。如果有新版本，需要快速部署。可能需要部署相同的服务，但使用不同的发布版本。服务必须能够快速扩展。它还必须能够在几毫秒内启动和关闭。

在这种情况下，服务可以构建为容器映像，并作为容器进行部署。

在这种情况下，服务将保持隔离。不会有任何冲突的机会。可以根据计算出的服务需求来分配计算资源。这项服务可以迅速扩展。容器也可以快速启动和关闭。

无服务器部署

在某些情况下，微服务可能不需要知道底层的部署基础设施。在这些情况下，部署服务外包给第三方供应商，他们通常是云服务提供商。企业对底层资源完全漠不关心;它只想在一个平台上运行微服务。它根据每个服务调用从平台消耗的资源向服务提供商付费。服务提供者为每个请求挑选代码并执行它。执行可能发生在任何正在执行的沙箱中，如容器、VM或任何东西。它只是对服务本身隐藏起来。

无服务器部署平台的基础设施非常灵活。该平台扩展服务以自动吸收负载。消除了管理低级基础设施所花费的时间。由于微服务提供商只为每个呼叫消耗的资源付费，因此费用也降低了。

服务部署平台

微服务也可以部署在应用部署平台上。通过提供一些高级服务，这样的平台清楚地抽象出了部署。服务抽象可以处理非功能性和功能性需求，如服务实例的可用性、负载平衡、监控和可观察性。应用部署平台是完全自动化的。它使得应用程序的部署非常可靠、快速和高效。

结论

微服务部署选项和产品不断发展。可能会有更多的部署模式效仿。上面提到的许多模式非常流行，并且正在被大多数微服务提供商使用。他们非常成功和可靠。但是随着范式的变化，管理员正在考虑创新的解决方案。