架构模式: 服务实例与容器一一对应

架构模式: 服务实例与容器一一对应

上下文

您已应用微服务架构模式并将系统架构为一组服务。每个服务都部署为一组服务实例，以实现吞吐量和可用性。

问题

如何打包和部署服务？

要点

• 服务使用各种语言，框架和框架版本        
• 编写每个服务包含多个服务实例    
• 用于吞吐量和可用性服务必须是可独立部署的    
• 可扩展的服务实例需要彼此隔离        
• 您需要能够快速构建和部署服务      
• 您需要能够约束服务所消耗的资源（CPU和内存）    
• 您需要监视每个服务实例的行为        
• 您希望部署可靠        
• 您必须尽可能经济高效地部署应用程序  

解决方案

将服务打包为（Docker）容器映像，并将每个服务实例部署为容器

例子

Docker正在成为一种非常流行的打包和部署服务的方式。每个服务都打包为Docker镜像，每个服务实例都是Docker容器。有几个Docker集群框架，包括：

• Kubernetes
• Marathon/Mesos
• Amazon EC2 Container Service

结果上下文

这种方法的好处包括：

• 通过更改容器实例的数量可以直接扩展和缩小服务。
• 容器封装了用于构建服务的技术的细节。例如，所有服务都以完全相同的方式启动和停止。
• 每个服务实例都是隔离的容器对服务实例消耗的CPU和内存施加限制容器的构建和启动速度非常快。例如，将应用程序打包为Docker容器比将其打包为AMI要快100倍。Docker容器的启动速度也比VM快得多，因为只有应用程序进程启动而不是整个操作系统。

这种方法的缺点包括（现在感觉已经非常成熟了）：

• 部署容器的基础架构不如部署虚拟机的基础架构丰富。

关联模式

• 此模式是每个主机模式的服务实例的细化。
• 每个VM模式的服务实例是另一种解决方案
• 无服务器部署模式是另一种解决方案。