背景
你已经采用了微服务架构并且将你的系统架构为一组服务。每个服务为了吞吐量和可用性,部署为一组服务实例。
问题
怎样将服务打包和部署?
限制
- 服务采用不同语言,不同框架,不同框架版本编写
- 每个服务为了吞吐量和可用性,存在多个服务实例
- 服务必须独立部署和扩展
- 服务实例彼此之间应该隔离
- 你需要可以快速的构建和部署服务
- 你需要可以限制服务消费的资源(CPU和内存)
- 你需要监控每个服务实例的行为
- 你想要可靠部署
- 你必须尽可能小成品的部署应用程序
解决方案
将服务打包为(Docker)容器镜像,部署每个服务实例为容器
示例
Docker正在成为一个极其受欢迎的打包和部署服务的方式。每个服务打包为Docker镜像,每个服务实例是一个Docker容器。现在有很多Docker集群框架,例如:
结果
这个方法的优势包括:
- 简单直接的通过更改容器实例数量,而扩展和收缩服务。
- 容器封装了构建服务的技术细节。所有服务,举个例子,都以相同的方法启动和停止。
- 服务实例之间是隔离的
- 容器限制了服务实例可以消耗的CPU和内存
- 容器构建和运行极其快速。比如,将应用打包为Docker容器比将其打包为AMI快了100倍。而且Docker容器启动比虚拟机快得多,由于只启动应用进程,而不是整个操作系统。
这个方法的弊端包括:
- 部署容器的基础设施不像部署虚拟机那么丰富。
相关模式
- 这个模式是每主机单个服务实例的精进
- 每虚拟机单个服务实例是个可替代的解决方案
- 无服务器部署模式是个可替代的解决方案