微服务是大型架构核心，下面我详解微服务部署模式@mikechen
虚拟机部署
在一台物理机、或虚拟机上，运行多个不同微服务的实例（或同一服务的多个实例）。
服务可能运行在不同端口，或同一进程容器（如Tomcat中多个Web应用）。
[服务 A] → VM 实例 1（虚拟机镜像） [服务 B] → VM 实例 2（虚拟机镜像） [服务 C] → VM 实例 3（虚拟机镜像）
| 优点 | 缺点 |
|---|---|
| ✅ 服务实例完全隔离，安全性高 | ❌ 资源利用率低（每个 VM 占用独立内核） |
| ✅ 封装技术栈，无需关心底层环境 | ❌ 部署速度慢（VM 启动慢，分钟级） |
| ✅ 使用成熟云计算基础设施（AWS EC2） | ❌ 成本高（每个 VM 独立收费） |
| ✅ 适合传统企业，运维团队熟悉 | ❌ 弹性扩展不够灵活 |
容器化（Docker）部署
容器化部署模式利用Docker等容器技术，将每个微服务及其依赖打包成独立的容器镜像。
并通过容器编排平台（如Kubernetes），进行统一管理和部署。
容器具有轻量级、隔离性强、可移植性好等特点。
[服务 A] → Docker 容器 1 [服务 B] → Docker 容器 2 [服务 C] → Docker 容器 3
| 优点 | 缺点 |
|---|---|
| ✅ 服务独立部署，开发团队自治 | ❌ 需要容器管理平台（K8s/Docker Swarm） |
| ✅ 独立扩展，可按资源需求分别扩容 | ❌ 服务间通信复杂（RPC/消息队列） |
| ✅ 技术栈灵活，各服务可用不同框架 | ❌ 数据库分散，分布式事务复杂 |
| ✅ 故障隔离，单服务崩溃不影响其他 | ❌ 测试复杂，需启动所有依赖服务 |
Kubernetes（K8s）集群编排部署
Service Mesh 是专门负责服务间通信的基础设施层。
[服务 A] + [Sidecar 代理] → K8s Pod [服务 B] + [Sidecar 代理] → K8s Pod 流量管理 → Istio/Consul → 自动负载均衡、熔断、监控
| 优点 | 缺点 |
|---|---|
| ✅ 基础设施与服务分离，开发专注业务 | ❌ 架构复杂度高，需要学习 Istio/Argo |
| ✅ 自动负载均衡、熔断、限流、监控 | ❌ 性能损耗（Sidecar 代理增加延迟） |
| ✅ 支持多语言，统一治理策略 | ❌ 运维成本高，需要专门团队 |
| ✅ 云原生最佳实践，K8s 原生支持 | ❌ 调试复杂，问题定位困难 |
Serverless （函数式微服务）
将微服务代码，部署到云平台的FaaS（Function as a Service）或Serverless容器平台。
比如：AWS Lambda、阿里云FC、Google Cloud Functions、Knative等。
无需管理服务器、容器或集群，按实际调用付费。
极致简化运维（几乎零服务器管理）。
自动无限弹性伸缩 + 高可用，成本最低（真正按需付费，闲时几乎为0）。
适用场景：事件驱动型业务、突发流量场景、计算密集型短任务、创业团队或希望大幅降低运维成本的项目。