微服务部署模式

大纲（优先看）

微服务部署模式的上下文：

微服务架构包含一组服务
每个服务都部署为一组服务实例以实现吞吐量和可用性

问题背景：如何部署？

需求背景：

微服务使用各种语言、框架和不同的框架版本
需要快速构建、独立部署和扩展服务
服务实例之间要相互隔离
监控每个服务实例的行为
限制服务消耗的资源（CPU和内存）
尽可能降低成本

部署模式列表：

单主机部署多个服务实例
单主机部署单个服务实例
服务部署到虚拟机
服务部署到容器
服务部署平台
无服务器部署

基础设施相关模式组——部署模式：

单主机部署多个服务实例

在主机（物理机或虚拟机）上运行不同服务的多个实例，存在资源需求冲突的风险。

有多种方法可以实现这种部署，比如每个服务实例占用一个进程

优点

资源利用率高

缺点

资源需求冲突
依赖版本冲突
难以限制服务实例消耗的资源
因为一个进程中可能有多个服务实例，因此很难监控每个服务实例资源消耗，也没法隔离每个实例

单主机部署单个服务实例

一台主机上部署一个服务实例

优点

服务实例彼此隔离
不存在资源冲突或依赖版本冲突
最多消耗一个主机的资源
监控、管理、重新部署都很简单

缺点

资源利用率低

服务部署到虚拟机

把服务打包为虚拟机镜像，并将每个服务实例部署为单独的虚拟机。可以认为运行时每个服务都是该镜像实例化的虚拟机。

优点

通过增加实例数量来扩展服务很简单（负载均衡）
VM封装了服务构建的细节，所有服务启动和终止方式是一致的
每个服务实例都是隔离的（单独的VM）
VM可以对服务实例消耗的CPU与内存进行限制

缺点

资源利用率较低（一台虚拟机只允许一个服务实例）
部署相对慢（分钟级）
操作系统管理VM所需的额外开销

服务部署到容器

将服务打包为容器镜像并部署到容器中

容器是一种轻量级部署方案，可以在一台机器上运行多个容器共享操作系统，从容器的角度看，它就好像有自己的独立IP、端口，与其他容器不冲突，互相独立运行；同时目前有很多现代化工具来编排容器协调资源，比如k8s

优点

更改容器数量可以直接扩展或缩减服务
容器封装了服务构建的细节，所有服务启动和终止方式是一致的
服务实例互相隔离
容器可以限制服务实例使用的CPU及内存
容器的构建和启动是很快的（明显快于VM镜像构建与VM启动）

缺点

大量容器的管理
部署容器的基础设施没有部署VM的基础设施丰富

无服务器部署

使用公有云提供的serverless部署机制部署服务，部署细节对用户是隐藏的，用户不要管理基础设施（没有服务器的概念）。需要用户打包代码（比如zip）并上传，基础设施获取服务代码并运行。常用的公有云serverless平台有AWS Lambda、Azure Functions等

示例：使用AWS Lambda部署Restaurant Service

优点

AWS服务集成简单
消除系统管理任务，比如底层系统管理、操作系统或运行时补丁等
弹性伸缩：运行多个服务实例以动态处理负载

缺点

延迟：请求可能有高延迟（Java服务通常需要至少几秒钟，不适合对延迟敏感的服务）
不适合长时间运行的服务

服务部署平台

使用部署平台作为应用程序部署的自动化基础设施，提供服务抽象（一组命名的、高可用服务实例）：

Docker编排框架，比如k8s
无服务器平台，比如AWS Lambda
PaaS，比如Cloud Foundary

Docker编排框架将运行着Docker的一组计算机转变为资源集群，将容器分配给机器，提供资源管理、调度和服务管理等功能。常用编排框架有k8s

现代常用的服务部署平台：k8s集群

优点

多种后续模式（Successor）支持，使用灵活性高；功能强大

缺点

额外的学习和资源成本

总结

微服务的各种部署模式都有各自利弊，在进行微服务部署时应当选择支持服务要求的最轻量级部署模式，比如Serverless $\gt$ 容器 $\gt$ 虚拟机 $\gt \dots$

再回顾一下这张关系图：