架构模式: 服务实例与容器一一对应
上下文
您已应用微服务架构模式并将系统架构为一组服务。每个服务都部署为一组服务实例，以实现吞吐量和可用性。
问题
如何打包和部署服务？
要点
- 服务使用各种语言，框架和框架版本
- 编写每个服务包含多个服务实例
- 用于吞吐量和可用性服务必须是可独立部署的
- 可扩展的服务实例需要彼此隔离
- 您需要能够快速构建和部署服务
- 您需要能够约束服务所消耗的资源（CPU和内存）
- 您需要监视每个服务实例的行为
- 您希望部署可靠
- 您必须尽可能经济高效地部署应用程序
解决方案
将服务打包为（Docker）容器映像，并将每个服务实例部署为容器
例子
Docker正在成为一种非常流行的打包和部署服务的方式。每个服务都打包为Docker镜像，每个服务实例都是Docker容器。有几个Docker集群框架，包括：
结果上下文
这种方法的好处包括：
- 通过更改容器实例的数量可以直接扩展和缩小服务。
- 容器封装了用于构建服务的技术的细节。例如，所有服务都以完全相同的方式启动和停止。
- 每个服务实例都是隔离的容器对服务实例消耗的CPU和内存施加限制容器的构建和启动速度非常快。例如，将应用程序打包为Docker容器比将其打包为AMI要快100倍。Docker容器的启动速度也比VM快得多，因为只有应用程序进程启动而不是整个操作系统。
这种方法的缺点包括（现在感觉已经非常成熟了）：
- 部署容器的基础架构不如部署虚拟机的基础架构丰富。
关联模式
- 此模式是每个主机模式的服务实例的细化。
- 每个VM模式的服务实例是另一种解决方案
- 无服务器部署模式是另一种解决方案。