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